Tracing in ASP.NETBy Scott Mitchell
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
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
Problems with Classic ASP's
Response.Write Debugging Method
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
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
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
These two methods both expect two String parameters and can be called like so:
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.
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
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
- Control Tree - A listing of the Web controls on the ASP.NET Web page, and how they relate to one
- 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.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:
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
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
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
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 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
setting accepts the following parameters:
To enable tracing output on your ASP.NET Web pages for the entire Web application, simply set
true. If you are
working on a live site, you can set
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
|Something to Try...|
Wanna see something neat? Set the |
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