It's midnight, and all's quiet in Code City. Suddenly, disaster strikes! The ASP script you're working on brings down the Web server. You immediately go into debug mode. First, you output the values of the variables in your script. Next, you print comments to the browser using crude Response.Write() statements. And soon the code becomes so messy that you cannot remember the error that you were trying to solve in the first place.
This scenario could have easily been turned on its head if you had just used ASP.NET's script tracing capabilities. Keep reading, and we'll tell you how.
Basics of tracing
To understand how tracing works, look at the short sample code in Listing A.
From something so small, you wouldn't expect much output. But you'd be wrong...
|Output from Listing A|
If you guessed that this was due to the Trace directive in the first line of the ASP.NET script, give yourself a quick pat on the back. The Trace directive is one of many Page directives that are available in ASP.NET to simplify debugging. It provides a big-picture view of the environment in which your ASP.NET script is executed.
You will notice that the information in the trace output has been neatly broken down into the following categories:
- Request Details: This contains information about the HTTP request—the built-in session ID, the type of request (GET or POST), the HTTP status code, and encoding.
- Trace Information: This actually "traces" the progress of your script and provides information about the various subprocesses started by the script. Note that you can output custom messages as well as variables values at any point for faster debugging.
- Control Tree: As is evident from the name, this outlines the different controls that you have used in your ASP.NET script. For example, the System.Web.UI.WebControls.Label entry indicates that the script uses a "label" ASP.NET server control.
- Cookies Collection: Here, you can view all the cookies that have been used. The ASP.NET_SessionId entry represents the cookie that maintains the state information in the ASP.NET environment by default.
- Headers Collection: HTTP headers, sent to the browser as part of the response from the Web server, are listed here.
- Server Variables: This last section displays the values for all the important server variables—$HTTP_REFERER, $HTTP_USER_AGENT, $SERVER_NAME, $SCRIPT_NAME, and so forth.
The standard trace output packs a mean punch. If you have a problem in your script, a quick look at the trace report is a good way to start the debugging process.
Sometimes you want to go beyond the standard output by adding some trace output of your own. No problem—you can easily add your own custom messages to the trace output. Take a look at Listing B, which shows you how.
Here is the output of the above script (focus on the "Trace Information" block):
|Output from Listing B|
As you can see, there are now additional entries in this block under the Array Check category, corresponding to the calls made to the Trace() object in the script. The built-in ASP.NET Trace() object allows you to add custom messages to the Trace directive's output. The Write() method of this object accepts two parameters: the category of the message and the message itself. The former helps you organize your messages into groups for easy tracing, and the latter is the actual text to be displayed in the trace. You can use the message parameter to track the progress of your script in the manner that you understand best. Pay attention also to the last two columns of this Trace Information section, which list the time in seconds for each Write(). This can be useful to identify bottlenecks in your ASP.NET scripts.
You Have Been Warn()-ed
An alternative to the Write() method is the Warn() method, used to highlight more serious problems in your ASP.NET script. Look at Listing C.
If the script above encounters a fatal error—for example, the database server mydbserver is down—the output would look like this:
|Output from Listing C|
The effects of the Warn() method are obvious—messages are displayed in bright red! This allows a developer to differentiate between the alarming "we have a serious problem" messages and the "this is just general information" messages. The input parameters are the same as those for the Write() method—the category and the message itself.
Tracing And Logging
If the thought of adding the Trace directive to all the files in your already mostly done application doesn't appeal to you, you can activate application-level tracing (which doesn't require you to modify each script) through the web.config file in your application directory. Here's a sample of what you need to add to it:
<configuration><system.web><trace enabled="true" requestLimit="5" pageOutput="true" traceMode="SortByTime"localOnly="true" /></system.web></configuration>
The enable attribute of the
A special note here on the trace.axd script: this is a built-in script that becomes available when you enable application-level tracing. This script allows you to view previous trace output—especially useful when you are debugging dependent scripts. This file cannot be viewed in a text editor; instead, you have to view it in your browser.
By enabling application-level tracing, developers can concentrate on programming instead of on trying to track down and fix vexing problems. Over the course of this article, I've shown you how to enable tracing, and I've also explained the various sections of the trace represent. I showed you how to add your own custom messages to the trace output at important points, and how to use the Write() and Warn() methods to color-code your debug messages. Finally, in order to simplify the task of activating tracing at the application level, I showed you how you could write all trace output to a trace log in one fell swoop, simply by modifying the config.web configuration file.
All these techniques can significantly reduce the time you spend debugging your scripts, and they provide a systematic way in which to locate and resolve errors in your ASP.NET development process.