Using Trace Output

Implementing every possible event routine is useful for getting an overall picture of when events occur— and it's the only way to step through the Global.asax events, but it isn't very efficient. Another way to get a good overall picture is to enable tracing. Tracing collects internal execution data and formats it so that you can get a good picture of what's going on in your page or application. You can enable tracing for a single page or for an entire application, and you can control whether tracing occurs only when you run the application locally (on the server machine) or remotely (traces requests from any machine). Enabling tracing at the application level also enables page-level tracing.

Tracing is better experienced than described. Here's how to enable tracing for your entire application:

1. Open the web.config file and scroll down until you see this line:

<trace enabled="false" requestLimit="10"

pageOutput="false" traceMode="SortByTime" localOnly="true" />

2. Change the line so it reads as follows:

<trace enabled="true" requestLimit="10"

pageOutput="true" traceMode="SortByTime" localOnly="false" />

3. Save the web.config file.

The changes enable tracing throughout the application (trace enabled="true") and tell the ASP.NET engine to format the trace output, append it to the page output (pageOutput="true"), and trace all requests, both those from the server machine itself and those from remote computers

(localOnly="false").

To test the output, create a new Web Form named ch9-2.aspx and change the default form id attribute value to "Form1". Don't add any controls or code to the page, but set it as the start page. Tracing works regardless of which page you have set as the start page, but the output from a Web Form can interfere with the trace output (depending on the layout mode). Using a blank Web Form makes the trace information clean. Now run the application. You'll see output similar to Figures 9.8, 9.9, 9.10, and 9.11—tracing produces several screens of information.

Note Tracing is a debugging operation. Unlike Debug statements, which are not included when you compile your application in Release mode, trace statements are compiled in Release mode. Trace operations execute at runtime, so tracing can slow down your application considerably. However, you can leave trace statements in your page and disable tracing, which causes the ASP.NET engine to ignore the statements.

iK^qusil Uet.3* |

Piiquait ! rrci:dinq:

JLOl/JM? 1L: 3+: M AM LnKcdn i JTT ej

Rnquntt l^pn , Ul-olu-fc Oodc: r mjp»>nil C r*£DtfcK|.

Inc-ori» (-.Tr-O]

1 lr.sct Informrrtion J

i liriim t,

Me iv&**

r rnmllntCii

ln«nliiil(ij

mms-: paq * a?i". paqr uacp^q» ai:-. pa-;r a»-: ptqr

Brqn In' Cr-d prt

Bi-qn Frrt>r-:rr End Frp^j-Kto-Bc-qn Sh/t/flvS-rj1* End

DC-3n CflTiJcr Cnd t-rrcrr

a ccitic a o: : *t * a a a ccmtcc a tcmns a ecu

O.WJ D.0DWG7 D.DC + LM

Id

■jTi'dni J4.-* frftlai :-ncSu*:in.i

__PAGE

in

siilpir-.V.-ai- >Ji.^aaHiic«C jiPcLrlrrsCcr troj 5 vi.ltm.'iVit- I -IIrrt»Ir.Ir=--. firifom Eyiln.Wib UJ.Lftv-dZarAicI

E ill IIT,.Wm b Ul. H?« b>: on I r=> 1.5 j-; h= r

Syrlani.Wa* t'l.jKird^Mtrtl S* 1 lim.Wi^ UJ..fti 'ilZanfcid

siilpir-.V.-ai- >Ji.^aaHiic«C jiPcLrlrrsCcr troj 5 vi.ltm.'iVit- I -IIrrt»Ir.Ir=--. firifom Eyiln.Wib UJ.Lftv-dZarAicI

E ill IIT,.Wm b Ul. H?« b>: on I r=> 1.5 j-; h= r

Syrlani.Wa* t'l.jKird^Mtrtl S* 1 lim.Wi^ UJ..fti 'ilZanfcid

Figure 9.8: Trace output with tracing enabled in the web.config file (screen 1)

MM itt-

iptiioil Snif

MM itt-

firfM!

v-sJM"

tfn

tWi-j^ fi-r -r.ln.lti«

T ft*

'.-■■ • it.™ 1

a

pageic^ 1 fr

et ii

EHIMtilr^i

lart miiiA

Icookle« Coilecifcn

VfllOt

ColKfloo

*r,us VBMilfwjrt

MM^+C (Cl¥f^ifclf 4 D. l|T 1.C: Q)124-il "O Cufi 19.11:93

Ctri-jHTCr Mieii

*r,us VBMilfwjrt

MM^+C (Cl¥f^ifclf 4 D. l|T 1.C: Q)124-il "O Cufi 19.11:93

Figure 9.9: Trace output with tracing enabled in the web.config file (screen 2)

ESSE

CEi-T FL^Cl CEfTJHi.il CEET j-E

CETT «fItTrEiLI2! CECT iil-lnJJ.Mtia CECT ({nut liEirta

«■rn «BfjteillJliniDiaLl^lnniMll

r*Hi* ttBftMTjfc«K^l^lg^twtftf^cWii liJBjMtjtM ,r„i «OJ l^i |J ([jv^jn It ? 4 0. ».-.n,^ MT 1 C. $511 Lti -£T .■ J: P >¡13}

liaHC

KVM'JWH

Figure 9.10: Trace output with tracing enabled in the web.config file (screen 3)

Figure 9.11: Trace output with tracing enabled in the web.config file (screen 4)

As you can see, tracing is much simpler than writing Response.Write statements or loops to display cookies, header variables, or Request.Server variables. For production applications, you should never enable tracing to remote machines; instead, set the trace attribute (localOnly="true") to limit tracing to requests from the local (server) machine itself; otherwise, the trace information will appear on your users' screens.

While tracing output to the screen can be extremely useful, it doesn't work well with pages that have output formatted in GridLayout mode and that target CSS-enabled browsers. ASP.NET creates those pages using absolute positioning, which means the page output appears on top of the trace information (which is not formatted with absolute positioning). For these pages, which will probably represent the bulk of your ASP.NET Web Forms, set the pageOutput trace attribute to false (pageOutput="false"). Doing this doesn't disable tracing; it simply switches the trace output to a trace utility named trace.axd that ASP.NET creates in the root directory for your application. Trace.axd is an HttpHandler that intercepts the request and displays the trace results from memory.

The only way to view the trace data is to request it from a browser. For example, run your application with the Web Form ch9-2. Refresh the page several times and then type the URL http://localhost/CSharpASP/trace. axd into your browser (you may need to adjust the URL to point to your local CSharpASP application root). You'll see a page like that in Figure 9.12.

Figure 9.12: Viewing trace output via the trace.axd HttpHandler

The trace listing has one entry for each traced request, up to the number of requests specified by the requestLimit attribute in the trace element in your web.config file.

<trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="false" />

Click the View Details link to view the trace output for that request. The trace output itself is identical to the trace output shown earlier in Figures 9.8 through 9.11, so I won't repeat it here.

The tracing engine stops tracing after it reaches the limit set by the requestLimit attribute—tracing doesn't work in a round-robin fashion. Instead, the attribute value controls the total number of traced requests. After reaching the limit, you can clear the trace using the Clear Current Trace link in the upper-right corner of the trace.axd page.

You don't have to trace-enable your entire application. You can enable and disable tracing for any individual page by adding the trace attributes to the @Page directive. For example, restore the original web.config trace element settings to disable application-level tracing:

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />

Open the ch9-2.aspx file in the editor, and add a trace="true" attribute to the @Page directive.

Note The trace attributes requestLimit, pageOutput, and localOnly are not supported at the page level, only in the web.config file.

Save and run the Web Form. You'll see the trace output in your browser. You can remove the trace="true" attribute or set the attribute value to "false" to disable tracing. You should experiment with tracing—especially if you've worked with classic ASP and have old debug code to look at, because tracing shows you many of the values that you had to code by hand in classic ASP. For now, leave tracing enabled for the ch9-2 Web Form; you'll need it in the next section.

Was this article helpful?

0 0

Post a comment