Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)

2017-07-07 02:10:07

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

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:

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.