More often than not, I see how newbie .NET programmers are confused when trying to trace ASP.NET applications. The origin of the confusion is that .NET Framework exposes two different tracing mechanisms when you are developing web applications.
General .NET Framework Tracing
Firstly, you have the standard low-level System.Diagnostics.Trace class. This class allows us to emit tracing information within our code, using Trace.WriteLine() methods. We also need a TraceListener, which will allow us to capture this information into a storage we choose. .NET Framework does the plumbing for us when we associate a TraceListener with an application, using its configuration file.
There are several pre-made TraceListener implementations already available, such as TextWriterTraceListener (which writes the tracing information into a text file) and EventLogTraceListener (which writes the same information in a specified event log, even if it’s in a remote computer).
ASP.NET offers another tracing mechanism for web developers, based on System.Web.TraceContext class. This is an object that lives in ASP.NET page, just like Controls, Request, Response and so on. We have to enable tracing in web.config file, and we can also set it up to display the tracing information on the page itself (setting pageOutput=’true’) or using ASP.NET trace viewer (appending /Trace.axd to the page URL). For example:
<trace pageOutput="true" enabled="true"/>
You can emit tracing information from ASP.NET code using Write or Warn methods of the Page.Trace property. The difference is that Warn messages are displayed in red.
The best thing is that ASP.NET runtime adds a lot of information by default, such as:
- timing of the main page events, so we can check how long it takes
- page controls hierarchy tree
- server variables
- request and response information
in addition to our own tracing information, as displayed below:
We can use System.Diagnostics namespace objects to trace in ANY .NET Framework application, including ASP.NET ones. But, for ASP.NET applications, we have a powerful tracing mechanism already set in place by Page.Trace property.