Introduction to Web Application Debugging
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 Using the Debugger.
You can debug managed and unmanaged objects, as well as all supported common language runtime languages and script languages. For more information, see Debugging Managed Code. In addition, the ASP.NET page framework provides a trace mode that enables you to insert instrumentation messages into your forms. For details, see Introduction to Instrumentation and Tracing.
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. When you install Visual Studio or Visual Studio server components on a computer, it creates a Windows group called Debugger Users. Any developer who wants to be able to debug on that computer must be a member of that group. (Having a special group for debugger users allows the server administrator to control who has debugging privileges separately from users who have other permissions for that server.)
If you installed Visual Studio, then your user name is added to the Debugger Users group. Any other users who want to debug — other users, or you logged in under a different profile — must be manually added to the Debugger Users group.
Security Note Membership in the Debugger Users group effectively grants users administrative-level privileges. Do not make anyone a member of this group who should not have this level of privilege.
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 normally has 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.
- Adding user permissions by adding user names to the Debugger Users group.
- 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> setting 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 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. For details, see Debug Mode in ASP.NET Applications.
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 allow 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 details, see Debugging Client-Side Scripts.