ASP.NET 4 in VB 2010 : Page Tracing (part 1) - Enabling Tracing, Tracing Information

Visual Studio's debugging tools and ASP.NET's detailed error pages are extremely helpful when you're testing an application. However, sometimes you need a way to identify problems after you've deployed an application, when you don't have Visual Studio to rely on.

You could try to identify these errors by recording diagnostic information in an event log, but this assumes that someone will actually review the log regularly. More aggressively, you could display some information directly in the web page. The problem with this strategy is that you need to remove (or at least comment out) all this extra code before you deploy your web application. Otherwise, your website users could see strange debugging messages when they least expect it.

Fortunately, there's an easier way to solve the problem without resorting to a homegrown solution. ASP.NET provides a feature called tracing that gives you a far more convenient and flexible way to report diagnostic information.

1. Enabling Tracing

To use tracing, you need to explicitly enable it. There are several ways to switch on tracing. One of the easiest ways is by adding an attribute to the Page directive in the .aspx file:

<%@ Page Trace="True" ... %>

You can also enable tracing using the built-in Trace object (which is an instance of the System.Web.TraceContext class). Here's an example of how you might turn tracing on in the Page.Load event handler:

Protected Sub Page_Load(ByVal sender As Object, _
  ByVal e As EventArgs) Handles Me.Load
    Trace.IsEnabled = True
End Sub

This technique is useful because it allows you to enable or disable tracing for a page under specific circumstances that you test for in your code.

Note that by default, once you enable tracing, it will apply only to local requests. (In other words, if you're working with a deployed web application, you need to make your requests from the web browser on the web server computer.) This limitation prevents end users from seeing the tracing information. If you need to trace a web page from an offsite location, you'll need to enable remote tracing by changing some settings in the web.config file.Once you've enabled remote tracing, you can use your code to selectively turn on tracing—for example, for specific users.

2. Tracing Information

ASP.NET tracing automatically provides a lengthy set of standard, formatted information. Figure 1 shows what this information looks like. To build this example, you can start with any basic ASP.NET page. Shown here is a rudimentary ASP.NET page with just a label and a button.

Figure 1. A simple ASP.NET page

On its own, this page does very little, displaying a single line of text. However, if you click the button, tracing is enabled by setting the Trace.IsEnabled property to True (as shown in the previous code snippet). When the page is rendered, it will include a significant amount of diagnostic information, as shown in Figure 2.

Figure 2. Tracing the simple ASP.NET page

Tracing information is provided in several different categories, which are described in the following sections. Depending on your page, you may not see all the tracing information. For example, if the page request doesn't supply any query string parameters, you won't see the QueryString collection. Similarly, if there's no data being held in application or session state, you won't see those sections either.

If you're using style sheets, your rules may affect the formatting and layout of the trace information, potentially making it difficult to read.

2.1. Request Details

This section includes some basic information such as the current session ID, the time the web request was made, and the type of web request and encoding (see Figure 3). Most of these details are fairly uninteresting, and you won't spend much time looking at them. The exception is the session ID. By watching for when the session ID changes, you'll know when a new session is created. (Sessions are used to store information for a specific user in between page requests.

Figure 3. Request details

2.2. Trace Information

Trace information shows the different stages of processing that the page went through before being sent to the client (see Figure 4). Each section has additional information about how long it took to complete, as a measure from the start of the first stage (From First) and as a measure from the start of the previous stage (From Last). If you add your own trace messages (a technique described shortly), they will also appear in this section.

Figure 4. Trace information

2.3. Control Tree

The control tree shows you all the controls on the page, indented to show their hierarchy (which controls are contained inside other controls), as shown in Figure 5. In this simple page example, the control tree includes buttons named cmdWrite, cmdWrite_Category, cmdError, and cmdSession, all of which are explicitly defined in the web page markup. ASP.NET also adds literal controls automatically to represent spacing and any other static elements that aren't server controls (such as text or ordinary HTML tags). These controls appear in between the buttons in this example, and have automatically generated names like ctl00, ctl01, ctl02, and so on.

One useful feature of this section is the Viewstate column, which tells you how many bytes of space are required to persist the current information in the control. This can help you gauge whether enabling control state is detracting from performance, particularly when working with data-bound controls such as the GridView.

Figure 5. Control tree

2.4. Session State and Application State

These sections display every item that is in the current session or application state. Each item in the appropriate state collection is listed with its name, type, and value. If you're storing simple pieces of string information, the value is straightforward—it's the actual text in the string. If you're storing an object, .NET calls the object's ToString() method to get an appropriate string representation. For complex objects that don't override ToString() to provide anything useful, the result may just be the class name.

Figure 6 shows the session state section after you've added two items to session state (an ordinary string and a DataSet object). 

Figure 6. Session state

2.5. Request Cookies and Response Cookies

These sections display the cookies that were sent by the web browser with the request for this page and display the cookies that were returned by the web server with the response. ASP.NET shows the content and the size of each cookie in bytes.

Figure 7 shows an example with a page that uses a cookie named Preferences that stores a single piece of information: a user name.  In addition, the web browser receives a cookie named ASP.NET_SessionId, which ASP.NET creates automatically to store the current session ID.

Figure 7. Cookies collections

There's one quirk with the list of cookies in the trace information. If you haven't created at least one custom cookie of your own, you won't see any cookies, including the ones that ASP.NET creates automatically (such as the session cookie). ASP.NET assumes that if you aren't using cookies yourself, you aren't interested in seeing these details.

2.6. Headers Collection

This section lists all the HTTP headers (see Figure 8). Technically, the headers are bits of information that are sent to the server as part of a request. They include information about the browser making the request, the types of content it supports, and the language it uses. In addition, the Response Headers Collection lists the headers that are sent to the client as part of a response (just before the actual HTML that's shown in the browser). The set of response headers is smaller, and it includes details such as the version of ASP.NET and the type of content that's being sent (text/html for web pages).

Generally, you don't need to use the header information directly. Instead, ASP.NET takes this information into account automatically.

Figure 8. Headers collection

2.7. Form Collection

This section lists the posted-back form information. The form information includes all the values that are submitted by web controls, like the text in a text box and the current selection in a list box. The ASP.NET web controls pull the information they need out of the form collection automatically, so you rarely need to worry about it.

Figure 9 shows the form values for the simple page shown in Figure 1. It includes the hidden view state field, another hidden field that's used for event validation (a low-level ASP.NET feature that helps prevent people from tampering with your web pages before posting them back), and a field for the cmdTrace button, which is the only web control on the page.

Figure 9. Form collection

2.8. Query String Collection

This section lists the variables and values submitted in the query string. You can see this information directly in the web page URL (in the address box in the browser). However, if the query string consists of several different values and contains a lot of information, it may be easier to review the individual items in the trace display.

Figure 10 shows the information for a page that was requested with two query string values, one named search and the other named style. You can try this with the SimpleTrace.aspx page by typing in ?search=cat&style=full at the end of the URL in the address box of your web browser.

Figure 10. Query string collection

2.9. Server Variables

This section lists all the server variables and their contents. You don't generally need to examine this information. Note also that if you want to examine a server variable programmatically, you can do so by name with the built-in Request.ServerVariables collection or by using one of the more useful higher-level properties from the Request object.