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…

Figure A

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Headers Collection: HTTP headers, sent to the browser as part of the response from the Web

    server, are listed here.

  6. 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.

Taking Messages

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):

Figure B

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:

Figure C

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" 

The enable attribute of the element allows you to specify whether you want tracing at

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

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