ToolKit
LANGUAGES: All .NET Languages
VERSIONS: 1.0 | 1.1
Discover the CLR Debugger
Debug your Web applications like you never could before.
By Ken McNamee
I must say I have been quite lucky the past few years since I started working exclusively with ASP.NET because I've been able to step through my code as it executes, line by line, even down to SQL Server's stored-procedure level. I'm lucky because, even years later, I remember what it was like trying to debug an ASP 3.0 application using Visual InterDev or Notepad. As long as I'm developing with ASP.NET, I don't need to leave Response.Write statements strewn throughout my code to output the value of one variable or another. Using the CLR Debugger (DbgCLR), which ships free with the .NET Framework SDK, I can debug an ASP.NET Web application like any other kind of software developed with a professional, high-level language IDE.
Speaking of professional development environments, DbgCLR actually is a slightly limited version of the debugger included with Visual Studio .NET. Or, is the Visual Studio .NET debugger a more powerful version of DbgCLR? Well, it doesn't matter. Either way they are great debuggers. The differences between them really are quite small. As the name suggests, DbgCLR supports only debugging code written for the CLR; the VS .NET debugger additionally supports debugging native Win32 code. The only major difference that might affect ASP.NET developers is DbgCLR's lack of a remote debugging feature. DbgCLR's few other differences are either minor inconveniences - such as no Autos window - or not relevant to Web development - such as no Registers window.
Use DbgCLR With ASP.NET
The first thing you must do to debug a Web page using DbgCLR is tell the ASP.NET runtime to emit debug symbols when compiling the page. You do this by adding the Debug page directive:
<%@ Page Language="C#" Debug="True" %>
You can set this on a page-by-page basis, or you can require all pages to compile in debug mode with this web.config option:
This is a flexible model because you can turn on the debug mode by default in web.config and still turn it off on a page-by-page basis using the Debug page directive. Or, you can turn it off by default in web.config, then use the Debug page directive to turn it on in selected pages.
The next step in using DbgCLR is to start the program itself, which is installed in the GuiDebug folder under your Framework SDK root. Without Visual Studio .NET installed, this folder normally is located in C:\Program Files\Microsoft.NET\FrameworkSDK\GuiDebug for version 1.0, and C:\Program Files\Microsoft.NET\SDK\v1.1\GuiDebug for version 1.1.
Although nearly identical to the VS .NET debugger, DbgCLR is not quite as simple to use. For ASP.NET pages, three requirements must be met for DbgCLR to operate successfully: the source code for the page must be opened, the page must have been compiled in debug mode, and it must "attach" itself to the executable program running the page. If you are familiar only with integrated debuggers and have never used one that is external to your IDE, the process of attaching one program to another might seem a little alien. In reality, however, you are doing manually what Visual Studio .NET does behind the scenes automatically .
Once the source code for the page is opened in DbgCLR and it's compiled - you do this by requesting the page in the browser - click on the Tools menu and select Debug Processes. You should see something similar to the screen displayed in Figure 1. The process you need to attach to is the ASP.NET worker process (aspnet_wp.exe). Remember, the IIS process, inetinfo.exe, merely accepts the request for the page from the browser client, invokes the ASP.NET ISAPI DLL, and passes off the page's execution to aspnet_wp.exe. If you don't see aspnet_wp.exe in the list of running processes, select the "Show system processes" checkbox because, by default, DbgCLR displays only the processes your user account has started.
Figure 1. The Debug Process dialog is used to let DbgCLR attach to the
ASP.NET worker process, aspnet_wp.exe, which is where your Web pages are
actually executed.
Now you can set breakpoints in the code. Run the page again and you should be able to step through not only the code in the page, but also components called from the page. You also can edit the code from within DbgCLR, but it doesn't include an Edit and Continue feature, nor does it include a Save function if you decide to edit the page from the debugger. You can circumvent these limitations by editing the page and closing it, at which point a dialog pops up asking if you want to save it. This is certainly not ideal, yet it's understandable because DbgCLR is meant to function only as a debugger, not a full-featured IDE.
Because I primarily use Visual Studio .NET, I don't get to use DbgCLR often. One use I have found for it is on machines where it is illogical or impossible to install the entire Visual Studio .NET environment. For example, I might use DbgCLR in QA or even production where an IDE isn't required but a powerful debugger can be invaluable. Visual Studio .NET is intended to debug remote processes, but I must admit I've had some trouble getting this to work. Also, some companies might employ a network architecture that prohibits you from using a developer workstation to access a QA or production machine in this manner. Of course, if you don't own Visual Studio .NET, DbgCLR is the next best thing for your debugging needs.
The sample code in this article is available for download.
Ken McNamee is an independent consultant who works with companies in need of highly scalable, data-driven Web applications. And who doesn't need one of those these days? Prior to this, he led a team of developers in re-architecting the Home Shopping Network's e-commerce site, HSN.com, to 100 percent ASP.NET with C#. E-mail him at [email protected].
