Tracing in ASP.NET
By Scott Mitchell
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:
|
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
andTrace.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:
|
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!