This article talks about tracing - a form of debugging that allows us to keep track of the health of our applications. We see how tracing is implemented in .NET, and how we can implement our own tracers.
The Basics
.NET provides Trace Listeners, which are objects that receive the trace output and output it somewhere; that somewhere could be the debug window in your development environment, a file on your hard disk, a Windows Event log, a database, or any other customized data store.
A Trace Listener passes on tracing information from your application to the output store.
The System.Diagnostics namespace provides two classes named Trace and Debug that are used for writing errors and application execution information in logs. Only methods of the Trace class become part of the release build code, providing you the ability to track and record the health of your application. When you create a new project in Visual Studio, you need to define the DEBUG and/or TRACE symbols, as required.
.NET Trace Listeners
.NET provides 3 Trace Listeners: DefaultTraceListener (outputs to Debug window), TextWriterTraceListener (Outputs to file) and EventLogTraceListener (outputs to the Windows Event log). The Trace Listeners provide methods to output the trace information, flush the buffer and close the output stream.
The following piece of code demonstrates how a TextWriterTraceListener can be used in your application:
FileStream myLogFile = new FileStream("D:\\MyLogFile.txt",FileMode.OpenOrCreate) ;
TextWriterTraceListener myTraceListener =new TextWriterTraceListener(myLogFile) ;
Trace.Listeners.Add(myTraceListener) ;
Trace.WriteLine("Hello - this is our trace message") ;
Trace.Flush() ;
myLogFile.Close() ;
Note: Event Logs are not recommended for most tracing scenarios, since the log tends to get quickly filled up if you are not careful. Event logs should typically be used for errors and more determined forms of tracing, such as messages from Windows Services.
Changing Trace Listeners
Instead of hard coding the type of trace listeners into your code, however, you can add or remove them through the .config file of your application (applicationname.exe.config for Windows Forms application, web.config for ASP.NET). The
Trace Switches
Trace switches allow us to control the operation of the Trace Listeners at run time. These objects can be controlled by an application's configuration file, eventually eliminating the need to change, compile and distribute our code each time we want to change the tracing behavior.
The BooleanSwitch is a kind of on/off switch which can be either enabled or disabled. The TraceSwitch, on the other hand, allows us to control the levels at which tracing can be enabled. This allows our code to check what type of messages to send to the listeners.
Implementing our own Trace Listeners
To implement our own trace listener, we need to derive from the TraceListener base class. At the very least, each inheritor of this class must implement the Write and WriteLine methods.
A typical Trace Listener to implement would be one for writing into a database. Your implementation should also provide for specifying maximum number of trace messages to hold in local cache before flushing to the database - you definitely do not want to open a connection to the database everytime you write a trace message!
Tracing in ASP.NET
.NET also provides powerful tracing mechanism for ASP.NET applications, adding tremendously to your ability to figure out what's going wrong without resorting to those dozens of Response.Write statements that later need to be removed.
The System.Web.UI.Page class provides a Sytem.Web.TraceContext object in the Trace property. The Trace object can be considered as an intrinsic page object, similar to Request, Response and Server. TraceContext class is also accessible through Control.Context.Trace property. This allows us to include trace statements in custom server controls, or when we want to include trace statements from outside the ASP.NET page, for example, from the global.asax file.
ASP.NET provides two types of tracing: page-level tracing and application-level tracing.
Page-level tracing can be enabled by setting the Trace attribute of the @Page directive to true. You can add as many trace messages to the page as you want, allowing you to print out a host of information including cookies, and server side variables. Once you are done, simply turn the Trace attribute to false, and all tracing will be disabled!
However, page-level tracing is cumbersome and does not serve the purpose fully when working on a real application - you need to setup every page individually. ASP.NET therefore provides application-level tracing, which can be enabled in the web.config file of your web application by using the
Performance Implications for ASP.NET tracing
Tracing can severally affect ASP.NET application performance. If you want to use tracing in deployed ASP.NET applications, then consider using the classes found in System.Diagnostics namespace - we can fully utilize those classes in our ASP.NET applications.
