| Debugging is the process of finding the causes of errors in a program, locating the lines of code causing those errors, and fixing the errors. When starting a program from Visual Studio .NET for debugging, you should ensure that the program is started in the Debug configuration. To enable debugging in an ASP.NET application, you need to ensure that the debug attribute of the <compilation> element in the web.config file is set to true, like this: <compilation debug="true"/>  | When debugging is enabled for an application, the compiler includes extra debugging information in the page, creating a large output file that executes slowly. When you deploy your application, be sure that you change the debug attribute in the <compilation> element in the web.config file to false. This will improve the application's performance. |
In addition, for ASP.NET Web applications and Web services, ensure that the Enable ASP.NET Debugging option is set to True. The Enable ASP.NET Debugging option is found in the Configuration Properties, Debugging option in the project's Property Pages dialog box. | When you run an application from Visual Studio .NET, it automatically attaches a debugger to the process in which your application is running. In the case of ASP.NET Web applications and Web services, the debugger is also attached to the ASP.NET worker process (aspnet_wp.exe) if the Enable ASP.NET Debugging property is set to True in the project's Property Pages dialog box. |
Setting Breakpoints and Stepping Through Program Execution Breakpoints are markers in the code that signal the debugger to pause execution. After the debugger pauses at a breakpoint, you can analyze variables, data records, and other settings in the environment to determine the state of the program. Follow these steps to learn how to set breakpoints and perform step-by-step execution of a program: Create a new Web application project (Example10_3) with the same user interface as Example10_2. Switch to Code view and add the following using directive: using System.Diagnostics; Add the following method to the class: private int Factorial(int intNumber) { int intFac = 1; for (int i = 2; i <= intNumber; i++) intFac = intFac * i; return intFac; } Add the following code to the Click event handler of the btnCalculate control: private void btnCalculate_Click(object sender, System.EventArgs e) { int intNumber, intFac; try { intNumber = Convert.ToInt32(txtNumber.Text); intFac = Factorial(intNumber); lblResult.Text = String.Format ("The factorial of {0} is {1}", intNumber, intFac); } catch(Exception ex) { Debug.WriteLine(ex.Message); } } In the event handler added in step 3, right-click the beginning of the line that makes a call to the Factorial() method and select Insert Breakpoint from the shortcut menu. You will note that the line of code is highlighted with red and also that a red dot appears in the left margin. Set the project as the startup project for the solution, and run the project. Enter a value and click the Calculate button. Note that execution pauses at the location where you have marked the breakpoint. You should see an arrow on the left margin of the code indicating the next statement to be executed. Select Debug, Step Into to step into the code of the Factorial() method. Hover the cursor over the various varibles in the Factorial() method; you'll see the current values of these variables. Select Debug, Step Out to automatically execute the rest of the Factorial() method and restart the step mode in the event handler at the next statement. Step through the execution until you see the form again.
 | Breakpoints and other debugging features are available only when you run your project using the Debug configuration. |
To set advanced options in a breakpoint, you can choose to create a new breakpoint by selecting Debug, New Breakpoint. The New Breakpoint dialog box, shown in Figure 10.1, has four tabs. You can use these tabs to set a breakpoint in a method, in a file, at an address in the object code, and when a data value (that is, the value of a variable) changes. Figure 10.1. The New Breakpoint dialog box enables you to create a new breakpoint. 
Clicking the Condition button opens the Breakpoint Condition dialog box, as shown in Figure 10.2. Figure 10.2. The Breakpoint Condition dialog box enables you to set a breakpoint based on the runtime value of an expression. 
Clicking the Hit Count button in the New Breakpoint dialog box opens the Breakpoint Hit Count dialog box, shown in Figure 10.3. This dialog box can be especially helpful if you have a breakpoint inside a lengthy loop and want to step-execute the program only near the end of the loop. Figure 10.3. The Breakpoint Hit Count dialog box enables you to break the program execution only if the specified breakpoint has been hit a given number of times. 
Analyzing Program State to Resolve Errors When you break the execution of a program, the program is at a particular state in its execution cycle. You can use debugging windows (which you can invoke from the Debug, Windows menu) to help you identify the cause of the error you are debugging. Table 10.5 lists the important debugging windows in Visual Studio .NET. Table 10.5. Important Debugging Windows in Visual Studio .NETWindow | Description |
|---|
Call Stack | Enables you to view the names of methods on the call stack, the parameter types, and their values | This | Enables you to examine the members associated with the current object | Autos | Displays the variables used in the current statement and the previous statement | Locals | Displays the variables local to the current method under execution | Watch | Enables you to evaluate variables and expressions |
| You can also perform step-by-step execution of SQL Server stored procedures in Visual Studio .NET. To configure a project for SQL Server debugging, access the project properties window. Select the configuration properties for debugging; then, in the right pane, under the Debuggers node, select True for Enable SQL Debugging. |
Debugging on Exceptions You can control the way the debugger behaves when it encounters a line of code that throws an exception. You do this through the Exceptions dialog box, which is invoked by selecting Debug, Exceptions. The two levels at which you can control the behavior of the debugger when it encounters exceptions are as follows: When the exception is thrown You can instruct the debugger to either continue or break the execution of the program when an exception is thrown. If the exception is not handled If the program you are debugging fails to handle an exception, you can instruct the debugger to either ignore it and continue or break the execution of the program.
Debugging a Running Process You need to take the following steps to debug an already running process. Open the source file of the process in Visual Studio .NET and set the breakpoint at an appropriate location. Select Tools, Debug Processes. This invokes the Processes dialog box. Select the process that needs to be debugged in the Available Processes section, and then click the Attach button to attach the process to the debugger. Visual Studio .NET debugger breaks the execution of the process when the breakpoint is reached.
When you debug a running process, you should be a member of the Debugger Users group. In addition, when debugging the ASP.NET worker process, you should be a member of the Administrators group.  | When you attach a debugger to the ASP.NET worker process aspnet_wp.exe, it freezes the execution of all other Web applications on that server. In most cases, you'll want to avoid debugging on a production server. |
Debugging a Remote Process For remote debugging to work, the Machine Debug Manager (mdm.exe) should be running on the remote computer. mdm.exe is a Windows service that provides remote debugging support. If the remote computer has never been set up for remote debugging, you can take one of the following two steps to configure the remote machine: You also must ensure that your user account is a member of the Debugger Users group on the remote machine. If you want to debug an ASP.NET worker process, you must also have administrative privileges (that is, you should be a member of the Administrators group) on the remote machine. | The local computer and the remote computer must be members of a trusted domain for remote debugging to be possible. |
| Visual Studio .NET uses DCOM (Distributed Component Object Model) to enable remote debugging. If you get a DCOM configuration error while debugging, you didn't set up the remote machine to support remote debugging. |
If SQL Server is installed on the remote machine, the setup process just described also configures the machine for SQL Server stored procedures debugging. In addition to the already-mentioned one-time setup of the remote machine, you need to configure the Visual Studio .NET project on your local machine. To do this, take the following steps: Set the Enable Remote Debugging option to True in the project's Property Pages dialog box, shown in Figure 10.4. The EXE file must be in a shareable directory on the remote machine. Figure 10.4. You must set the Enable Remote Debugging option to True to enable remote debugging. 
Set the Remote Debug Machine option with the name of the machine on which the EXE file will run. The EXE file must be in a shareable directory on the remote machine. The location of the EXE file on the remote machine must match the value of the Output Path property, which is on the Build property page in the Configuration Properties folder.
After you have completed the required setup, the process of debugging a remote process is almost the same as the process of debugging an already running process. The only difference is that before selecting a running process from the Processes dialog box, you need to select the remote machine name from the Processes dialog box. Debugging the Code in DLL Files The process of debugging a DLL file is similar to the process of debugging an EXE file. There is one difference, though: The code in the DLL file cannot be directly invoked, so you need to have a calling program that calls various methods/components of the DLL files. You typically need to take the following steps to debug code in a DLL file: Launch the program (such as an EXE file, a Web page, a Web service, and so on) that uses the components or methods in the DLL file. Launch Visual Studio .NET and attach the debugger to the calling program. Set a breakpoint either in the calling program where the method in the DLL file is called or in the source code of the DLL file. Continue with the execution. The execution breaks when the breakpoint is reached. At this point, select Debug, Step Into to step into the DLL file's source code. Execute the code in step mode while you watch the value of its variables.
Debugging Client-Side Scripts Visual Studio .NET also enables you to debug client-side scripts. Note the following additional points for client-side scripting: Client-side debugging works only with Microsoft Internet Explorer. You need to enable script debugging in Internet Explorer. To do this, select Tools, Internet Options; select the Advanced tab; and uncheck the Disable Script Debugging option in the Browsing section. Attach the debugger to the iexplore.exe process displaying the Web form. This is required only if you are debugging an already running process. While attaching the process in the Attach to Process dialog box, make sure that you also select the Script option.
Debugging a Windows Service A Windows service runs within the context of the Service Control Manager. Therefore, to debug a Windows service, you must attach a debugger to the process in which the Windows service is running. If the Windows service is not already started, you need to start the Windows service to perform debugging. Debugging a Serviced Component A serviced component is stored in a DLL file. The code in the serviced component cannot be directly invoked, so you need to have a client (calling) program that creates the serviced component object and calls various methods of the serviced component. Therefore, to debug a serviced component, you need to take steps similar to those of debugging any DLL file. However, the debugging differs slightly depending on whether the serviced component application is a library or server application. If the serviced component is a library application, the serviced component runs in the client application's process. In this case, you can set breakpoints in the serviced component or the client application and run the client application in debug mode. When the breakpoint is reached, you can step into the serviced component's code. In the case of an already running client application, you can set breakpoints in the serviced component or the client application and attach a debugger to the client application's process. On the other hand, if the serviced component is a server application, the serviced component runs in a separate process called dllhost.exe. Setting breakpoints in the client code and attaching a debugger to the client application debugs only the client application; it does not step into the code of the serviced component. Therefore, in this case, to step into the code of the serviced component, you need to attach debugger to the dllhost.exe process that is running the current serviced component. Note that while debugging, the serviced components involving transactions might raise COMException errors indicating transaction timeout problems. The default computer-level setting for a transaction timeout is 60 seconds. While debugging, you might want to increase the transaction timeout value. You can do so by overriding the default settings for a particular serviced component. If you are debugging multiple serviced components that involve transactions, instead of increasing the timeout value for each serviced component, you can choose to increase the computer-level setting of the default timeout value. You can do this by changing the Transaction Timeout value in the Options tab of the My Computer Properties dialog box, shown in Figure 10.5. You can open this dialog box by selecting Properties from the context menu of the My Computer node in the Component Services administrative tool. Figure 10.5. You can set the timeout value for all the distributed transactions in a computer in the My Computer Properties dialog box. 
Debugging a .NET Remoting Object A .NET remoting object is stored in a DLL file, such as a serviced component. A .NET remoting object executes in the process of the remoting server application, without respect to its activation mode. Therefore, to debug a remoting object, you need to take the following steps: If the remoting server is running in its own process, attach the debugger to that process. If the remoting server is hosted in IIS, attach a debugger to the ASP.NET worker process (aspnet_wp.exe). Set breakpoints in the remoting object class definition.
After taking these steps, the Visual Studio .NET debugger breaks the execution when it reaches the breakpoint in the code. Attaching a debugger to the process in which the client application is running debugs only the client application and does not step into the code of the remoting object class definition. To debug both client and server applications, you can attach a debugger to both the applications and step seamlessly into the code of both the applications. Debugging an XML Web Service Debugging XML Web services is similar to debugging Web applications. They also run in the ASP.NET worker process (aspnet_wp.exe). The only difference is that you need to take care of setting breakpoints in the Web methods, after which you can debug Web services in any of the following ways: You can run a Web service from Visual Studio .NET and then step into the code of the Web service by invoking the respective method through the Web service test page. You can also attach a debugger to the aspnet_wp.exe process to step into the code of the already-running Web service. You can create a client application for the Web service, which invokes its Web methods. You can then step into the Web service's code by running the client application from Visual Studio .NET. You can attach a debugger to an already-running client application and then step into the code of the Web service when the code reaches a breakpoint.
You can also use SOAP extensions of XML Web services for debugging. Refer to Chapter 6, "Advanced Web Services," to learn more about SOAP extensions. |
