Debugging

With previous versions of ASP, debugging has always been a bit of a chore. Response.Write was the primary method of finding out what's going on in a program, and even the Script Debugger was weak in comparison to the debuggers that Windows developers had for Visual Basic and C++ code. All that has now changed with .NET, as the CLR provides integrated debugging for all applications. The primary goals of this were:

• Both in-process and out-of-process debugging

• Remote process debugging

• Managed and unmanaged code debugging

• Mixed language support

• Edit-and-Continue

Some of these aren't actually implemented as part of the CLR, but the rest of the framework provides the required support. There are two ways to perform debugging in the .NET Framework. The first is to use the SDK debugger, and the second is to use Visual Studio .NET. This section isn't going to give a comprehensive list of all debugger features, as most are fairly obvious. What we will concentrate on are the most used features.

The SDK Debugger

The SDK debugger ( DbgCLR.exe ) ships with the .NET SDK, and can be found in the GuiDebug directory. It provides the same features as the Visual Studio .NET debugger, except that it doesn't support remote debugging or Edit-and-Continue. Despite the lack of these two features, it is far better than anything you have been used to in the ASP world.

Enabling Debugging

Earlier in this chapter, we showed that to allow tracing you added a Page directive to your web pages. The same is true for debugging, where the Debug attribute is set to True :

  <%@ Page Debug="True" %>  

This tells the compiler to emit debugging symbols into the compiled page, and allows the debugger to attach to the running program.

The debug symbols are also required for components , and to enable them use the /debug flag on the compiler (the flag is the same whichever language compiler you are using). When you compile with this an extra file is created, ending in .pdb “ this contains the debugging symbols. You don't have to do anything with this file, as it is only used by the debugger.

Before using the debugger, you will also need to view the web page in the browser so that the debugging symbols are loaded for the page. You can still start the debugger and load the page, but you won't be able to do any debugging until the page has been compiled once with the debugging enabled.

Note

Remember to disable debugging and compile components without the debug symbols when you deploy applications to reduce any overhead.

Starting Debugging

To start debugging your ASP.NET applications, launch the debugger, and from the Tools menu select Debug Process , to show the dialog in Figure 22-13:

Figure 22-13:

This shows the processes you can pick to debug. Make sure you have the Show system processes checkbox box selected, and pick the aspnet_wp.exe process “ this is the ASP.NET worker process. Click the Attach button to attach the debugger to the process, and then close the dialog. You can now load a page into the debugger (by using File Open) and set breakpoints by clicking in the gray margin as shown in Figure 22-14:

Figure 22-14:

This shows a breakpoint in a simple ASP.NET page coded using JScript ( unlikely for most people, but there's a point to it “ bear with me). This page simply instantiates a class called Programmer . If you now hit the page, you are flipped into the debugger at the set line as shown in Figure 22-15:

Figure 22-15:

You can now step into the code for the component ( assuming it was compiled with the /debug option), as shown in Figure 22-16:

Figure 22-16:

Now you've stepped into the constructor of the Programmer class. Notice that it is a Visual Basic class. You are almost at that point I was trying to make “ let's go one step further and step into the base class. See Figure 22-17:

Figure 22-17:

Now the point is made. You have a base class written in C#, which is sub-classed by a Visual Basic class, and used in a JScript ASP page. This becomes obvious when examining the call stack as shown in Figure 22-18:

Figure 22-18:

This really reinforces the concept of language equality in the runtime, since you can debug through components written in different languages. Even if it were restricted to a single language, the fact that you have such a good debugger would be a great benefit in itself.

SDK Debugger Features

The SDK debugger has all of the great features that you'd expect from a high-end development environment, including:

• Stepping into, out of, and over code

• Setting breakpoints on specific lines

• Setting breakpoints on specific exceptions

• Setting breakpoints on expressions

• Viewing contents of variables

• Viewing the call stack, threads, and modules

The two major features that aren't supported are debugging remote processes and Edit-and-Continue. No support for Edit-and-Continue means that the SDK debugger is a read-only debugger, so you can't edit code inline and continue the debugging process. You can only edit code externally, and the debugger recognizes that the file has changed (and will reload it if you desire ), but the new changes will not take effect until the request is rerun. For these features you need the Visual Studio .NET debugger.

Debugging in Visual Studio .NET

In Visual Studio .NET debugging is just a part of working with an integrated development tool. When building an application, all you have to do is set a breakpoint from within the code editor window and run your application. You'll see a view that looks similar to the SDK debugger, and supports the same set of features such as stepping and viewing of code and variables.

Edit-and-Continue

Edit-and-Continue gives you the ability to alter code while programs are running. This is due to the ability of the runtime to inject code into a running process. There are, however, some limitations:

• For running functions ( anywhere in the call stack) you are limited to 64 bytes of additional variables. Outside of the call stack there is no limit.

• You cannot change resource files.

• You cannot change exception-handling blocks.

• You cannot change data types.

• You cannot remove functions.

In most cases you couldn't really call these limitations , as they are the sorts of alterations that would require more than a simple change.

There's nothing special you have to do to enable this functionality. There are options to disable Edit-and- Continue, and to specify its various functions, but the defaults are all acceptable. All you have to do is retype code in the debugger when in break mode and the new code takes effect.

Remote Debugging

Remote debugging works in the same way as local debugging, except you have the option to debug a remote process. This is useful in situations where you have a separate server hosting the application. A full description of remote debugging is beyond the scope of this book, but consult the .NET documentation, under the section titled Remote Debugging Setup .