Professional ASP.NET 1.1 [Electronic resources] نسخه متنی

Tracing

Tracing is a new feature introduced with ASP.NET, previously absent in ASP. This feature allows you to trace the execution of an application and later view the trace results. Let's see an example in VB:

<Script 
runat="server"> 
Public Function Add(a As Integer, b As Integer) As Integer 
Return a + b 
End Function 
</Script> 
Call the Add routine: 4 + 5 = <%=Add(4,5)%> 

The output of this is:

Call the Add routine: 4+5=9

Classic ASP Tracing

Although a simple example, what if within the

Add function you wished to know the parameters of

a and

b as the code was executing? ASP developers usually add

Response.Write statements in their code to trace the actions of their code as it's executed:

<Script runat="server">
Public Function Add(a As Integer, b As Integer) As Integer
Response.Write("Inside Add() a: " + a.ToString() + "<BR>") 
Response.Write("Inside Add() b: " + b.ToString() + "<BR>") 
Return a + b
End Function
</Script>
Call the Add routine: 4 + 5 = <BR><%=Add(4,5)%>

The output of which is:

Call the Add routine: 4+5=

Inside Add() a: 4

Inside Add() b: 5

9

Although this works well, it does introduce unnecessary code into the application. This usually results in bugs that break deployed applications. Examples of this include SQL statements, configuration flags, or output status details, which are all items that were never intended to be shown. You also cannot trace a deployed application, since the users would see the

Response.Write trace results!

ASP.NET Tracing

Using ASP.NET's new tracing functionality, the

Response.Write statements are replaced with

Trace.Write statements:

<Script runat="server">
Public Function Add(a As Integer, b As Integer) As Integer
Trace.Write("Inside Add() a: ", a.ToString()) 
Trace.Write("Inside Add() b: ", b.ToString()) 
Return a + b
End Function
</Script>
Call the Add routine: 4 + 5 = <%=Add(4,5)%>

If you request this page, using the default settings of ASP.NET (by default, trace output is not enabled), you would see the following result in the browser:

Call the Add routine: 4+5=9

Think of tracing as 'debug mode' for ASP.NET applications, since tracing code can be left in your scripts and when tracing is disabled, the trace statements are simply ignored.

Viewing Trace Output

To view the results of the

Trace.Write statements, you have two options:

Enable page tracing.

Enable application tracing.

Once tracing is enabled, by default the results are only presented to local clients – this is configurable, as you will see in a moment.

Enable Page Tracing

You can enable page tracing by adding a directive to the top of the ASP.NET Page:

<%@ Page Trace="true" %> 
<Script runat="server"> 
Public Function Add(a As Integer, b As Integer) As Integer 
Trace.Write("Inside Add() a: ", a.ToString()) 
Trace.Write("Inside Add() b: ", b.ToString()) 
Return a + b 
End Function 
</Script> 
Call the Add routine: 4 + 5 = <%=Add(4,5)%> 

This will add a trace output to the bottom of the requested page. Included with this output, as shown in Figure 13-6, are our

Trace.Write outputs:

Figure 13-6:

Enable Application Tracing

Adding

Trace="true" statements to the top of ASP.NET pages isn't difficult, but what if you had a larger application consisting of several ASP.NET pages? Or, what if you wanted to trace the output of your application and view the results, but at the same time not output the trace section at the end of each page? Application tracing allows you to accomplish all of this.

You can enable application tracing by creating a

web.config file with trace settings in it for your web application:

<configuration>
<system.web>
<trace 
enabled="true" 
requestLimit="10" 
pageOutput="false" 
traceMode="SortByTime" 
localOnly="true" 
/>
</system.web>
</configuration>

You can set the

enabled flag to

true (the inherited

machine.config default is

false ), request the page, and then use a special tool to view the application traces;

Trace.axd as shown in Figure 13-7:

Figure 13-7:

Trace.axd is a special HTTP Handler used to view trace output for an application. We will discuss this tool, tracing, and the

Trace object in more detail in Chapter 22. Let's turn our attention to the configuration settings found in the

web.config file we created.

Trace Configuration Settings

The

<trace> section within the configuration file provides us with some additional options not available when enabling tracing on a page. These options include:

enabled :This option can be set to

true or

false . Tracing is enabled or disabled at an application-level. If you set

enabled to

"false" , page tracing is still supported using the

Trace directive discussed earlier. This value is set to

false by default.

enabled="[true | false]" 

requestLimit :The total number of trace requests to keep cached in memory on a per application basis. Tracing exposes a special resource,

trace.axd , used to view trace output when

pageOutput is set to

false . By default, the value of

requestLimit is

10 .

requestLimit = "[int]" 

pageOutput :When tracing is enabled through the configuration file, the administrator is given the option to either enable or disable tracing on each page.

pageOutput tracing enables details to be traced for every page within an application. However,

pageOutput tracing may be turned off while application level tracing is still enabled (

enabled = "true" ). This keeps trace requests in memory such that they are available via

trace.axd but not within the output of a page. By default,

pageOutput is set to

false .

pageOutput = "[true | false]" 

traceMode :The

tracemode setting gives control over how trace detail information is output. Data may be sorted by time or category, where category is either the settings made by the system or the

Trace.Write settings enabled by the developer. By default,

traceMode is set to

SortByTime .

traceMode = "[SortByTime | SortByCategory]" 

localOnly :When tracing is enabled, the

localOnly flag determines whether the trace output is to be displayed only to local requests (those made through http://localhost) or for any request. Since tracing is best used as a debug tool during development, it is suggested that the default setting (

true ) be left as is.

localOnly = "[true | false]" 

Tracing is a great tool for debugging applications during development. Tracing should not, however, be enabled for deployed applications. When tracing is enabled, it consumes resources, whereas applications should be kept as lean and mean as possible. This does not mean that you need to remove the

Trace.Write statements from your code. When tracing is not enabled, these statements are ignored and do not affect the performance of the application.

For deployed applications, the recommendation is to use the Windows Event Log for application logging/tracing. A sample use of the Windows Event Log is shown for the

Application_OnError event discussed in the previous chapter.

If you did any amount of coding in ASP, you will no doubt remember those helpful error codes, such as

0x800A01A8 . ASP.NET makes some dramatic improvements on the level of detail available when errors occur, however, we don't always want that type of rich data displayed to end users. With ASP.NET's custom errors configuration option, we can control how ASP.NET displays application error messages.