Debugging ASP.NET Applications

Summary

• Tracing
• Debugging with the CLR Debugger

Tracing

Unlike classic ASP, ASP.NET provides easy-to-use tracing functionality that can be used to monitor the application. ASP.NET tracing tasks can be subdivided into three main categories:

• Generating page-level tracing.
• Adding traces.
• Generating application-level tracing

Generating page-level tracing.

With ASP.NET, generating page-level tracing is very easy - just set the Trace attribute of the @Page directive to true:

<%@ Page language="c#" Codebehind="default.aspx.cs" trace=true  ...  %>

By simply setting Trace = true you get the following trace information in the trace output:

• Request Details such as session ID, status, encoding, and others.
• Trace Information which displays information about certain code snippets and how long they took to process (this timing information can be used to measure performance.)
• Control Tree which can be very helpful when you want to examine which controls were created as server controls, and for determining control parents. It follows that the Control Tree section is a good place to discover which controls should have been made server controls.
• Cookies Collection which shows cookies names, values, and sizes.
• Header Collection which shows client-side HTTP header names and values.
• Server Variables which shows names and values of all server variables.

With page tracing you can include your own tracing information, and when tracing is turned on, this information will appear in the Trace Information section. The following page illustrates the above information:

Adding traces

You can add more trace information to the Trace Information section by using the Write and Warn methods of class Trace in the code behind module. Note that the default sort of trace messages is by time, but you can change the sort order to sort by category using the TraceMode attribute:

<%@ Page language="c#" trace="true" TraceMode="SortByCategory" %>

Generating application-level tracing

What if you wanted all your ASP.NET pages to generate trace statements. It would be quite a headache to add the Trace="True" attribute to each page's @Page directive, especially if you have 10s or 100s of pages. And what if you later wanted to disable tracing? A much better way to control application-wide tracing is to use the Web.config file. The tracing features that you can add in the Web.config file are actually richer than those in the @Page directive. The following shows a sample Web.config file that enables certain tracing features:

<configuration>
    <system.web>
        <trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" />
    <\system.web>
<\configuration>

enabled attribute enables or disables tracing for the entire application. If set to false, page tracing via the Trace attribute is still possible. pageOutput attribute enables/disables tracing details for each page within an application. However, if this item is set to false while the enabled attribute to set to true, the traces will be kept in memory

Viewing an application's trace in one location

Once application-level tracing is turned on, you can view the entire application's trace information in one central location: trace.axd. For example. to view the trace information for any given ASP.NET Web application:

Note that trace.axd was invoked from within the application's directory, and not from some other central location. The ViewDetails link is used to display the trace information for the associated request. trace.axd offers a number of advantages:

• If you wish to examine the traces for a live application, you would not have page-level traces enabled. Rather, you can use trace.axd to view the entire application's trace information. Viewing trace information for a live application is accomplished by adjusting Web.config to set enabled to true and pageOutput to false.
• You can use trace.axd to view the application's trace from anywhere if you set localOnly to false. The default is true.

Debugging with the CLR Debugger

Debugging ASP.NET projects is very easy. However, you need to be aware of some important points. In the ASP.NET application's Web.config file there exists a <compilation> element with the following default values:

<compilation defaultLanguage="c#" debug="true" />

When an ASP.NET application is first created, the <compilation> element has its debug attribute set to true, and the project itself is configured to Debug (rather than release). The interaction of these two items described which parts of an ASP.NET application can be debugged as follows:

 In the last two cases where debug is true and irrespective of the solution build configuration, if you try to debug the application you will get the following dialog box: