第 130 页

<smtp><network host="mail.yourdomain.com"/></smtp>

</mailSettings>

</system.net>

<system.webServer>

<modules runAllManagedModulesForAllRequests="true" />

</system.webServer>

</configuration>

Once this is in place, anytime an exception is generated and not handled, an e-mail is sent to the

specified address. This e-mail message contains a large amount of useful troubleshooting information,

including the exception details and stack trace. Figure 42-13 shows an example message.

fiGure 42-13

886 .

chaPter 42 debugging Web ApplicATionS

In addition to the SMTP provider, there is also an Event Log, WMI, and SQL Server provider. Quite

complex rules can be enabled to direct the notifications to one of more of these providers. If none of

these meet your needs, you can even write your own custom provider.

suMMary

With the combination of Visual Studio 2010 and ASP.NET server-side capabilities, you have a

wide array of tools to help you look after your web solutions. These features enhance the already

impressive feature set available with normal Windows application debugging, with web-specific

features such as JavaScript and Silverlight debugging, page- and application-level error handling,

and the capability to trace code, which you can use to monitor the way pages are being executed in

your web applications without interrupting your end users.

In addition, the ASP.NET Health Monitoring framework enables you to proactively manage your

production web applications by notifying you as soon as a problem occurs.

43

advanced Debugging

Techniques

what’s in this chaPter?

.

Adding debugging actions to your code with the Debug and Trace

classes

.

Learning techniques for debugging applications already running on

the local or remote computer

.

Debugging multi-threaded applications, SQL Server stored

procedures, and mixed-mode applications

As you’ve seen throughout the last several chapters, Visual Studio 2010 comes with a great variety

of ways to debug and run through your applications, including catching errors and displaying

them to you for action before the code executes too far; a number of techniques for effectively

debugging web applications; and other features, such as breakpoints and visualizing errors.

However, there is still more functionality to be found in Visual Studio that you can use to

customize your experience with debugging projects, databases, unmanaged code, and even the

.NET Framework itself. In this chapter you’ll find advanced techniques for debugging your

projects regardless of language or technology.

start actions

Visual Studio provides several ways to launch applications at the start of a debugging session.

For most projects the default start option will be sufficient, which in the case of a Windows

executable will launch the program directly. In the case of a web application, Visual Studio

opens the default web browser and loads the current page, or navigates to the root path of the

web application if there is no active page.

888 .

chaPter 43 AdVAnced debugging TechniQueS

In some scenarios you may want a different action to occur during a debugging session. For example,

you may need to always open a specific web page when the web application is started. In these

scenarios you can change the start options on the Debug or Web project property page. Figure 43-1

shows the start actions for a Windows Forms project.

fiGure 43-1

In addition to starting the project directly, you can also choose to start an external program that

presumably will subsequently call your project into the execution process. Alternatively, you can

choose to launch the default web browser on your system with a specific URL, again with the

assumption that the URL will ultimately invoke your project.

Often, applications are built with the capability to exhibit different behavior depending on command-

line arguments. If your project is of this variety and you need to test the different configurations, you

can use the Command Line Arguments textbox to specify which set of arguments is to be included in

the execution of the project. You should enter the command-line arguments in exactly the same way

you expect the end user to do so when that user is invoking your application once it has been deployed.

You can override the default directory from which the application should be executed by setting

the Working Directory option. This equates to the same setting when you edit a Windows shortcut.

In addition, you can also specify a different machine to control the debugging process of the

application by activating the Use Remote Machine option. Note that you will need to explicitly

specify the remote computer path, because it does not have an associated browse option.

The final section of the Debug page pertains to the different kinds of debugging that will be

performed during the execution of your application. By default, the only debugging process active

is the debugging of managed code inside the Visual Studio environment, but you can optionally

include native unmanaged code or SQL Server stored procedures. These debuggers are discussed

later in the chapter.

start actions .

889

The configuration and platform settings are available only when you have the

Show Advanced Build Configurations setting activated. You can find this in

the Projects and Solutions . General options page and it is on by default for all

environment configurations except for Visual Basic programmers.

The start actions for ASP.NET web applications are found on the Web property page for the project,

as shown in Figure 43-2. The default is to launch the web site with whichever page is currently open

in the code editor or web designer. This can be changed to always use a specific page or URL. The

other option is to start an external program or wait for a request from an external application. This

is particularly useful when debugging a web service that is invoked by another application.

fiGure 43-2

ASP.NET web application projects can also choose from one of three web server options. The

built-in Visual Studio Development Server is the most convenient, because it does not require

installation or configuration. Unlike IIS, the Visual Studio Development Server supports Edit

and Continue. The Custom Web Server option enables you to specify a remote web server to

debug against.

890 .

chaPter 43 AdVAnced debugging TechniQueS

debuGGinG with code

Three classes ship with the .NET Framework under the System.Diagnostics namespace that can be

used to build debugging support directly into your code — the Debug, Debugger, and Trace classes.

When used properly, these classes provide a very powerful way for you to interact with the debugger.

The functionality provided by all three of these classes is exposed through static/shared methods

and properties, which makes it easy to add them to your code.

the debugger class

The Debugger class provides programmatic access to certain debugger functions within Visual

Studio. For example, the following code snippet checks whether the application is running under a

debugger and, if not, launches one and attaches to the process:

c#

if (!Debugger.IsAttached)

{

Debugger.Launch();

}

Vb

If Not Debugger.IsAttached() Then

Debugger.Launch()

End If

When this code is executed while the application is running

normally outside Visual Studio, the program execution

pauses, and you are presented with a dialog box similar to

the one shown in Figure 43-3. Selecting a New Instance of

Visual Studio 2010 loads the application in Visual Studio

and continues executing the application in Debug mode.

the debug and trace classes

The Debug and Trace classes are used to output

debugging information and trace the execution path of

your application. Most of the properties and methods are

common across the two classes, which may seem redundant.

However, there is a key difference in the way these methods

are implemented and the results presented to you.

The Debug class should be used if you only need to output information while running in Debug

mode. The Trace class can be used if you want output in both the Debug and Release versions.

While you are debugging an application during development, both your tracing and debugging

output go to the Output window in Visual Studio. However, in Release mode, any Debug statements

will be suppressed by the compiler and not invoked during execution. This ensures that you can

include a large amount of debug code in your application without increasing the size or decreasing

the performance of your release code.

fiGure 43-3

Debugging with Code .

891

The ability to use Trace and Debug statements in different build confi gurations

is specifi ed through compiler directives. Within Visual Studio, you can enable or

disable these directives from the project properties pages. These settings are found

on the Build property page for C# projects, and under the Advanced Compiler

Options button on the Compile property page for Visual Basic projects.

Methods for Outputting Debug Messages : table43 - 1

The methods that are available to output debug messages in the Debug and Trace classes are listed

in Table 43-1.

Write

The text or string representation and an optional category

WriteIf

The text and an optional category, if the condition specified as an argument

evaluates to true

WriteLine

The text followed by a carriage return and an optional category

WriteLineIf

The text followed by a carriage return and an optional category, if the condition

specified as an argument evaluates to true

Method outPuts

You can also offset the output by increasing or

decreasing the indenting through the Indent and

Unindent methods.

You can use the Assert method on the Debug and

Trace classes to create an assertion, which tests

a condition that was specified as an argument. If

the condition evaluates to true, no action occurs.

If the condition evaluates to false, the assertion

fails. If you are running in Debug mode, your

program pauses execution, and a dialog box is

displayed, as shown in Figure 43-4.

Selecting Abort terminates the application

execution. Retry breaks at the statement and

Ignore continues execution.

While running in Debug mode, all output from the

Debug and Trace classes is displayed in the Output

window. However, with a Release build all trace

output is collected by a listener. A listener is simply

an object that receives trace output and writes it to an output device. An output device could be a

text fi le, Windows event log, or some other custom logging repository.

Finally, Trace Switches are available, which allow you to enable, disable, and filter tracing output.

Trace Switches can be declaratively enabled within the app.config file for an application.

fiGure 43-4

892 .

chaPter 43 AdVAnced debugging TechniQueS

debuGGinG runninG aPPlications

Sometimes you’ll need to debug an application that is running outside Visual Studio. Many reasons

exist for why you would want to do this, such as if a defect appears only when an application is

executed in production. Fortunately, Visual Studio provides a simple method for attaching and

debugging a Windows executable or web application that is actively running.

attaching to a windows Process

Attaching to a running Windows process is a fairly straightforward task in Visual Studio. Ideally,

you will have the original source code open in Visual Studio, in which case you will be able to debug

the process as if you had launched it in Debug mode from Visual Studio.

If you are debugging an executable without access to the source code, the

available debugging features are limited. If the executable was built without

debug information or symbols, available features are further limited and it is

unlikely that you will gain much useful information by debugging it in this way.

Therefore, it is recommended that when you perform a release build you should

in fact perform two builds: one with and one without debug symbols. The

symbols should be archived in a safe location so that they can be accessed if you

ever need to attach to a running process or debug a memory dump.

From the Debug menu, use the Attach to Process command. This displays the Attach to Process

dialog window (see Figure 43-5), from which you can browse all active processes. Locate the

application that you want to debug from the Available Processes list and click the Attach button.

fiGure 43-5

Debugging running applications .

893

Because attaching to an application requires these manual steps, it is not well suited if you are

trying to debug a problem that occurs during startup. Also, if you are debugging an application

that does not require any user input and finishes quickly, you may not have time to attach to it. In

both these scenarios it would be better to either launch the application in Debug mode from within

Visual Studio, or create a custom build with a Debug.Break() statement in the startup code of the

application.

Once you’ve finished debugging an attached process, you should always cleanly detach from the

process by selecting Debug . Detach All. You can also choose to end the application by selecting

Debug . Terminate All.

attaching to a web application

Attaching to an ASP.NET web application is almost as easy as attaching to a Windows application.

However, before you attach to a web application, you must ensure that it has debugging enabled by

editing the web.config file for the application. Locate the Compilation node within system.web

and set the debug attribute to true. The following listing shows a minimal web.config file with the

Debug option set, ready for attaching the debugger to the application:

< configuration >

< appSettings/ >

< connectionStrings/ >