Describes debugging ASP.NET Web services. Information includes: debugging a Web service on //localhost, debugging a Web service on a remote server, and debugging a deployed Web service.

As your ASP applications get more advanced and grow in size, little bugs start becoming very difficult to catch and fix! It is important to grow your debugging skills while you grow your coding skills! Here are some tips that will hopefully aid you in your debugging.

In this article Matt shows how he debugged a Windows 2000 Server (ASP/COM) application with a very simple solution -- which was very difficult to find!The purpose of this article is to outline our server debug process from one very general server symptom: Server ”II” would stop responding to external requests. I thought it would be beneficial for Admins and Developers to see the process and pitfalls of debugging large Microsoft enterprise applications. For this article, I refer only to server “II” and “I” for simplicity in our cluster. In all, the application contains about 500 asp pages (2 extranets, 1 intranet), 10 server DLLs, 25 library DLLs and 15 report DLLs.

Debugging a Windows Forms application is similar to debugging in Visual Studio 6.0, but debugging a ASP Web App is not as obvious. Thanks to the "BugSlayer" at Tech-Ed, it's not as bad as "all that". You can use the debugger like you normally would do in Visual Studio. You just need to attach a process. This article will bring you through the steps needed to "get attached".

Describes debugging ASP.NET Web services. Information One of the nicest parts of ASP.net debugging is what I call post-mortem debugging...One of the most challenging aspects of Active Server Pages (ASP) development prior to .NET was debugging and tracing.

A major benefit of the .NET Framework is that whatever language you choose to program in, everything is compiled to an identical Microsoft Intermediate Language (MSIL). As a result, the only debugger needed is the one in VS.NET, and this is as powerful as ever, with cross-language debugging of the .NET languages, scripting, SQL, Win32 native applications, and server processes.

Believe it or not, there is really nothing special about the process of debugging a Web form. You do things like set breakpoints, step through the code, examine variables, and so forth. Unfortunately, the debugger is not set up out-of-the-box. You need to configure it yourself, which requires two steps:

The System.Diagnostics.Debug class provides methods for writing debugging output and validating assertions. It has an Assert and Fail method with multiple signatures to suit different situations. The methods of this class are defined with the Conditional attribute discussed earlier. So the compiler variable DEBUG must be defined for these methods to be called. In Visual Studio .NET DEBUG is defined by default during debug builds. Thus, the use of the methods of this class does not affect performance or size of release builds.

During the last several months, I have dealt with many users from both inside and outside of Microsoft who have debugging issues. I noticed that there are many common mistakes and problems that can be solved, if users are provided with proper diagnosis. Hence, I’ve written this document to provide you with this information which will help you if you run into any issues while using the debugger.