Debugging and Tracing in ASP.NET (3/4)

[previous] [next]

Debugging and Tracing in ASP.NET

System.Diagnostics.Debug

This class provides methods for writing debugging output and validating assertions. It has an Assert and Fail method with multiple signatures to suit different situations. The methods of this class are defined with the Conditional attribute discussed earlier. So the compiler variable DEBUG must be defined for these methods to be called. In Visual Studio .NET DEBUG is defined by default during debug builds. Thus, the use of the methods of this class does not affect performance or size of release builds.

When debugging output is written using the four different Write methods in this class they go to all the listeners that are registered with this class. All listeners that can trace debug output inherit from TraceListener, which is an abstract class. There are three concrete listeners that inherit TraceListener. The first listener, which is always registered by default, is the DefaultTraceListener. This prints the output to the debugger log during debugging. The second concrete listener is EventLogTraceListener. This directs its output to an event log. The third concrete listener is the TextWriterTraceListener. This prints its output to a text file.

When controlling the debugging trace with a BooleanSwitch we have two options. One is to use an if...else statement as shown below.

if(traceflag.Enabled) 
{
	Debug.Write("Some debugging ouput");
}

The other is to use the provided WriteIf methods of the Debug class.

Debug.WriteIf(debug.Enabled, "Some debugging ouput");

Given these two options it is always better to use the if...else structure for performance reasons. When the traceflag is disabled the call to Write is never performed. However, in the second construct the boolean check and the call is always performed. Thus, for all practical purposes the Write methods should be used exclusively.

Setting the appropriate properties of the Debug class can control the format of the debugging output. While all properties and listeners can be added in code it is best that they are done in the config file. This allows for changes without recompilation. The example config file shown above can be modified to add a text file log and fix some formatting options as shown below.

<configuration>
 	
	...
    <system.diagnostics>
       	<switches>
          <add name="debugSwitch" value="1" />
        </switches>
	<debug autoflush="true" indentsize="4">
           <listeners>
              <add name="textListener" 
                   type="System.Diagnostics.TextWriterTraceListener,System" 
                   initializeData="c:\Debug.log" />
           </listeners>
	</debug>
    </system.diagnostics>
</configuration>

System.Diagnostics.StackTrace

Many times it is helpful to print out the call stack. This class provides the relevant functionality. Unlike Java where a stack trace can only be obtained for an exception by calling the printStackTrace method, the .NET framework provides the ability to construct a stack trace anywhere in the code by constructing a new instance of the StackTrace object. The call stack pertaining to an exception can also be generated using the appropriate constructor. Once the StackTrace object has been created the content can be printed out for observation.

A StackTrace object is essentially a collection of System.Diagnostics.StackFrame objects. Each StackFrame object contains information about one call. The StackTrace object exposes this collection using the FrameCount property and the GetFrame method.

The following code prints out the call stack using the StackTrace and StackFrame class.

StackTrace st = 
   new System.Diagnostics.StackTrace(true);
for(int i = 0; i < st.FrameCount; i ++)
{
	StackFrame sf = st.GetFrame(i);
	Debug.WriteLine(" File: " +  sf.GetFileName()  +
			" Line: "  + sf.GetFileLineNumber() + 
			" Method: " + sf.GetMethod());
}

[previous] [next]

Created: December 4, 2002
Revised: December 4, 2002

URL: https://webreference.com/programming/asp/debugging/3.html