Tracing in ASP.NET

Introduction
To say that debugging support was lacking in classic ASP is a bit of an understatement. One of the most common debugging "techniques" for classic ASP developers was to simply place Response.Write statements in various code portions in order to see certain variable values or to ensure that a particular piece of code was being reached. One of the most common / useful places to put such a debugging Response.Write is right before executing a dynamic SQL statement.

ASP.NET (finally) introduces modern programming practices into Web development, something that's sorely been sorely lacking. With ASP.NET you can, quite easily, debug your ASP.NET Web pages using Visual Studio.NET's debugger. This means that you can step into your code, set breakpoints, have a watch window to observe the values or your variables, etc. This article, however, is not going to delve into the specifics of using VS.NET's debugger on an ASP.NET Web page (perhaps a future article will...), but, rather, in this article we'll look at how to use a simpler version of debugging in ASP.NET, akin to classic ASP's Response.Write method.

Problems with Classic ASP's Response.Write Debugging Method
While the Response.Write method for printing debugging information in an ASP.NET Web page is simple, quick, and useful, it has several downsides as well. For example, if you have a live site, but need to perform some quick debugging on a particular ASP page, your users may see debugging information in the form of Response.Write statements (which makes the site look very unprofessional.) Furthermore, while developing your site, you may place several Response.Write statements throughout your application. Once you're ready to ship your application, however, you must go through each page removing any diagnostic Response.Write statements.

Using ASP.NET's Tracing Features
ASP.NET provides developers with a much more refined process for outputting page-level information. With ASP.NET, rather than using Response.Write, use Trace.Write or Trace.Warn. These two methods both expect two String parameters and can be called like so:

'Display an informational message Trace.Write(category, message) 'Display a warning (shown in RED) Trace.Warn(category, message)

These two statements can be littered throughout your ASP.NET Web page as you see fit. Recall that one of the weaknesses of classic ASP's Response.Write statements is that the statements always appear, and, in order to remove them from the output, you must go through each page and remove the superfluous statements. With ASP.NET's Trace.Write and Trace.Warn statements, however, these statements only appear when tracing is enabled. There are two ways to enable tracing - on a page-level and on a Web application-level.

We'll examine how to work with Web application-level tracing in a bit, but let's first look at enabling page-level tracing. All it takes to turn on (or off) page-level tracing is the setting of the Trace attribute in the @Page directive:

<% @Page Trace="[True|False]" %>

When tracing is enabled you automagically get a plethora of information on the ASP.NET Web page. Information like:

• Request Details - Session Id; Request time, type, and encoding; status code, etc.
  
• Trace Information - Page-level ASP.NET messages that you specify via Trace.Write and Trace.Warn.
  
• Control Tree - A listing of the Web controls on the ASP.NET Web page, and how they relate to one another.
  
• Cookies Collection - A listing of all of the cookies.
  
• Headers Collection - A listing of all of the HTTP headers.
  
• Server Variables - A listing of all of the server variables.

You can see a sample of the tracing output, just scroll down to the bottom of the page. Kudos to the ASP.NET team for providing such useful debugging information all in one spot by only requiring one simply page-level directive.

Since this plethora of useful information only appears if tracing is enabled, you can place Trace.Write and Trace.Warn statements throughout the page and not need to worry about removing them when shipping your application - rather, you just need to visit each page and set tracing to false:

<% @Page Trace="False" %>

In the live demo, notice how I used the tracing. I used Trace.Write statements at the beginning and end of each of my page-level subroutines, just so I know when I'm entering and leaving the sub. I also used a Trace.Write to output the value of my dynamic SQL string. Finally, I used a Trace.Warn to warn myself (or other developers/debuggers) that a hard-coded SQL statement is used as opposed to the preferred stored procedure route.

Turning on Web-Application Wide Tracing
By turning tracing on and off at a page-level, we still have some of the inherent disadvantages found in using the Response.Write approach. Namely, when you want to disable tracing, you must go through each page and set Trace to False. Also, if you wish to turn on tracing for a live Web site, every visitor will see the tracing output at the bottom of the page.

Fortunately ASP.NET eases alleviates these worries by providing developers the opportunity to turn on (and off) tracing for an entire Web application. To do this, use the trace setting in Web.config. (Web.config is an XML-based configuration file that is located in the root directory of your Web application. For more information on Web.config check out this article.) The trace setting accepts the following parameters:

<trace enabled="[true|false]" localOnly="[true|false]" pageOutput="[true|false]" requestLimit="[number]" traceMode="[SortByTime|SortByCategory]" />

To enable tracing output on your ASP.NET Web pages for the entire Web application, simply set enabled to true and pageOutput to true. If you are working on a live site, you can set localOnly to true, meaning that only those hitting the site through http://localhost will see the tracing information.

The settings in the Web.config file simply specify the default behavior; that is, what is to happen if no page-level directive for tracing is specified. Of course, you can override these settings on a page-level by explicitly setting the Trace page-directive to True or False.

Something to Try...
Wanna see something neat? Set the Web.config's trace to enabled as true and requestLimit to some value greater than zero. Now, visit some ASP.NET Web pages in your Web application. Now, point your browser to http://localhost/trace.axd (or whatever the directory is for your Web application). Neat, eh? :-)

Conclusion
In this article we examined ASP.NET's tracing features, a simple debugging technique that is superior to classic ASP's Response.Write method. Tracing can be enabled at both the page and Web application-level. For more information on ASP.NET, be sure to visit the ASP.NET Article Index.

Happy Programming!