Debugging ASP.NET: Tracing
This chapter is from the book
This chapter is from the book
This chapter is from the book
One of the most common ways to debug traditional ASP web applications is to use trusty calls to Response.Write. This enables you to create checkpoints in your code to view the contents of variables in the browser. This approach had several drawbacks, however. The output created by calls to Response.Write appears wherever the call is made in the code. It sometimes becomes a chore trying to interpret your debugging information because it is strewn all over the page in the browser. The formatting of your page is also affected.
When you are finished debugging your web application using calls to Response.Write, you are then faced with the daunting task of stripping out all this debug code. Because you are using the same type of code both to debug and to create valid output, you must carefully scan each of your ASP pages to make sure that you remove all the Response.Write calls that pertain to debugging. When your ASP pages get to be hundreds of lines long, this can be a real pain.
To address this issue, ASP.NET implements the TraceContext class. The TraceContext class solves all these issues and offers many more features. Let's take a look at some of the ways that the TraceContext class can help you debug your ASP.NET web applications more effectively.
Configuration
To use tracing in your ASP.NET web application, you need to enable it. This can be done at either the page level or the application level.
Page-Level Configuration
Enabling tracing at the page level entails adding the Trace attribute to the @Page directive, like this:
<%@ Page Language="C#" Trace="true" %>
If the Trace attribute has a value of true, tracing information will be displayed at the bottom of your ASP.NET page after the entire page has been rendered. Alternatively, you can include the TraceMode attribute. The value that you assign to this attribute determines the display order of the trace results. The possible values are SortByTime and SortByCategory. SortByTime is the default if you do not specify the TraceMode attribute.
Application-Level Configuration
Several tracing options are available at the application level. These settings are specified using the <trace> XML element in the <system.web> section of the web.config file. The attributes available to you are shown in Table 6.1.
Table 6.1 Tracing Options
|
enabled |
Is true if tracing is enabled for the application; otherwise, is false. The default is false. |
|
pageOutput |
Is true if trace information should be displayed both on an application's pages and in the .axd trace utility; otherwise, is false. The default is false. Note that pages that have tracing enabled on them are not affected by this setting. |
|
requestLimit |
Specifies the number of trace requests to store on the server. The default is 10. |
|
traceMode |
Indicates whether trace information should be displayed in the order it was processed, SortByTime, or alphabetically by user-defined category, SortByCategory. SortByTime is the default. |
|
localOnly |
Is true if the trace viewer (trace.axd) is available only on the host Web server; otherwise, is false. The default is true. |
An example of a trace entry in the web.config file might look like Listing 6.1.
Listing 6.1 Application-Level Trace Configuration in the web.config File
<configuration>
<system.web>
<trace enabled="true" pageOutput="false"
requestLimit="20"
traceMode="SortByTime" localOnly="true" />
</system.web>
</configuration>
Even though this example uses all the available attributes, none of them is required. Also note that page-level configuration settings overrule application-level settings. For instance, if tracing is disabled at the application level but is enabled at the page level, trace information will still be displayed in the browser.
The requestLimit attribute sets a limit on how many page requests are kept in the trace log. This prevents the logs from getting too large.
Setting the localOnly attribute to true enables you to view trace information if you are logged into the server locally, but remote users will not see anything. That way, you can enable tracing to debug a problem, and the users of your website will never be the wiser.