Tracing Features of ASP.NET
If you were an ASP developer in past, you know how difficult it was to debug your
applications. Commenting and un-commenting those Response.Write statements was a
nightmare for most of the developers. ASP.NET simplifies the debugging and
tracing process a lot. This in depth article takes you through the tracing
features of ASP.NET.
What is Debugging and Tracing?
Before going into the details of how to use trace features let us understand
what the commonly used terms - debugging and tracing - means in the context of
Debugging is a process in which you make sure that your application is
working as expected i.e. id does not contain any errors or bugs. Debugging is
generally a development time activity.
Tracing on the other hand deals with tracking the program execution. It may
not be always used for error tracking but can also be used in normal program
execution. Tracing can be enabled even during the normal program flow.
In the context of ASP.NET tracing features, we refer to both of the above
scenarios as "Tracing".
How ASP.NET supports tracing?
The ASP.NET provides an implicit object called Trace to you that can
be used to log trace messages. This object is of type TracingContext
which resides in System.Web namespace. This class has two methods -
Write and Warn that allow you to write your trace message to trace
log. ASP.NET also comes with a browser based utility called Trace.axd that
allows you to view all the trace information.
The only difference between Write and Warn methods is that Warn method
displays the trace message in red color.
Why ASP.NET tracing is better than traditional ways?
You might be wondering how ASP.NET tracing is better than traditional
Response.Write statement. After all you are just writing Trace.Write instead of
Response.Write! The answer lies in the flexible way in which you can control the
tracing. For example if you use traditional Response.Write statements to display
some trace methods it becomes your responsibility to comment them before the
application goes into production. On the other hand ASP.NET tracing can be
turned on or off with just a few settings at page level or in the web.config
ASP.NET trace is not just the messages you emit. It also contains many other
things that you typically need to know while developing the applications. They
- Session ID
- Cookies and their values
- Sever variables
- Event execution time
and so on.
You can clearly see that with just a few settings you get lot of information
about the request.
Tracing in action
Let's see how tracing works with an example. Follow these steps to develop
- Create a new web application in VS.NET
- Open web.config file
- Find the <trace> element and set its enabled attribute to true. Also,
set the pageOutput attribute of the tag to true.
- Save and run the application
and without writing a single line of code you get following display!
This information is nothing but the trace log.
Sections of Trace Output
The above output has following sections:
- Request Details
- Trace Information
- Control Tree
- Cookies Collection
- Headers Collection
- Server Variables
The Request Details sections gives information about the request such as
Session ID and request method.
The Trace Information section gives information about Trace Messages. These
messages can be system generated or emitted by you.
The Control Tree section tells you about the complete controls collection
inside the web form. This also gives details of rendering size in bytes for
The Cookies Collection section lists all the cookies created by your
application such as Session ID cookie.
The Headers collection displays all the HTTP headers such as User-Agent.
Finally, the Server Variables section lists all the server variables. This
section is very useful to get information such as remote host, authentication
details and request path.
Understanding the <trace> section
In the previous example we changed some settings in the <trace> section of
web.config file. The complete section looks as follows:
In order to turn the tracing on for all the web forms of an application the
enabled attribute must be set to true. We also set the
pageOutput to true. Setting this attribute to true causes the page to
display the trace information as we saw above. Make sure you have this attribute
turned off in production version. You might be wondering - where this
information goes if you set enabled attribute to true but pageOutput attribute
to false. In such case the trace information is still written to the trace log
but not displayed on each and every page. You can view such trace logs using
To run the utility type the url to the virtual root of your web application
and add trace.axd to it. For example on my test machine the url looks like -
http://localhost/demos/tracing/trace.axd. This time you will get a list of all
the trace logs for various pages. Navigating to a particular page essentially
displays the same page as seen above.
The requestLimit attribute indicates the number of requests to be
stored on the server and the default value is 10. traceMode attribute
indicates whether the information being displayed is to be sorted by time (SortByTime)
or category (SortByCategory). The localOnly attributes specifies whether
the trace.axd utility is available on the web server only or can be accessed
from remote machines also.
Writing your own messages to trace log
Let us move ahead and write our own messages in the trace log. Doing so is
very easy as shown in the following code:
private void Page_Load
(object sender, System.EventArgs e)
Trace.Write("Page_Load processing started");
Trace.Warn("Page_Load processing ended");
Here, I used Trace.Write and Trace.Warn methods to write the
messages to the trace log. Note, how the Trace.Warn message is displayed in red
after you run this page. You can also categorized your trace messages by using
an overloaded version of above methods.
Trace.Write("my category","Page_Load processing started");
Yet another overload of these methods also allow you to display Exception
details along with your trace message. This overload accepts parameter of type
System.Exception and displays its Message property along with your message.
//some code that might throw
Trace.Write("my category", "Some error occurred.", exp);
You can also programmatically decide whether tracing is enabled or not by
using Trace.IsEnabled property.
Controlling the tracing at page level
In the above example we set some properties of <trace> tag in web.config and
it displayed trace log for each and every page. You may not want this behavior
for all the pages. In such cases you can control whether the page will
participate in tracing process or not using Trace
attribute of the @Page directive.
<%@ Page language="c#" trace="False"%>
Note: Once you set trace attribute at page level this setting overrides all
the settings at web.config level. If you want that web.config settings be in
effect then simply remove the trace attribute from @Page directive.
In this article we saw how to use tracing features of ASP.NET in your
application. We also saw various ways of configuring tracing such as <trace>
tag, Trace.Write, Trace.Warn and Trace attribute of @Page directive. Using
built-in features of tracing you can not only save lot of code that other wise
you have to write, you can also control the trace from a central place.