Sending Data to the Debugger

We’ve already discussed using the Trace object to send Write and Warn messages to the Trace collection facility. You might also want to gather data independently from the page. Much of the debugging that goes on is not directed at the page code but rather at the business objects being used by the page. For example, if you’re trying to gather information about code execution in the Session_OnEnd event, the .NET Framework provides the objects in the System.Diagnostics namespace that allow us to get even deeper into the code and gather more detailed debug information. We can then output debug information without relying on the presence of an executing page to receive the output.

Code Listing 10-6 shows how to use the WriteLine method of both the Trace and Debug objects, which are in the System.Diagnostics namespace. (This Trace object is not the same as the Trace property of page.) Even with the trace and debug Page directives set to true, we still won’t see evidence of the error messages. To view the error data, we must use a process that will listen for the issued debug and trace information. Attaching to the process with Microsoft Visual Studio .NET 2003 and viewing information in the debug pane works. Another option is to use a system-level debug listener, such as DebugView, available for download at http://www.sysinternals.com/ntw2k/freeware/debugview.shtml.

Code Listing 10-6: DiagnosticsDebug.aspx

 <%@Page debug="true" compileroptions="/d:TRACE" %>
<script language="C#" runat="server">
protected void Page_Load(object o, EventArgs e) {
    System.Diagnostics.Debug.WriteLine("important debug information goes here");
    System.Diagnostics.Trace.WriteLine("trace information goes here");
}
</script>
<asp:label runat="server"  Text="Debugging info is helpful" /> 

Note that the Debug and Trace class functionality from the System.Diagnostics namespace is available only when the corresponding constants are defined. We get DEBUG defined when the debug Page directive is true, but the trace Page directive is unrelated. To define TRACE, we must do so explicitly using the compileroptions Page directive by setting the exact argument to be passed to the compiler. In this case, the argument is “/d:TRACE”. The compileroptions directive can be used to pass any arbitrary argument to the compilation of the page.

Note

Do not use ASP.NET debug functionality on a production server. The performance implications are severe. Instead, to gather run time information programmatically, use trace functionality or classes in the System.Diagnostics.Trace namespace.

Using Compiler Options

In addition to being able to pass compiler options directly using the compileroptions Page directive, we can control another behavior of ASP.NET code generation and compilation that can make investigations easier. By default, ASP.NET generates line-number pragma statements throughout the code. These references indicate the source point of the generated code in the original .aspx page. These pragma statements are not necessary, and can even be distracting, when you look extensively at the generated code. To disable these statements, add the linepragmas attribute to the Page directive with a value of false. Code Listing 10-7 is an example of disabling the source-point line pragmas.

Code Listing 10-7: NoLinePragmas.aspx

 <%@Page linepragmas="false" %>
<asp:label 
    runat="server" 
     
    Text="Disable line pragmas for more readable generated code" /> 

There’s really no point in disabling line pragmas generally, but when you find yourself needing to trace through the page class code to pursue some elusive problem, you’ll appreciate being able to remove them from view.