Debugging compiled applications can require special consideration; sometimes they are not able to produce output directly for the developer to see (for example, compiled business objects generally don't display any data). Normally, the executing code has been translated to machine language or MSIL, which makes it harder to follow along. These types of application require a different kind of debugger one that can attach to a running process.
| || |
When you run an application, compiled code is executed by the computer. This code executes instructions, creates variables along the way, assigns values to those variables, and destroys them as well. Recall that all of these variables are stored in memory. Attaching a debugger means that another application, a debugger, is watching the memory used by the first application. The debugger can interpret the instructions and memory used by the application and tell the developer know what's going on, in readable terms.
The previous methods you've seen today involve altering the code before execution and watching the output after execution is through. Attaching a debugger is very helpful when you need to watch and alter commands during execution. Figure 20.16 illustrates the difference.
Figure 20.16. Attaching a debugger allows you to watch the execution step by step.
Note that you can also run an application from the debugger, so you don't have to attach it after the program is already running.
Because ASP.NET pages are compiled, you can use debugging tools similar to those used for traditional application debugging. Specifically, you'll be using the Common Language Runtime Debugger included with the .NET Framework SDK.
Using the CLR Debugger
Before you use the debugger, you need to enable debugging in your application in the web.config file. Add the following lines to web.config in your root directory:
<configuration> <system.web> <compilation debug="true" /> </system.web> </configuration>
| || |
This line generates a symbol file (.pdb) for your application. This file tells the debugger how to map the machine instructions that must be interpreted to the code in the source file. This allows you to track the execution by looking at the code you've written instead of cryptic machine code.
This line also shows you some rudimentary debugging information in your ASP.NET pages when you receive an error, as you learned about earlier today in "Introduction to Debugging."
Note that you should disable the debug option in your web.config file as soon as you're done debugging. Compiling with debug enabled really slows down your applications.
Let's start the CLR debugger. The file is called DbgCLR.exe, and it's located at c:\Program Files\Microsoft.NET\FrameworkSDK\GuiDebug by default. Double-click on this file, and you should see what's shown in Figure 20.17.
Figure 20.17. The Common Language Runtime Debugger Interface.
Once you've opened the debugger, debugging your applications is a four-step process:
Open the file you want to debug.
Attach the debugger to the ASP.NET process.
Use the debugger's tools to manipulate your application.
Assuming that you've saved Listing 20.7 as listing2007.aspx, open it from your browser and allow it to execute normally. This will start the ASP.NET process and your application if they aren't already running. Open this file in the CLR debugger as well by clicking on File, Open, File, and then selecting the appropriate source file. You should see the source code in the CLR debugger, and the file will appear in the Solution Explorer window on the right side of the debugger.
To attach the debugger to the ASP.NET process, click Tools, Debug Processes. You should see the window shown in Figure 20.18.
Figure 20.18. Attaching the debugger to the ASP.NET process.
Click Show System Processes (if you haven't already) and find the aspnet_wp.exe process. Select this process and click the Attach button. In the window that pops up, check Common Language Runtime. At the bottom of the window, you should see the name of your application (tyaspnet21days). Click OK and close the processes window.
A new window is now available in the CLR debugger, called Disassembly. This window shows the interpreted instructions as seen by the computer.
When you attach to any process with a debugger, that application is usually frozen (unusable) and any unsaved information may be lost. ASP.NET is no different. When you attach to the process, make sure that you're not blocking any production applications.
| || |
A breakpoint is a place in the code where execution is paused. Breakpoints are very useful for debugging specific lines in your code. For example, if you know a line is causing errors in your page, you can set a breakpoint immediately before it and use the debugger to analyze the instructions and variables.
To set a breakpoint, click the left-hand column next to the source code of your file. A red dot should appear, meaning the execution will halt at this line. (If a question mark appears in the red dot, you may not have enabled debugging in web.config.) Hold your mouse cursor over the breakpoint and you'll see exactly where it will occur, as shown in Figure 20.19.
Figure 20.19. Setting a breakpoint in your code causes execution to halt temporarily at the specified line.
Now request listing2007.aspx from the browser again. When the execution reaches the breakpoint, the application will stop and the debugger will take control.
At the top of the CLR debugger window are controls that allow you to control the execution, such as moving to the next line of execution or stopping debugging altogether. The debugger is a very complex tool, and you can do a lot with it. For more information, see the .NET Framework SDK Documentation.
Debugging compiled applications can be a pain because you cannot stop execution without losing information, nor can you watch variables in real-time. This makes it difficult to track down where an error is occurring, especially if your application is very complex. The CLR debugger provides all the preceding capabilities for ASP.NET pages, which makes debugging a snap.
ASP.NET applications aren't all the CLR debugger can attach to. It can attach to and debug any .NET Framework application that you have running. (In other words, it must have been developed under the .NET Framework; you couldn't, for instance, debug Windows 95 with this debugger.) Just remember that the application must be enabled for debugging, meaning it must have symbol files.