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
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
the application level (note that you can still override this directive at the page level). The
requestLimit attribute allows you to specify the number of traces to keep in memory, while
the pageOutput attribute controls whether the trace information is appended to the end of the
page or written to a separate trace.axd log file in the application directory. Finally, the
traceMode attribute allows you to sort the trace output by category or time.
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
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