Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Debugging ASP.NET

Debugging ASP.NET

4.3 3
by Jonathan Goodyear, Brian Peek

Debugging ASP.NET focuses on the various tools, techniques, and best practices associated with debugging ASP.NET web applications under Microsoft's new .NET platform. Brief descriptions of the problems with debugging previous versions of ASP are covered, as well as how the new features of ASP.NET can be exploited to their fullest to find and eliminate bugs quickly


Debugging ASP.NET focuses on the various tools, techniques, and best practices associated with debugging ASP.NET web applications under Microsoft's new .NET platform. Brief descriptions of the problems with debugging previous versions of ASP are covered, as well as how the new features of ASP.NET can be exploited to their fullest to find and eliminate bugs quickly and easily. The book introduces changes to the code structure paradigm as implemented in the .NET platform, and how to structure ASP.NET code in this new paradigm to enable faster web application debugging.

Editorial Reviews

Directed toward experienced developers and project managers, this useful volume provides a resource for figuring out the bugs in your code. Readers should be familiar with developing ASP.NET web applications; all code examples are given in both Visual Basic.NET and C#. Among the skills taught here are the debugging tools available in ASP.NET, how to write code less susceptible to bugs, methods to remove bugs from large web applications, issues found in migrating traditional ASP web applications to ASP.NET, and locating bugs associated with specific parts of ASP.NET, including user controls, caching, ADO.NET, and web services. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

Publication date:
Landmark Series
Product dimensions:
7.00(w) x 9.00(h) x 0.80(d)

Related Subjects

Read an Excerpt

7: Visual Studio .NET Debugging Environment

The ASP script debugger that is integrated with the new Visual Studio .NET IDE is, without a doubt, one of the greatest enhancements to debugging from the previous versions of ASP. Unlike trying to debug traditional ASP pages in Visual Interdev, this actually works right out of the box!

In this chapter, you will be looking at all the features available for debugging in the Visual Studio .NET IDE, how to use them, and where each one is applicable for the problem you might be trying to conquer. This will all be accomplished by building a project from scratch in the IDE, so we recommend creating the project on your own as it is done in this chapter.

Introduction to Features

Let's start out by taking a look at the most important features of the Visual Studio .NET IDE debugger.You will take a detailed look at all of these as the chapter progresses. Many of these features have existed in the Visual Studio 6.0 IDEs; however, not all were previously available when debugging traditional ASP pages in Visual InterDev.

Call Stack

The call stack enables you to display the list of functions currently called. As the name implies, this can be imagined simply as a stack. (As functions are called from within function, which, in turn, are called from within functions, a stack is created.) With the call stack viewer, you can look at this stack and jump forward and backward into the stack to debug at any point in the chain. Figure 7.1 shows the call stack in action.

Command Window

If you have used the Visual Basic IDE previously, the command window will be quite familiar to you.The command window enables you to execute program statements separately from the running program. For example, if you want to set a variable equal to a new value, or if you want to print the value of a variable, or even if you want to create an object and call some methods on it, you can do it from this window. Figure 7.2 shows how the command window can be used.


Breakpoints enable you to stop the execution of a program at a defined point either in all instances or based on a certain set of criteria. The easiest way to set a breakpoint is to click in the gray left margin next to the line where you want to stop. The IDE drops a red "dot" in the margin; when you start the program in debug mode, it stops at that specified position. By popping up the breakpoint window from the debugging windows at the bottom of the screen, you can see all breakpoints currently set in the system. Figure 7.3 shows an example of the breakpoint window.

Watch Window

The watch window can be used to watch the contents of a variable or series of variables. This window also enables you to change the value of a variable, which can be quite useful in debugging applications.You can see an example of the watch window in Figure 7.4.


Tracing simply enables you to write out a series of text messages as the program is executing so that you can see what is happening at any point during the program's life cycle. This can be very useful in creating a log of events that can be inspected later to ensure that the program is operating as you expect in all aspects. Figure 7.5 shows an output from a Debug.Trace statement in the output window.

Attaching to Processes

At some point you might need to attach to a process running somewhere on the computer and debug it from within the ASP.NET page. This could be the ASP.NET process, aspnet_wp.exe, or another running service, or any other program running on the server. This can be accomplished quite easily.

Under the Debug menu you will find the Processes selection. Clicking this brings up the dialog box in Figure 7.6.

By default, you will see only the processes that you have started in some way. If you click the Show System Processes check box, you have access to everything that is running on the current machine. Click the process to be debugged, and then click the Attach button. Now, if that process hits a breakpoint or any other type of debugger event, that event pops up in the Visual Studio .NET IDE.You can also force the program to break by clicking the Break button at the bottom of the window. At any time, you can stop debugging the process by clicking the Detach button.Terminate kills the process altogether.

After clicking the Attach button, you are given a choice of what type of debugging you want to do on the process you've selected. Figure 7.7 shows an example of this dialog box.

If you are attaching to a .NET process written using the Common Language Runtime (CLR), choose the Common Language Runtime option from the dialog box. If you'll be breaking into a process that uses Microsoft Transact SQL language, check Microsoft T-SQL as your debug type. Native enables you to debug a standard Win32 application.This enables you to debug a Win32 program at an assembly lan-guage level. Finally, the Script type gives you the capability to debug standard Visual BasicScript and JavaScript.This is especially useful for debugging an instance of Internet Explorer.

Setting It All Up

There really isn't a whole lot to mention here. It is extremely simple to use the Visual Studio .NET IDE for debugging ASP.NET pages. In most cases, it will be a plug-and- play affair. The default debug build of any ASP.NET project will have everything set up for you to begin. However, even though that probably will be the case, we will discuss what is absolutely required for the debugging to work, just in case something goes wrong.

Take a look at the web.config file contained in your project.This is an XML file that contains specific configuration information for your ASP.NET project. One line in this file will look similar to the following:

<compilation defaultLanguage="vb " debug=="true " //>

The defaultLanguage parameter will be based on the default language of your ASP.NET project. But what we are concerned about here is the debug parameter. If you are running in a debugging environment and want to be able to access the spiffy features of the Visual Studio .NET IDE, this debug parameter must be set to true , as it is in the previous line. If it is set to false , none of the features will work.This is what you want for a release build of your project.

Inline Debugging of ASP.NET Pages

This is so very easy—you're going to be extremely happy about this. If you've ever debugged a program using Visual Studio 6.0 (Visual Basic,Visual C++, and so on) you will feel right at home with what you are about to learn about Visual Studio .NET. Let's discuss these great features using a sample project mentioned earlier in the chapter. As usual, both Visual Basic .NET and C# versions of the code will be provided for you to see.

This sample project will consist of an ASP.NET page and a Visual Basic .NET/C# component so that you can see how easily the two interact and how they can be debugged simultaneously. The project itself will simply ask the user for a valid email address and then send a form letter to that address. Start out by creating the project. We called ours Chap5Visual Basic for the Visual Basic .NET version and Chap5CS for the C# version.

The first thing to do is create the ASP.NET page that the user will see. Listing 7.1 contains the main ASP.NET page that contains the input form on which the user can enter the email address where the mail will be sent. Here the page name is left as WebForm1 , the default name provided when the project was created....

Meet the Author

Jonathan Goodyear began his career as a software developer at Arthur Andersen after receiving a degree in accounting and information technology from Stetson University. He has also worked as a consultant for PricewaterhouseCoopers and as the Internet architect for the Home Shopping Network's e-commerce presence (http://www.hsn.com). Presently, he works as an independent consultant through his consulting practice, ASPSoft, focusing on developing web applications with ASP.NET.

Jonathan is a contributing editor for Visual Studio Magazine (http://www.vbpj.com) and is a charter member of the Visual Studio 6 MCSD certification. He is also the founder and editor of angryCoder (http://www.angrycoder.com), the first eZine written completely in ASP.NET. When not hunched over a keyboard, Jonathan likes to spend time going to theme parks with his family near his home in Orlando, Florida.

Brian Peek is a senior software developer with Rapid Application Developers, Inc. (http://www.rapiddevelopers.com/) located in Troy, New York. He specializes in developing n-tiered applications, web-based applications, wireless applications, and any other projects that happen to come along. Additionally, he is the owner and lead programmer of Ganksoft Entertainment (http://www.ganksoft.com/), a small video game¿development company dedicated to producing high-quality games for video game consoles using only freely available tools and documentation. He holds a bachelor's degree in computer science from Union College in Schenectady, New York, his hometown. When not coding for work or coding games that he wishes would be published commercially, he can often be found practicing magic, learning to play piano, or playing his latest favorite video game. He can be reached at brian@ganksoft.com or brian@rapiddevelopers.com.

Brad Fox started programming in BASIC at the age of 12. Since then, computers and technology have played an integral part in his life. Brad joined the Army right out of high school and served in the 82nd Airborne Division. Since then he has gone on to become a Microsoft Certified Solution Developer. Currently, Brad is CEO of Digital Intelligence, Inc., where he spends most of his time developing cutting-edge technology for the financial industry.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews

Debugging ASP.NET 4.3 out of 5 based on 0 ratings. 3 reviews.
Guest More than 1 year ago
This book is an excellent book for ASP Programmers. Excellent book that introduce you to ASP.Net concepts w/ applicable examples. Interesting approach to introduce microsoft's new platform to developers. Easy, couple-nights reading before bed.
Guest More than 1 year ago
This book will save experienced, as well as newbies a lot of time debugging ASP.NET, as well as ADO.NET, Server Controls, COM+ interop, pretty much anything you can do with .NET. Good coverage of VB.NET as well as C#. I did not realize that VB.NET, and C# had different error messages. This book explains the different messages as well as strategies for avoiding them in the first place. All in all this book will save you a lot of time, much more than the book costs. A must have for any serious developer.
Guest More than 1 year ago
I have to say that even though the book says that its for intermediate to experienced programmers it really should say that it is for beginners to intermediate programmers. I say that because a lot of debugging skills suggested in this book come with experience to advanced programmers. However this book does list a whole bunch of gotcha's when using not just ASP.NET, but also some of the advanced features of ASP.NET like User Controls and Caching, Http Handlers, etc. This books also lists some pitfalls to be aware of when using Serviced Components (COM+). These features would be useful for Beginners or Intermediates but the Advanced developers of ASP.NET would already be familiar with some of the techniques listed like Tracing, Conditional Compiling, writing to the event log etc. I would recommend that if you are new to ASP.NET and have just finished reading a book on ASP.NET, pick this book up next to read about some gotcha's when using ASP.NET