Using a Debugger
As part of Visual Studio .NET, two debuggers are available: DbgClr and Devenv. DbgClr is almost identical to the debugger associated with the Visual Studio Development Environment except that it provides a read-only view of a particular project. With DbgClr, it is not possible to use edit-and-continue, and it is not possible to modify the source, recompile, and run from the same tool like it is with the debugger associated with Visual Studio .NET (devenv.exe). These differences aside, the functionality is just about the same for each of the tools. DbgClr might be faster than Devenv simply because not as much overhead is associated with DbgClr. DbgClr doesn't have a compiler, editor, and so on built in like Devenv does.
Any programmer who has used either the debugger associated with Visual Basic or the debugger associated with previous versions of Visual Studio should find most of the features familiar. The following sections highlight some of the added features of the debugger(s) that are a part of the Visual Studio .NET suite of tools.
Setting Breakpoints
You can set breakpoints just as you do with Visual Studio 6. You simply highlight the line on which the breakpoint should be set, right-click, and select Insert Breakpoint. You can also select New Breakpoint and specified options to be applied to the breakpoint, such as Hit Count and Condition, before setting the breakpoint.
One special note is Visual Studio .NET makes a clear distinction between debugging managed code and debugging unmanaged code. If your application includes both managed code and unmanaged code and the main project uses managed code, then to step into or set breakpoints in the source of unmanaged code, you need to specifically enable this feature. Figure 19.15 shows where you can enable debugging unmanaged code.
Figure 19.15. Enable unmanaged code debugging.
After this Enable Unmanaged Debugging option has been set to True, you can freely debug both unmanaged and managed code. Without this option, calls into unmanaged code are skipped.
Stepping Through Your Code
One particularly useful option that a debugger provides is the ability to single step through your code. This is supported with Visual Studio .NET. The main difference is that now you can debug an application that consists of multiple languages. For example, your main assembly is written in C# and you reference or link in code that was compiled with Visual Basic. As you step through the code with a debugger, you can step into code written in either Visual Basic or C#. You can set breakpoints in either the Visual Basic source code or the C# source code, and the program will stop when that point in your execution path has been reached. In other words, debugging an application that is composed of multiple languages can happen just as easily as if the whole project were written in one language.
Status Information
Much of the information about your application is provided. This is particularly important when multiple AppDomains, threads, or processes exist. With the debugger, you can switch into the context of any AppDomain, thread, or process easily. Look at the toolbar in Figure 19.16, which shows a debugging of the ThreadPoolTest sample introduced in Chapter 14, “Delegates and Events.”
The same toolbar is shown, this time with the thread information selected in Figure 19.17.
By selecting any of the input provided in these drop-down menus, the user can move to that particular context. Selecting a particular thread changes the debugger to show the current line in the source that the particular thread is executing. Something similar happens when a particular AppDomain is selected. Note that you are still actually selecting a thread context, but if that context is currently in another AppDomain, then the drop-down list shows the friendly name of the AppDomain that is currently hosting the particular thread.
Attaching to a Running Process
It is possible to attach the debugger to a running process. After the debugger is attached, that process is temporarily halted until the user continues it from the debugger.
To attach the debugger to a running process, you first need to select the process to which you want to attach. The Visual Studio .NET IDE provides an interface to do this. This interface is accessed through the DebugProcesses menu. Figure 19.18 shows this interface.
Figure 19.18. Selecting a process to which to attach.
After you have selected this menu item, a dialog box appears with a list of all of the processes available on the current machine to debug. If the process that you want to debug is a service, then you might need to select the check box in the lower-left corner titled Show System Processes so that system-level processes are included in the list. Figure 19.19 shows what a typical list of processes might look like.
As you can see from this figure, not only do you get a listing of available processes, but you also can see which processes are .NET applications and which are not. Select ThreadPoolTest.exe, which is a .NET application. A dialog box appears prompting you to input the types of applications that you want to debug. You want to debug both Common Language Runtime programs and Native (unmanaged) programs. Because this is the default, you don't have to do anything here. Just click OK. Figure 19.20 shows what this dialog box looks like.
After you click OK, the process is attached to the debugger and you are returned to the original process listing dialog box (as shown in Figure 19.19). However, this time is refreshed to indicate that you have attached to the process (see Figure 19.21).
Figure 19.21. Showing the process that has been attached to the debugger.
After the process has been successfully attached to the debugger, the window shown in Figure 19.21 can be dismissed. If you load a source page associated with the program being debugged, you will be able to set breakpoints and single step through the program just as if you had started up with the debugger.
Remote Debugging
It is possible to debug a process on another machine. To do this, you essentially follow the same steps as attaching to a process on the local machine. Remote debugging requires some setup first, however.
For the process to run at all on another machine, the machine must at least have the redistributable portion of the .NET Framework installed. This consists mostly of the DLLs and executables that the CLR requires to run.
You also have to make sure that the remote debug manager is running on the remote machine. This is most easily accomplished by running the Server Setup on the CD that was used to install the SDK. In the lower-left corner of the initial setup screen when you installed the SDK (the screen that had the three steps of installing the Windows Component Update, Visual Studio, and Updates), there was a small hyperlink, Server Setup. If you clicked on this rather than any of the other options, you would have installed the required files for remote debugging.
When you have completed both of these steps successfully, you should be able to go to the Services icon of the administrative tools and see that the Machine Debug Manager (mdm.exe) is running. The Services tool should look like Figure 19.22.
The specific properties of this service should look like Figure 19.23.
Figure 19.23. Machine Debug Manager service properties.
Of primary importance is that the service is started. The service should be configured to start automatically. If the service is configured to start manually, you will need to remember to start it before each debug session.
When this initial setup is complete, you can attach to a process on a remote machine exactly as you attached to a process on the local machine. A portion of the dialog box allows you to set the machine name from where the process list is to come. You can specify the machine name of any machine that has been properly set up. After a process has been attached on the remote machine, debugging proceeds exactly as described previously in the “Attaching to a Running Process” section.