In addition to using the debugger to troubleshoot ASP.NET, we'll also need to consider other forms of debugging—in particular, logging. In Chapter 5, we used the
Trace and Debug classes for logging in traditional .NET applications. You can use those classes to do logging in ASP.NET, too. The rules for using these logging classes in ASP.NET are very similar; about the only noticeable difference is in the XML config file. Isn't it great that .NET allows you to reuse the logging API you learned for one project in different projects?
Except you may not want to. Although you can use the Trace and Debug classes in ASP.NET pages, another logging API is exposed that may be better for web page development. Traditionally, web pages and applications have been written by two very different classes of programmers. ASP.NET closes the gap a little by bringing far more structure to web development, but even so, the logging needs of a web page are a bit different from those of an application. Among the chief differences:
Each web page is relatively standalone. Anything that happened on the previous page usually (though not always) doesn't matter. In contrast, applications require a more holistic approach to debugging, and logs that go back to the very beginning of the program.
Some applications have multiple users connected simultaneously, but all web pages are like that. Traditional logging gets confusing when multiple users write debugging info at once. But ASP.NET logging makes it trivial to see the debugging output for just any one particular user at a time.
When debugging web pages on a remote server, it's convenient to view the logs remotely with a web browser, too. Traditional logging doesn't easily support this.
Each web page maintains a great deal of information by default—the list of cookies, the querystring, information about the controls on the page, etc. We want this data to be automatically integrated into our debug logs.
Traditional applications are usually installed on servers that the developer can't directly interact with. So application logs tend to be long and wordy, since the developer needs to gather everything that could be relevant in one shot. Web pages are often installed on a server the developer can access. The logging can be less verbose (and hence, easier to read), since additional logging can be added if needed.
To solve all these issues, ASP.NET provides an alternative logging class called the TraceContext. Unlike the Trace and Debug classes from Chapter 5, which mix all the logging from the program into one file, the TraceContext will create one log file for each view of each page.
The first thing we need to do is enable tracing for the ASP.NET page we want to debug. This is very easy to do—it requires adding only a single line to either the page or the XML config file. But before we turn tracing on, let's first look at all the debugging information that tracing gives us. Keep in mind that all the following data was automatically provided by ASP.NET by changing just one line of code. Even though the data normally appears on a single web page, I've split it into smaller chunks here so that we can discuss each item one by one.
This is basic stuff: the time the web request was submitted, the encoding (for example, Unicode vs. ASCII), whether the web request was a GET or POST, etc. When debugging, you probably won't need this information very often. The only one of these fields that I've ever used to solve a bug was Session ID—a random number that identifies a user across multiple pages. Remember that each ASP.NET log corresponds to a view of a single page by a single user, so if you ever notice a list of logs and need to know which ones were by a particular person, Session ID is one way to figure that out.
Although the Time Of Request field probably won't help you solve any bugs, you should always at least glance at it every time you read an ASP.NET log. An extremely common mistake is to waste time by accidentally reading an old log instead of the one you care about. A quick sanity check on the Time Of Request field eliminates this error.