Chapter 6 discussed in detail how to use tracing in your VB .NET applications to locate and diagnose problems, record application status, and find performance bottlenecks. ASP .NET offers a similar tracing facility that records the main page and code events, gives you programmatic access to this information, and lets you add your own custom trace information. Good tracing information allows you to record and understand your application's behavior and can significantly improve your application's maintenance costs.
The trace facility in ASP .NET works at two levels. Page-level tracing records trace information about each HTTP request and displays that information after the page's rendered HTML. Application-level tracing records trace information for multiple pages and allows you to access this information through a special Uniform Resource Identifier (URI) called trace.axd.
Page-level tracing is disabled by default. To enable page-level tracing at design time, you set a Web Form's Trace property to true , which adds the trace attribute to the @ Page directive in the .aspx file. Listing 9-9 shows what the @ Page directive looks like when the Trace property is set to true . You can also use the Web Form's TraceMode property to ask for the trace information to be sorted either by time or by category.
<%@ Page Language="vb". .trace="True"%>
You can also control page-level tracing at runtime by changing the Web Form's Trace.IsEnabled property to true or false . This obviously only works on arequest-by-request basis, as the property state won't be maintained between HTTP requests . The code that sits behind the "Enable page-level tracing" button of the AspNetDebugDemo application is shown in Listing 9-10. This code enables page-level tracing for the current request, asks for the trace information to be sorted by time, and then writes a custom trace message and a custom trace warning. The difference between these two trace types is that a trace message is displayed in black and a trace warning is displayed in red.
Private Sub btnPageTracingOn_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles btnPageTracingOn.Click With Me.Trace .IsEnabled = True .TraceMode = TraceMode.SortByTime .Write("Information", "This is some custom trace information") .Warn("Warning", "This is a custom trace warning") End With End Sub
When you switch on page-level tracing, the trace information is displayed in the Web page along with your controls and any other elements on the Web page. Figure 9-11 shows the AspNetDebugDemo application's main page when page-level tracing is enabled by clicking the button marked "Enable page-level tracing". Notice that the information shown in the Trace Information section includes the custom trace message and warning discussed earlier. It's also worth noting that this trace information is on a per-request basis and isn't stored anywhere unless application-level tracing is switched on.
As you can see, there's a lot of tracing information available to you. The following list describes the information displayed within each of the page-level trace sections.
Request Details : Contains information about the HTTP request, including data from the HTTP request header.
Trace Information : Contains information about page events, including timing statistics so that you can do performance evaluation. You can use Trace.Write and Trace.Warn to add your own custom trace information to this section.
Control Tree : Includes information about the controls on the Web page, describing their type, render size, and view state size .
Cookies Collection : Describes the name , value, and size of every cookie passed in the HTTP response.
Headers Collection : Includes information about every header specified in the HTTP response.
Form Collection : Describes the name and value of every nonblank control in the Web Form that generated the request.
Server Variables : This section is self-explanatory ”it relates the name and value of each of the server variables.
Page-level tracing will slow down your application, but you can disable it by setting each Web Form's Trace property to false . Leaving tracing code within your application doesn't matter because the JIT compiler won't compile the tracing code when the Web Form's Trace property is set to false .
Page-level tracing is very useful during development and testing to help you understand the behavior of individual Web pages within your application. However, the output from page-level tracing is transient and not stored anywhere.
If you want to understand more about your application as a whole, or if you want to record your application's behavior when in production or its behavior during different execution runs for comparison purposes, then you need to use application-level tracing.
Application-level tracing involves tracing information being recorded for every page within an application. ASP .NET contains a built-in trace viewer for each application's trace information, which is invoked used a special page called trace.axd, off the application root. This level of tracing is disabled by default, but you can enable it by setting the enabled attribute of the <trace> section in Web.config. Listing 9-11 shows a typical <trace> section.
<trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
The following list presents the meaning of each of the attributes in the < trace > section:
enabled : If this attribute is set to true , application-level tracing is enabled. If it's set to false , application-level tracing is disabled.
requestLimit : Specifies the number of trace requests that are stored on the Web server.
pageOutput : If this attribute set to true , trace information is displayed on individual pages and on the trace.axd page. If it's set to false , trace information is still displayed on the trace.axd page, but the Trace property of each page determines whether the trace information is shown on that page.
traceMode : Just as with page-level tracing, this attribute controls whether displayed trace information is sorted by time or sorted by category.
localOnly : If this attribute is set to true , you can view the trace.axd page only in a browser running on the same Web server as the application. If it's set to false , remote browsers can also view the trace.axd page.
To view application-level trace information in the A spNetDebugDemo application, you should run the solution in Visual Studio without debugging (using Ctrl+F5). Clicking several of the buttons that demonstrate error handling will generate some application activity and trace information. You can view this information using the trace viewer, which you access by clicking the button marked "Show app-level tracing". The code behind this button is shown in Listing 9-12.
Private Sub btnAppTracingShow_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles btnAppTracingShow.Click Response.Redirect("trace.axd") End Sub
The trace viewer page for the A spNetDebugDemo application is shown in Figure 9-12. This page shows which application pages have been requested , including the time of the request, and gives you access to the detailed trace for each of the page requests.
Figure 9-13 shows the detailed trace for a page request, which you can access by clicking one of the View Details links shown in Figure 9-12. This page looks similar to the page-level trace information that you saw earlier, but of course without the page controls or any other page elements. Just as with page-level tracing, this page shows any custom trace information that has been generated.
Application-level tracing is most useful for recording and understanding your ASP .NET application's behavior as a whole, whereas page-level tracing is more useful for testing and debugging individual Web pages. In both cases, ASP .NET provides you with the easy-to-use tools that you need to debug your Web applications.