Configuring the Debugging Environment

The Visual Studio .NET IDE provides much more control over the debugging process than what was available in Visual Basic 6. Although some features will be familiar, others have been enhanced, and there are new features to learn about.

This section covers Visual Studio .NET settings and tools to use during debugging, and specific considerations for debugging special types of applications.

The first change you will notice in the Visual Studio .NET IDE is the drop-down list on the main toolbar that enables you to select whether you want a Debug configuration or a Release configuration when you build your application.

The Debug configuration creates a PDB(program database) file that contains what are called debugging symbols for your executable. This file is found in the project’s \bin directory along with the executable file, and will have a .pdb filename extension. A Debug build will also cause extra information to be added to the executable file so that the debugger can stop at breakpoints and let you step through your executing code. The ability to do these things is necessary during the development phase, and you will typically use the Debug build throughout the development of your application.

When you are ready to create a version of the application that will be installed in a production environment, you should change this option and create a Release build. This type of build does not include the extra overhead needed to work with the debugger. If your solution is complex and consists of multiple projects, the Configuration Manager dialog box enables you to select Debug and Release build options on a project-by-project basis. Figure 8.1 shows the Visual Studio .NET IDE displaying the Configuration Manager dialog box. Also, note the toolbar for setting a Debug or Release build.

Figure 8.1: The Configuration Manager

Other settings that control debugging behavior for your Visual Studio .NET projects are found on the project Property Pages dialog box, shown in Figure 8.2. To access this dialog box, right-click the project name in the Solution Explorer and choose Properties from the menu.

Figure 8.2: The project Property Pages dialog box

If you click Configuration Properties and Debugging in the left pane of this dialog box, you will see several items in the right pane:

Start Action  This has three options. The Start Project option is used for standard Windows forms or console applications, which start up on their own. The Start External Program option enables you to specify another program, such as a testing application, to start running and make calls on your component. The Start URL option is used for XML Web services and enables you to specify a start URL.

Start Options  This section enables you to type in any arguments that would normally be entered at the command line for console applications, to specify a working directory, to specify that you are debugging on a remote server, or to specify that that you want to use Internet Explorer instead of the Visual Studio .NET internal web browser when debugging web applications.

Debuggers  This section enables you to include debugging for ASP.NET applications, unmanaged code, or SQL Server stored procedures.

Other settings pertinent to debugging are also found on the Configuration Properties, Build portion of this dialog box (see Figure 8.3). These include an output path for your executable and PDB file, and whether your compiled executable will include DEBUG and TRACE constants that determine whether output from Debug.Write and Trace.Write statements in your code are included in the compiled executable. Debug and Trace statements are covered in detail in the next section of this chapter, “Implementing Instrumentation and Tracing.”

Figure 8.3: The Build portion of the project Property Pages dialog box

Now let’s look at some of the features that are available while you are using the debugger from within the Visual Studio .NET IDE.

Configuring Debugging in ASP.NET Applications

For ASP.NET applications and XML Web services, the setting that controls whether debugging symbols are included in your compiled code is made in the web.config file. The following code snippet shows how this setting is formatted in the web.config file:

<configuration>    <system.web>       <compilation defaultLanguage="VB"          debug="true"          numRecompilesBeforeAppRestart="15">       </compilation>    </system.web> </configuration>

Be sure to set this to debug="false" when your application is ready to go into production, because enabling the debugging capability can adversely affect performance.

Running the Visual Studio .NET Debugger

The Visual Studio .NET debugger is running whenever you start your application from within the Visual Studio .NET IDE with a Debug build selected. While running within the IDE, your application will go into Break mode automatically whenever a runtime error is encountered. Alternatively, you can set breakpoints at specific locations in your code to control exactly when your application will enter Break mode.

While in Break mode, execution of your application is suspended at a specific line of code (the line where you set a breakpoint, or the line where an error occurred). You can use the debugging tools provided by Visual Studio .NET to find out detailed information about the state of your application, such as the current call stack or values of variables. When in Break mode, the Debug menu and toolbar give you access to these tools.

Next, you will learn about the debugging tools provided by Visual Studio .NET.

Setting Breakpoints

Breakpoints are an important debugging tool, by setting a breakpoint at a specific line of code you can control exactly at what point in program execution the debugger will go into Break mode. In Visual Studio .NET, breakpoints have been enhanced to provide more functionality than was available in the Visual Basic 6 IDE. Breakpoints can be saved with your solution (information about breakpoints is one type of information that is stored in the solution.suo file).

Breakpoints can also be conditional. In Visual Basic 6, when you set a breakpoint, it was hit every time that line of code was executed. In Visual Studio .NET, you can set conditions on each breakpoint that cause it to be hit (and program execution suspended), only if the condition is met. You can evaluate variable values or just specify that you want to break on the nth time that the line of code executes.

You can set breakpoints in various ways: by using the menu, toolbar, or keystroke shortcuts. The most direct way is to click on the left margin of the code editor window, next to the line of code where you want to set the breakpoint. A line of code with a breakpoint will be highlighted in the code editor. You can set breakpoints only on an executable line of code. You cannot set them on a comment or a simple variable declaration. Breakpoints can also be disabled, so that they will not be hit when code is executing, without removing them completely from the project.

After you have set the breakpoint, you can set conditions. Right-click on that line of code and select Breakpoint Properties from the menu. Figure 8.4 shows the Breakpoint Properties dialog box.

Figure 8.4: The Breakpoint Properties dialog box

You can then set a condition by entering an expression to evaluate or a variable name and specifying that the breakpoint will be hit if the condition is True or when the value changes. When working with loops or subroutines that are executed many times, you might want to specify a hit count. Rather than breaking each time the line of code is executed, it will break only at a specific count, or every 10 times (a multiple), or when the hit count reaches or exceeds a specified number.

Use the Breakpoint window to see the status of all breakpoints in your project. You can access this window by choosing Debug Ø Windows Ø Breakpoints from the Visual Studio .NET menu.

Note 

You will practice setting breakpoints in Exercise 8.1.

Using Debugging Tools

Other tools that are available to you in Break mode are accessed through the Debug menu and toolbar. These include the following:

Resuming/stopping program execution  The Debug menu and toolbar include commands to continue application execution at the current line of code, to stop debugging (and end application execution), to break all (similar to pressing Ctrl+Break when the application is executing), and to restart the application execution from its startup code. When not in Break mode, the Debug menu also offers an option called Start Without Debugging, which enables you to test your application’s behavior without the debugger running.

Stepping through code one line at a time, stepping over or out of procedures  When you enter Break mode, the next line of code that will be executed is highlighted. You can use the Step Into instruction to execute code line by line. Step Over will execute a subprocedure or function without stepping line by line. Step Out will finish executing a subprocedure or function and take you back to the line of code following the one that called the subprocedure.

Status windows, such as, Memory, Registers, Call Stack, Threads, Modules, and Disassembly  You can access detailed information about how your application is executing, such as viewing the contents of memory and registers. You can view the call stack to see which procedures are currently executing and see how many active threads are running. The Modules window shows you information about assemblies that are loaded, such as the mscorlib.dll, system.dll, and any others that your application references, as well as your application’s executable. The Disassembly window shows you the assembly language code that has been compiled from your source code.

Status windows, such as, Watch, Locals, Autos, and Me  These status windows show information about variables and objects in your application. You can use the Watch window to change the value of a variable in Break mode and then resume application execution. The Locals window shows the value of variables in the current procedure, The Autos window also shows values from previously executed procedures. The Me window shows the status of your Windows form and its controls.

Command window  The Command window is similar to the Immediate window in Visual Basic 6. When this window is set to Immediate mode, you can use it to evaluate expressions, query the value of variables and execute lines of code. By switching to Command mode (type >cmd in the window and type >immed to return to Immediate mode), you can type commands to control Visual Studio .NET, such as starting and stopping your application, or to run Visual Studio .NET macros.

Figure 8.5 shows the Debug toolbar and the options that are available on the Debug menu when you are in Break mode. You will test many of these options in Exercise 8.1.

Figure 8.5: The Debug menu and toolbar

In Exercise 8.1, you will set breakpoints and use the Command window and some of the other Visual Studio .NET debugging tools.

Exercise 8.1: Setting Conditional Breakpoints and Using the Debugging Tools

1. Start Visual Studio .NET and begin a new Windows application. Name the project DebugExamples.

2. Change the name of the default Form1.vb to frmDebug.vb.

3. Add a Command Button and a TextBox to the form. Name them btnStart and txtResult. Your form should look like the following one.

   

4. Create a Click event procedure for btnTest. This code will perform some simple calculations in a loop so you can test the Debug features. You code should look like this:

   Private Sub btnStart_Click(ByVal sender As System.Object, _    ByVal e As System.EventArgs) Handles btnStart.Click    Dim loopCounter As Int32    Dim innerCounter As Int32    Dim resultNum As Int32    For loopCounter = 1 To 10       For innerCounter = 1 To 10          resultNum = loopCounter * innerCounter       Next    Next    txtResult.Text = CType(resultNum, String) End Sub

5. Set a breakpoint on the line of code that reads For innerCounter = 1 To 10 by clicking in the left margin of the code editor. The line of code will be highlighted.

6. Right-click on the breakpoint and choose Breakpoint Properties from the menu. Click the Condition button and a second dialog box will open.check Type loopCounter=5 in the text box. Make sure that the Is True option is selected. Click the OK button to close each dialog box.

   

7. On the Debug menu, choose Debug Ø Windows Ø Breakpoints. The Breakpoints window displays at the bottom of the screen and shows information about the breakpoint you just set.

8. Save and run the application. Click the Start button. When your application goes into Break mode, display the Locals window to view the values of your variables. Verify that loopCounter is equal to 5.

9. Use the Step Into toolbar button to step line by line through the code. Watch the variable values change in the Locals window.

10. Remove the breakpoint on the line of code that reads For innerCounter = 1 To 10 by clicking again in the left margin of the code editor. The highlight will go away.

11. Set a breakpoint on the line of code that reads resultNum = loopCounter * innerCounter by clicking in the left margin of the code editor. That code line will be highlighted.

12. Right-click on the breakpoint and choose Breakpoint Properties from the menu. Click the Hit Count button and then choose Break When The Hit Count Is Equal To from the drop-down list. Type a value, such as 35, in the text box.

13. Run the application again. Click Start, and when it goes into Break mode, display the Locals window. Examine the value of your variables.

14. Display the Command window. The window should be in Immediate mode, the title bar should display “Command Window - Immediate.”

15. Type ? loopCounter in the Command window. Press the Enter key. You should see the value of loopCounter, which should be 4.

16. Type loopcounter = 7. Press the Enter key. Verify in the Locals window that the value has been changed.

    

17. Click the Continue button on the Debug toolbar to resume application execution.

Debugging Other Types of Applications

When you are working on standard applications in the Visual Studio .NET IDE, you have all the source code loaded into Visual Studio .NET and are working on a single computer. As you work with other types of applications, such as Windows services, .NET Remoting objects, or XML Web services, debugging can become more complex. You might need to debug code that is running on a different computer. This section covers some of the special considerations for debugging.

Debugging Windows Services

As we discussed in Chapter 1, “Creating and Managing Windows Services,” a Windows service cannot be started by running it in the Visual Studio .NET IDE. It must first be installed as a Windows service and then started with the Service Control Manager. After the service is running, you can attach the Visual Studio .NET debugger to the process. This is done by choosing Debug Ø Processes from the menu, locating your service in the list of processes running on your computer, and then attaching to that process. Chapter 1 explains this procedure in more detail.

Debugging DLLs

If your project consists of only DLLs with no user interface or other startup code, you can still debug these applications by specifying the name of a project (such as a Windows Form application) that will be used to test the DLL. This information is entered in the Project Properties dialog box under Configuration Properties Ø Debugging, Start External Program.

Debugging Remote Components

If you need to debug an application that is running on a different computer across the network, you must make sure that either Visual Studio .NET or the remote components are installed on the machine. The remote components are installed by using the Visual Studio .NET setup disk. You will see the option to install remote components on the first screen. To debug remotely, you must also be a member of the Windows Debugger Users group on the remote machine.

Just-in-Time Debugging

When your .NET Framework applications are running outside of the Visual Studio .NET environment and an error occurs, you will see a dialog box asking whether you want to debug them. For Windows forms and ASP.NET applications, you can use the Common Language Runtime debugger; for classic ASP applications and other script-based applications, use the Script debugger. There is also a native debugger available for C++ applications.

Debugging XML Web Services

When debugging an XML Web service, you can step from code in a test client, into the code of the Web service (assuming the Web service was created with Visual Studio .NET and you have the source file and debugging symbols file, .pdb, available). You do not have to load the Web service project into Visual Studio .NET. You can load the test client, set a breakpoint on the line of code that makes a call to the Web service, and then watch as you step from your test client into the code module of the Web service. Remember that your Visual Studio .NET test project contains a proxy class that hides some of the details involved in calling Web service methods. By default, this class is marked with a <DebuggerStepThrough()> attribute. This means that when stepping though the code, you typically do not see the code in the proxy class executing. If you remove the attribute, you will step from the client code, to the proxy class, and then into the Web service code.

Debugging SQL Server Stored Procedures

Visual Studio .NET not only gives you the ability to view and run SQL Server stored procedures from the Server Explorer, but also provides the ability to debug them. Expand the Server Explorer to display your database’s stored procedure, right-click the procedure name, and choose Step Into Stored Procedure from the menu. Please consult the Visual Studio .NET documentation for more information about components that need to be installed for SQL Server and permissions that are required to debug this way.

Debugging with Command-Line Debuggers

The .NET Framework includes two command-line debugging utilities. The CLR Debugger (DbgCLR.exe) provides debugging services with a graphical interface when the .NET Framework is installed but Visual Studio .NET is not present. The Runtime Debugger (Cordbg.exe) is a command-line debugger.