Visual Studio Preparation

Visual Studio has a set of debugging options that affect all types of projects. You can find these options by selecting Tools ’ Options. There are four pages of options, most of which you can leave at their default settings. However, you should understand some of these options in detail, because they can have a big effect on the efficiency of your debugging sessions. This section looks at the more important options.

General Debugging Options

From the Tools ’ Options menu item, you can find the major settings that control the debugger's behavior on the Debugging ’ General property page. Figure 4-1 shows the options that you can manipulate from this page.

Figure 4-1: The General debugging property page

The "Hexadecimal display" option allows you to display variables in hexadecimal format in the debugging windows such as Locals and Autos. Normally, you won't want to select this option, but it might be useful if you're doing a lot of mathematical work.

"Allow hexadecimal input without prefix" is another setting that you probably don't want to select unless you're doing some significant hexadecimal work. When selected, this option allows you to enter values as direct hexadecimals, without using the ampersand (&) prefix.

There are many reasons why the debugger might not be able to locate source code during a debugging session. One reason occurs when you don't actually have available source code for part of your application, perhaps for a process written by another developer. Another possibility is a security problem, such as when you don't have the right permissions to access a Web application's virtual directory. Whatever the cause, you can ask the debugger to "Show disassembly if source is not available" by selecting the option of the same title. For some reason that's unclear to me, this option is disabled by default. You should also be aware that there are some circumstances where the debugger can't even display the disassembly ”for instance, when you're debugging a script and stop on a breakpoint while there are no threads in your program.

You should usually select the "Warn if no symbols on launch" option. It's most useful when you mistakenly try to debug a version of your program that was built in release mode. Without this warning, you can become rather confused when none of your breakpoints are hit.

When you debug your application, the Visual Studio debugger tries to find a source file for each of the binary executables being debugged . The first place it looks is the folder containing the binary, and then it searches through the paths defined on your solution's Common Properties ’ Debug Source Files page. Because it's possible for the debugger to find ambiguously named or versioned files, it sometimes prompts you to confirm that it's found the correct source files. If you select the "Confirm correct file was found when finding source" option, the debugger has permission to confirm its guesses. If you don't select this option, the debugger just keeps quiet and hopes for the best. Selecting this setting is especially useful when you're debugging in a test or production environment, where the source is unlikely to live in the same folder as the binary.

Many of your applications, especially the distributed ones, are going to contain multiple execution processes. So when you break into an application with a breakpoint or by using the Break button, you want to either pause all of the processes in the application or pause just the single process that you're interested in. Selecting the "In break mode, only stop execution of the current process" option means that just the active debugger process is paused , leaving the rest of the application to continue normally. This can be very useful when one of the processes, such as a Web service, might be used by another application that would otherwise be frozen. Alternatively, you can choose to pause the whole application, which is most likely to be useful when you're investigating a problem that crosses multiple processes.

You should always leave the " Color text of current statement and breakpoints" option selected, as the colors are a great help in finding your way around the source window when you're stopped on a breakpoint.

Another option you should always select is "Use IntelliSense to verify breakpoints." This option allows you to hover over a breakpoint glyph in order to see information about that breakpoint, including the reason why the breakpoint won't be hit if that's applicable .

The "Allow property evaluation in variables windows" option tells the debugger to evaluate all object properties (i.e., members ) in the Autos, Locals, and Watch windows so that you can see their values. Although this option is shown as enabled in Figure 4-1, there are two good reasons to keep the option disabled during normal debugging. First, enabling this option can cause unexpected side effects when you have any of the previously mentioned debugging windows open . This is because the debugger automatically evaluates any property displayed in a debugging window by invoking it. This can have the effect of changing the normal execution path of your program, because the code in the property might not have been invoked if the program wasn't running under the Visual Studio debugger. It's really not advisable to have your program behave differently when it's running inside the debugger compared to when it's not. The second reason for disabling this option is when you're doing mixed-mode debugging with both managed and unmanaged code. Making multiple property evaluation calls across into unmanaged code can be very expensive in performance terms.

When you set a breakpoint in a client script, you normally want that breakpoint to be reflected in the corresponding Active Server page that is generated. Selecting the "Insert breakpoints in Active Server Pages for breakpoints in client script" option ensures that this behavior happens.

Edit and Continue Options

From the Tools ’ Options menu, the options on the Debugging ’ Edit and Continue property page allow you to control what the Visual Studio source editor does when you edit code during a debugging session. Figure 4-2 shows the options available on this page.

Figure 4-2: The Edit and Continue property page

Most of the options on this page aren't applicable to VB .NET programmers because Edit and Continue hasn't been implemented for the first version of VB .NET (or C#). However, you're allowed to edit your code, with the proviso that your program will continue running with its current code and will completely ignore any new code that you add until you restart the application. Selecting the "Allow me to edit VB files while debugging" option gives you this facility. Bear in mind that this can lead to some really confusing results because the code shown in the source window will no longer match the code being executed. I discuss a workaround for this in the "Coping Without Edit and Continue" section later in this chapter.

In the final frame on this page, you can choose what you want the debugger to do when you edit your VB source code during a debugging run. I recommend using the "Always ignore changes and continue debugging" option because this avoids the annoying message stating that changes won't be applied until after the application is restarted. If you're happy dealing with this message, select instead the "Warn me if I make changes" option.

Just-In-Time Debugging Options

From the Tools ’ Options menu, the Debugging ’ Just-In-Time property page shows you some options that affect the behavior of the Just-In-Time debugging process that I discussed in Chapter 3. Figure 4-3 shows this property page.

Figure 4-3: The JIT debugging property page

The options on this page allow you to enable or disable the types of code that can be debugged when a program crash is caught by the Just-In-Time debugger. You can specify the setting for managed code and for script. As I pointed out in Chapter 3, you need to have installed Visual C++.NET in order to specify the setting for native code.

Native Debugging Options

From the Tools ’ Options menu, the Debugging ’ Native property page (see Figure 4-4) shows you the debugging options available when you're debugging native Win32 code.

Figure 4-4: The Native debugging property page

If you're debugging Win32 objects that contain export tables, the "Load DLL exports" option will load those export tables. If you don't understand what this entails, you don't need to worry about this option except to deselect it because it has a performance overhead.

The "RPC debugging" option allows you to step into COM remote procedure calls when you're debugging COM components via COM Interop. You should enable this option if you're working with a distributed application that uses COM Interop.

Project Default Options (Visual Studio 2003 Only)

From the Tools ’ Options menu, the Debugging ’ Projects ’ VB Defaults property page shown in Figure 4-5 is only applicable if you're using Visual Studio 2003. This page allows you to specify the default Option Explicit and Option Strict settings for each new VB .NET project.

Figure 4-5: The VB Defaults property page

The first option on this property page allows you to specify the default Option Explicit setting for every new VB .NET project. Setting this option to "On" requires you to declare every variable in your code before you use it, and I recommend that you always use this setting. It behaves identically to Option Explicit in VB.Classic.

The second option allows you to specify the default Option Strict setting for each new VB .NET project. I advise you to ensure that this option is always set to "On" for absolutely every VB program you ever write. The "On" setting is applied to every new project and finds many type coercion and code ambiguity problems at compile time, as opposed to you having to wait for a runtime error.

The "Project Preparation" section later in this chapter has more detailed information about the effects of these settings.

Other Useful Visual Studio Settings

The final Visual Studio setting to enable is not really debugging related , but it displays line numbers within every source file. This is very useful for locating assertions and exceptions, both of which give you a line number, and it generally makes it easier for you to follow the setting of breakpoints and source code. To enable this setting, select Text Editor ’ All Languages ’ General from the Tools ’ Options menu item, and select the "Line numbers" option in the Display frame.

Now that you understand the Visual Studio settings, the next step is to look at the debug settings that you can set for a Visual Studio solution.