Debugging Web Pages Overview
The ASP.NET page framework provides extensive support for debugging Web applications. However, because Web applications are distributed, there are some special issues associated with debugging them.
In general, you debug Web applications the same way you do other types of Visual Studio applications. You can set breakpoints, start the debugger, break into code, examine variables, and perform all the functions associated with the Visual Studio debugger. For details, see Debugger Roadmap. In addition, the ASP.NET page framework provides a trace mode that enables you to insert instrumentation messages into your forms. For details, see Walkthrough: Using Tracing in Visual Web Developer to Help Find Web Page Errors and Walkthrough: Integrating ASP.NET Tracing with System.Diagnostics Tracing.
Debugger Configuration
Web application debugging requires certain components on the computer where debugging is to happen and requires that you have adequate permissions.
Local Computer Configuration
If you are running Web applications locally on your computer—that is, the Web server is on your computer—then the computer has the correct components automatically.
You must still make sure that you have adequate permissions to debug. Users have the permission to debug processes running under their user identity, but cannot debug other user's processes. Administrators can debug any process.
Remote Computer Configuration
If the Web server is on another computer (a remote server), you must ensure that the computer is configured properly. This involves:
Making sure that DCOM is installed on both your computer and on the server. Windows 2000 and Windows Server 2003 normally have DCOM installed already, so there is usually no action required on your part.
Installing Visual Studio server-side components on the remote computer. You can do this by running the Visual Studio installation process on the remote computer and selecting the option for server components.
Ensuring that any debugger users have permissions to attach to a Web server process. This means that server processes must either run as the user (impersonation) or that users who want to debug must have administrative privileges on the Web server. (Giving users administrative privileges on the server might not be in keeping with your security policies.) You can control ASP.NET impersonation using the identity element of the Web.config file for your application. For details, see <identity> Element.
For details about configuring for remote debugging, see Debugging Web Applications on a Remote Server.
Whether you are running locally or on a remote computer, you must be sure that debugging is enabled for your Web application specifically. This is done in the compilation Element (ASP.NET Settings Schema) element of the Web.config file that is part of your Web application project. This setting instructs the compiler to insert debugging symbols into the application's compiled code so that you can use the debugger with it. You can enable debugging using the Web Site Administration Tool. For details, see Walkthrough: Debugging Web Pages in Visual Web Developer.
Debugging Client Script
Client script runs within the browser, separately from the code in your Web application, which runs on the server. You can use the Visual Studio debugger to debug client script. The debugger does not enable you to follow execution from server code to client script; however, it does support most other debugging functionality for client script.
You can debug client script in various ways. From within Visual Studio, you can use debugger commands to attach to the browser process (Iexplore.exe) and break into the script. From there, you can use the debugger as you would for any other code.
For more information see Client-Side Script Debugging.