The breakpoint concept still works in Web forms as it does in Windows forms, but with a few caveats:
- · Your development server must have the remote debugging components installed.
- · You must know approximately where to look for the data.
The second point seems simple, but how often have you stepped through an entire VB application only to find that the problem was a variable incorrectly declared before your breakpoint? Tracing provides a much more global answer to the debugging question.
To enable tracing, add a Trace = “true” attribute to your @Page directive for page-by-page implementation. Optionally, you can enable tracing for an entire application with a <trace> entry in the Web.config.
Turning on the tracing for a page or application gives anyone using the Web page a comprehensive breakdown of the many values and attributes used to keep a Web server running. Some of the information includes:
- · Details of the request
- · A breakdown of the application flow
- · The Control Tree
- · Cookies
- · Headers
- · The Form Collection (if it exists)
- · The Querystring (if there is one)
- · Server variables
The trace information itself is phenomenally helpful in debugging and optimizing, but there’s more. Using the System.Web.TraceContext class, we have the opportunity to write to the trace information section of the trace.
As shown in Table A, the TraceContext class is remarkably simple, with two properties and two unique methods.
The two methods are also overloaded, each with a similar pattern. The first method accepts a single string input and simply writes that message to the trace log in the appropriate color. The second accepts two strings and writes a message and a category to the log. This category can be sorted with the TraceMode property. You can also call the Warn method, which accepts a message and category as above, as well as an exception object. It writes the exception information to the trace log along with the other information.
A quick example
For this article, I wrote a simple Web form application that adds two numbers in text boxes and puts them in a label. I have a simple function that adds the numbers and an event handler for the button click to return the result, as shown in Listing A.
If you run the example, you’ll see that the event handler is not explicitly described in the trace information. We can fix that by adding a Trace message to the beginning of the add_Click method. Trace is a static class in Web applications and doesn’t need to be instantiated before use:
Trace.Write(“Running the add_Click handler”);
Notice that when we run the sample now and try to add two numbers, there is an entry for the new trace point, but it has no category. We want function calls to be all in one category, so when we add a trace to the sum method, we give it the “Function” category:
Trace.Write(“Function”,”This is the beginning of the sum method”);
We aren’t handling bad input in the above handler. We can use the new Try/Catch block and the TraceContext Warn method to deal with this. This leaves us with the code in Listing B.
If we try to add 4 and d using our simple example, we get the trace information shown in Table B.
Easier than VB6
Tracing ends the confusion of having to use alert() variables or Response.Write to determine what’s going on behind the scenes in our Web applications. Combining tracing with the power of breakpoints and the other Visual Studio.NET tools works to make debugging Web forms applications as easy as—or easier than—using Visual Basic 6.