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:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
debug="true" />
</system.web>
</configuration>
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 mailto:editors@devproconnections.com.