第 122 页

Culture=neutral, PublicKeyToken=null" / >

< data name="Manager" type="CustomResourceType.Person, CustomResourceType" >

< value > Joe,175,69.5 < /value >

>data/<

Creating custom resource types is a difficult process, because Visual Studio 2010

doesn’t refresh your TypeConverter after it has been loaded the first time. You

can either strongly name the assembly in which the TypeConverter is located

and increment the version number each time you change it, or you will have to

restart Visual Studio in order for the changes to take effect.

summary .

823

suMMary

This chapter demonstrated how important XML resource files are in building an application that

can both access static data and be readily localized into foreign languages and cultures. The rich

user interface provided by Visual Studio 2010 enables you to easily add resources such as images,

icons, strings, audio files, and other files to an application.

The built-in support for localizing forms and generating satellite assemblies empowers developers

to write applications that can target a global market. You have also seen that the user interface

provided within Visual Studio 2010 is extensible, meaning that you can modify it to interact with

your own custom resource types.

PART IX

debugging

. Using the Debugging Windows

. Debugging with Breakpoints

. DataTips, Debug Proxies, and Visualizers

. Debugging Web Applications

. Advanced Debugging Techniques

: chaPter39

: chaPter40

: chaPter41

: chaPter42

: chaPter43

39

Using the Debugging Windows

what’s in this chaPter?

.

Learning basic debugging concepts in Visual Studio, including

breakpoints and DataTips

.

Understanding the debugging windows in Visual Studio

.

Using and unwinding exceptions during a debug session

Debugging an application is one of the more challenging tasks developers have to tackle, but

correct use of the Visual Studio 2010 debugging windows will help you analyze the state of the

application and determine the cause of any bugs. This chapter examines the numerous windows

available in Visual Studio 2010 to support you in building and debugging applications.

the code window

The most important window for debugging purposes is the code window. With the capability

to set breakpoints and step through code, this window is the starting point for almost all

debugging activities. Figure 39-1 shows a simple snippet of code with both a breakpoint and

the current execution point visible.

fiGure 39-1

828 .

chaPter 39 uSing The debugging WindoWS

breakpoints

The first stage in debugging an application is usually to identify the area that is causing the error

by setting a breakpoint and gradually stepping through the code. Setting breakpoints and working

with the current execution point are covered in more detail in the next chapter. Although you can’t

see the color in Figure 39-1, breakpoints are marked in the code window with a red dot in the

margin of the page and red highlighting of the code itself.

When a breakpoint is encountered, the current execution point is marked with a yellow arrow in the

margin and the actual code is also highlighted in yellow. As discussed in the next chapter, this marker

can be dragged forward and backward to control the order of execution. However, this should be

done sparingly because it modifies the behavior of the application.

datatips

After hitting a breakpoint, the application is paused, or is in Break mode. In this mode, you can

retrieve information about current variables simply by hovering your mouse over the variable name.

Figure 39-1 shows that the value of the mCustomerName variable is currently “Dante Hicks.” This

debugging tooltip is commonly referred to as a DataTip, and can be used to view not only the values

of simple types, such as strings and integers, but also to drill down and inspect more complex object

types, such as those made up of multiple nested classes.

DataTips are used to both query and edit the value of a variable.

In Chapter 41 you learn how the layout of this DataTip can be customized using type proxies and

type visualizers.

the breakPoints window

When debugging a complex issue, it is possible to set numerous breakpoints to isolate the problem.

Unfortunately, this has two side effects. One, the execution of the application is hampered, because

you have to continually press F5 to resume execution. Two, and more significantly, the execution

of the application is slowed considerably by the presence of conditional breakpoints, which enable

you to specify an expression that is executed to determine if the application should be paused.

The more complex the breakpoint conditions are, the slower the application will run. Because

these breakpoints can be scattered through multiple source files, it becomes difficult to locate and

remove breakpoints that are no longer required.

The Breakpoints window, shown in Figure 39-2, is accessible via Debug . Windows . Breakpoints

and provides a useful summary of all the breakpoints currently set within the application. Using this

window, breakpoints can easily be navigated to, disabled, and removed.

The output Window .

829

fiGure 39-2

Figure 39-2 shows two currently active breakpoints in the Customer.cs file. The first is a regular

breakpoint with no conditions. The second has a condition whereby the application will break only

if the mAccountBalance variable has a value less than 1000. This condition is also in bold, because

the application is currently in Break mode at that breakpoint.

The Breakpoints window, like most other debugging windows, is made up of two regions: the

toolbar and the breakpoint list. Several new functions have been added to the toolbar in Visual

Studio 2010, including search, and import and export of breakpoints. These functions are explained

further in Chapter 40.

Each item in the breakpoint list is represented by a checkbox that indicates whether the breakpoint

is enabled, an icon and breakpoint descriptor, and any number of columns that show properties of

the breakpoint. The columns can be adjusted using the Columns drop-down from the toolbar. You

can set additional breakpoint properties by right-clicking the appropriate breakpoint.

the outPut window

One of the first debugging windows you will encounter when you run your application for the

first time is the Output window. By default, the Output window appears every time you build

your application, and shows the build progress. Figure 39-3 shows the successful build of a

sample solution. The final line of the Output window indicates a summary of the build, which in

this case indicates three successfully built projects. In the output there is also a summary of the

warnings and errors encountered during the build. In this case there were no errors, but there

were three warnings. Although the Output window can be useful if for some reason the build fails

unexpectedly, most of the time the errors and warnings are reported in the Error List.

fiGure 39-3

830 .

chaPter 39 uSing The debugging WindoWS

The Output window has a secondary role as the standard output while the application is running. The

drop-down on the left of the toolbar can be used to toggle between output sources. Figure 39-3 shows

the output of the build, but as you perform other activities in Visual Studio additional entries are

created in the drop-down list. For example, when you run your application in Debug mode, Visual

Studio creates an entry called Debug, which displays any messages that either the run time or your

code has emitted using Debug.Write or Debug.WriteLine. Likewise, a Refactor entry is created to

show the results of any recent refactoring operation that was performed.

The output from external tools such as .bat and .com files is normally displayed

in the Command window. The output from these tools can also be displayed in

the Output window by setting the Use Output Window option in the Tools .

External Tools dialog box.

The other icons on the toolbar, in order from left to right, enable you to navigate to the source of a

build message, go to the previous message, go to the next message, clear the window contents, and

toggle word wrapping for the Output window.

the iMMediate window

Quite often when you are writing code or

debugging your application, you will want

to evaluate a simple expression either to test

a bit of functionality or to remind yourself

of how something works. This is where the

Immediate window (Debug . Windows .

Immediate) comes in handy. This window

enables you to run expressions as you type

them. Figure 39-4 shows a number of

statements — from basic assignment and

print operations through to more advanced

object creation and manipulation.

Figure 39-4 shows a new Customer object

being created in a C# project within the

Immediate window. Within a Visual Basic

project you can’t do explicit variable

declaration (for example, Dim x as Integer). Instead it is done implicitly using the assignment

operator.

One of the more useful features of the Immediate window is that it can be used while you are

writing code. When you create new objects in the Immediate window at design time, it invokes the

constructor and creates an instance of that object without running the rest of your application.

fiGure 39-4

The Watch Windows .

831

If you invoke a method or property that contains an active breakpoint, Visual Studio changes

to Debug mode and breaks at the breakpoint. This is especially useful if you are working on a

particular method that you want to test without running the entire application.

The Immediate window supports a limited form of IntelliSense, and you can use the arrow keys to

track back through the history of previous commands executed.

IntelliSense is only supported in the Immediate window when running in Debug

mode, not during design-time debugging.

The Immediate window also enables you to execute Visual Studio commands. To submit a

command, you must enter a greater than symbol (>) at the start of the line. There is an extremely

large set of commands available; in fact, almost any action that can be performed within Visual

Studio is accessible as a command. Fortunately, IntelliSense makes navigating this list of available

commands a little more manageable.

There is also a set of almost 100 predefined

aliases for commands. One of the more

well-known aliases is “?”, which is a

shortcut for the Debug.Print command

that prints out the value of a variable.

You can see the full list of predefined

aliases by entering > alias, as shown in

Figure 39 - 5.

the watch windows

Earlier in this chapter you saw how DataTips can be used in the code window to examine the

content of a variable by hovering the mouse over a variable name. When the structure of the object

is more complex it becomes difficult to navigate the values using just the DataTip. Visual Studio

2010 has a series of Watch windows that can be used to display variables, providing an easy-to-use

interface for drilling down into the structure.

quickwatch

The QuickWatch window (Debug . QuickWatch) is a modal dialog that can be launched by

right-clicking the code window. Whatever you have selected in the code window is inserted

into the Expression field of the dialog, as shown in Figure 39-6 where a Customer object is

visible. Previous expressions you have evaluated appear in the drop-down associated with the

Expression field.

fiGure 39-5

832 .

chaPter 39 uSing The debugging WindoWS

fiGure 39-6

The layout of the Value tree in the QuickWatch window is similar to the DataTip. Each row

shows the variable name, the current value, and the type of object. The value of the variable can

be adjusted by typing in the Value column.

Use the Add Watch button to add the current expression to one of the Watch windows. These are

variables to be continuously watched.

watch windows 1–4

Unlike the QuickWatch window, which is modal and shows a variable value at a particular

execution point, the Watch windows can be used to monitor a variable value as you step through

your code. Although there are four Watch windows, a single window is sufficient in most cases.

Having four separate windows means that you can have different sets of variables in the different

windows, which might be useful if you are working through a more complex issue that involves

multiple classes.

Figure 39-7 shows an Order and Customer

class in a Watch window (Debug .

Windows

. Watch 1 to Watch 4). Similar to both

the QuickWatch window and the DataTips

discussed previously, the user interface can

be used to drill down into more complex

data types. fiGure 39-7

The Code execution Windows .

833

Additional variables to be watched can be added either by typing into the Name column on an

empty line or by right-clicking the variable in the code window and selecting Add Watch from the

context menu.

autos and locals

The Autos and Locals windows are two special Watch windows in which the variables are

automatically added by the debugger. The Autos window (Debug .

Windows . Autos) contains

variables that are used in the current, preceding, and future lines of code. Similarly, the Locals

window (Debug .

Windows . Locals) shows all variables used in the current method. Other than

being automatically generated, these windows behave the same as the Watch windows.

the code execution windows

In addition to inspecting the contents of variables during a debugging session, it is essential that

you carefully evaluate the logic of your code to ensure that everything is executed in the order

that you expect. Visual Studio 2010 has a group of debugger windows that show exactly what was

loaded and being executed at the time you paused the program execution. This allows you to better