ASP.NET: Error Handling Tips And Tricks Part 1 – Page And Application Tracing

The first tip has more to do with error diagnosis. Lot’s of developers use Response.Write as their primary debugging mechanism in ASP. ASP.NET now has built in tracing. No longer do we need to use messy Response.Write statements. Now, we can use Trace.Write statements.

These Trace.Write statements are conditionally compiled out depending on whether or not tracing is enabled in your application.

1. Add trace directive at top of page

<%@ Page Trace=“True” %>

2. Add trace calls throughout page

Trace.Write(“Button Clicked”)

Trace.Warn(“Value: “ + value)

3. Access page from browser

So, there is a way to set a value at the application level to turn on and turn off page tracing. In the Web.Config file, there is a Trace tag that you can use to globally set this trace value. I can set the number of requests that I want to trace by setting the RequestLimit property.

One thing that people have been asking is if you can have tracing enabled but not show all of the extra data at the bottom of the page. What they want to be able to do is send it to a second window perhaps. The idea is that someone can test the app and I can have all of the trace output saved into a file for later use. ASP.NET can do this. There is a virtual file that is created under your application root called “Trace.axd”. By default, when you hit this page, you can see all of the trace statements from the application. The browser never sees any of this. It doesn’t even know the trace is enabled.

1. Create “web.config” file in app vroot:

<configuration>

     <system.web>

         <trace enabled=“true” requestLimit=“10”/>

     </system.web>

</configuration>

2. Access tracing URL within app

https://localhost/approot/Trace.axd