Tracing Features of ASP.NET

Introduction

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 our discussion.

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

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

• 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 the application:

1. Create a new web application in VS.NET
2. Open web.config file
3. Find the <trace> element and set its enabled attribute to true. Also, set the pageOutput attribute of the tag to true.
4. 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 individual controls.

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:

<trace
   enabled="true"
   requestLimit="10"
   pageOutput="true"
   traceMode="SortByTime"
   localOnly="true"
/>

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 trace.axd utility.

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.

try
{
//some code that might throw 
//exception.
}
catch(Exception exp)
{
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.

Summary

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.