第 129 页

fiGure 42-6

JavaScript breakpoints have the same functionality as standard breakpoints. This

includes setting conditions, hit counts, or even running a macro as part of a

tracepoint.

When the debugger hits a breakpoint, it

pauses execution and displays the HTML

code that has been rendered on the client, as

shown in Figure 42-7. This provides a true

debug experience, because it includes all

client-side elements such as the ViewState and

server controls rendered in HTML.

Visual Studio 2010 also has comprehensive

watch visualizers for client-side elements.

Figure 42-7 demonstrates this with a tooltip

that shows the properties and methods of the

document object.

It is also possible to set both client-side

JavaScript breakpoints and Visual Basic or C# server-side breakpoints at the same time on the

same page. This enables you to step through both server-side and client-side code in a single

debug session.

debugging dynamically Generated Javascript

Several scenarios exist where ASP.NET sends down to the client JavaScript that has been

dynamically generated on the server. For example, the ASP.NET AJAX controls such as the Update

fiGure 42-7

Debugging silverlight .

879

Panel will generate client-side JavaScript files that are actually

stored as resources in the ScriptManager control.

When you are running a web application in Debug mode, the

Visual Studio Solution Explorer shows a list of all the script

references that the page you are debugging has loaded, as shown

in Figure 42-8. Double-clicking any of the links under the Script

Documents node displays the JavaScript code and enables you to

set breakpoints within those scripts.

debugging asP net aJax Javascript

ASP.NET AJAX provides both Debug and Release versions of its

client JavaScript libraries. The Release version is optimized for

performance and minimizes the size of the JavaScript that must be

downloaded to the client. The Debug version is more verbose and

provides additional debugging features at runtime, such as type and

argument checking.

If debugging is enabled in the web.config file, ASP.NET AJAX uses a debug version of the client

libraries. You can also enable the debug version on a per-page basis by setting ScriptMode=”Debug”

on the ScriptManager control.

ASP.NET AJAX also includes the Sys.Debug class, which can be used to add debug statements

to your client JavaScript. This class can be used to display the properties of objects at run time,

generate trace messages, or use assertions.

debuGGinG silVerliGht

Visual Studio 2010 includes a native debugger

that makes it easy to debug Silverlight applications.

When you create a new Silverlight application,

Visual Studio prompts you either to generate an

HTML test page to host the Silverlight application,

or to utilize an existing or new web project, as

shown in Figure 42-9.

In Figure 42-9, we’ve chosen to create a test page

that hosts the Silverlight application in the web

application project that is part of the existing

solution, and to enable Silverlight debugging in this

web application. If you select either of the other

two options, you will not need to perform any

additional steps to enable Silverlight debugging.

fiGure 42-8

fiGure 42-9

880 .

chaPter 42 debugging Web ApplicATionS

You can always enable or display support for Silverlight debugging in an existing web application

project under the Web option page of the project properties.

Once the Silverlight debugger is enabled, you are able to set breakpoints in the code-behind class

files of the XAML pages. When the breakpoint is encountered during debugging, the session pauses

and displays the current line of code, as shown in Figure 42-10. You will be able to step through the

code, view the call stack, and interrogate the properties of objects, just as you would with any Web

or Windows Forms application.

The only major limitations with Silverlight debugging are that Edit and Continue are not supported

and JavaScript debugging is disabled.

fiGure 42-10

tracinG

In addition to actively debugging your web applications when things go wrong, you can also

implement ASP.NET tracing functionality to look at the information produced in an individual

page request. Using tracing enables you to add debug statements to your code that are only viewable

when viewing locally; when the web application is deployed to the remote server, users do not see

the trace information.

Trace information can include variables and simple objects to help you determine the state of the

specific request and how it was executed. Note that ASP.NET tracing is different from using

the Trace class in normal Windows applications in that its output is produced on the actual

ASP.NET web page or in a standalone trace viewer, rather than the output windows that Trace

commands use.

Tracing .

881

Page-level tracing

To implement page-level tracing, you simply need to include a trace attribute in the @Page directive

at the top of the page you want to trace. A simple ASPX page with tracing activated might look like

the following:

<%@ Page Language="C#" AutoEventWireup="true" Trace="true"

TraceMode="SortByCategory" CodeBehind="ShowTrace.aspx.cs"

Inherits="CSWebApp.ShowTrace" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>Trace Example Page</title>

</head>

<body>

<form runat="server">

<div>Hello!</div>

</form>

</body>

</html>

In addition, you can specify how the tracing messages associated with the page request should

appear by using the TraceMode attribute. Set this to SortByTime to output the tracing messages in

the order that they were produced, or SortByCategory to categorize them into different message

types. Figure 42-11 shows the trace output for the sample page defined in the previous code when

sorted by category.

fiGure 42-11

882

.

chaPter 42 debugging Web ApplicATionS

application-level tracing

Application-level tracing can be enabled through the web.config file. Within the system.web

node, you need to include a trace node that contains the attribute enabled with a value of true.

When using application-level tracing, you can control how the tracing is produced through the

pageOutput attribute. When set to true, you receive the tracing information at the bottom of

every page (similar to how it appears in Figure 42-11), whereas a value of false ensures that the

tracing information never appears on the page, and is instead only accessible through the Trace

Viewer (covered later in this chapter). You can also restrict the amount of information to trace with

the requestLimit attribute. Including a trace node for the web.config file you saw earlier in this

chapter results in a configuration like the following:

<?xml version="1.0"?>

<configuration>

<system.web>

<compilation debug="true" targetFramework="4.0" />

<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">

<error statusCode="403" redirect="AccessDenied.html" />

<error statusCode="404" redirect="PageNotFound.html" />

</customErrors>

<trace enabled="true" pageOutput="false" traceMode="SortByCategory"/>

</system.web>

<system.webServer>

<modules runAllManagedModulesForAllRequests="true" />

</system.webServer>

</configuration>

</system.web>

</configuration>

trace output

Tracing output is voluminous. The simple Hello page defined earlier produces almost three full

printed pages of information, including the following categories of data:

.

Request Details: The specific details of the current session, time of the request, what type of

request it was, and the HTTP code that is returned to the browser.

.

Trace Information: A full listing of each event as it begins and then ends, including the

amount of time taken to process each event.

.

Control Tree: A listing of all controls defined on the page, including the page object itself,

as well as HTML elements. Each object also has a size listed, so you can determine whether

any abnormal object sizes are affecting your application’s performance.

.

Session State and Application State: These two lists show the keys and their values for the

individual session and the application overall.

.

Request Cookies Collection and Response Cookies Collection: A list of any known

ASP.NET request and response cookies on the system that your application may be able

to access.

Tracing .

883

.

Headers Collection: A list of the HTTP headers included in the page.

.

Response Headers Collection: The HTTP headers associated with the response, indicating

what type of object is being returned.

.

Form Collection: A list of any forms defined in the page.

.

Querystring Collection: A list of any query strings used in the page request.

.

Server Variables: A list of all server variables known to the ASP.NET server and application

you’re currently executing.

As you can see, when tracing is implemented for a web page or application, you gain access to

an enormous amount of information that you can then use to determine how your application is

performing. You can see whether problems exist in the various collections in the way of missing or

extraneous data, as well as analyze the Trace Information list to determine whether there are any

abnormally long processing times for any specific events.

the trace Viewer

The Trace Viewer is a custom handler included in your web application when you have application

tracing activated. When tracing is being reported at the application level, you can navigate to this

page and view all page tracing output as it occurs. To view the Trace Viewer, browse to the

trace.axd page in the root directory of your web site.

The Trace Viewer provides a summary table of all requests made in the application, along with the

time the request was made and the HTTP status code returned in the response. It also provides a

link to detailed information for each request (which is the same information that you can see on

a page trace discussed earlier), as shown in Figure 42-12.

fiGure 42-12

884 .

chaPter 42 debugging Web ApplicATionS

custom trace output

You can supplement the default trace information with your own custom-built trace messages, using

the Trace.Warn and Trace.Write methods. Both have the same set of syntactical overloads, and

the only real difference is that messages outputted using the Warn method are displayed in red text.

The simplest form for these commands is to include a message string like so:

Trace.Warn("Encountered a potential issue")

However, you can categorize your warnings and messages by using the second and third forms of

the methods, including a category and optionally an error object as well:

Trace.Warn("MyApp Error Category", "Encountered a potential issue", myAppException)

health MonitorinG

ASP.NET includes a built-in framework for generating and capturing events for the purposes of

monitoring a web application. This feature, called Health Monitoring, allows you to become more

proactive in managing your production web applications, enabling you to be notified as soon as a

problem occurs.

The Health Monitoring provides much more than just alerting you that an

exception has occurred. You can also instrument your code and generate alerts

for custom events; for example, if a user fails to log on or attempts to access a

restricted area.

Health Monitoring is enabled through the web.config file. Within the system.web node you need

to include a healthMonitoring node that contains the attribute enabled with a value of true.

This node will also contain the details of which provider to use and rules for handling different

events. Extending the web.config file from earlier, we have created an SMTP provider and a rule

that e-mails the details of any unhandled exceptions to the webmaster. The web.config file has

also been modified to include a reference to an SMTP server, so that the provider can send the

e - mail notifications.

< ?xml version="1.0"? >

< configuration >

< system.web >

< compilation debug="true" targetFramework="4.0" / >

< customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm" >

< error statusCode="403" redirect="AccessDenied.html" / >

< error statusCode="404" redirect="PageNotFound.html" / >

< /customErrors >

< trace enabled="true" pageOutput="false" traceMode="SortByCategory"/ >

< healthMonitoring enabled="true" >

< providers >

< add name="SMTPProvider"

type="System.Web.Management.SimpleMailWebEventProvider"

Health Monitoring .

885

from="server@yourdomain.com"

to="webmaster@yourdomain.com"

subjectPrefix="Exception on WebApp:"

bufferMode="Critical Notification"/>

</providers>

<rules>

<clear />

<add name="All Errors Default"

eventName="All Errors"

provider="SMTPProvider" />

</rules>

</healthMonitoring>

</system.web>

<system.net>

<mailSettings>