Debugging Deployed Web Applications
If you need to debug a Web application that is running on a production server, this should be done with caution. If you attach to the ASP.NET worker process for debugging and hit a breakpoint, for example, all managed code in the worker process halts. Halting all managed code in the worker process can cause a work stoppage for all users on the server. Before you debug on a production server, consider the potential impact on production work.
To use Visual Studio to debug a deployed application, you must attach to the ASP.NET worker process and make sure that the debugger has access to symbols for the application. You must also locate and open the source files for the application. For more information, see Managing Symbols and Source Code, How to: Find the Name of the ASP.NET Process, and ASP.NET Debugging: System Requirements.
Note
Many ASP.NET Web applications reference DLLs that contain business logic or other useful code. Such a reference automatically copies the DLL from your local computer to the \bin folder of the Web application's virtual directory. When you are debugging, remember that your Web application is referencing that copy of the DLL and not the copy on your local computer.
The process for attaching to the ASP.NET worker process is the same as attaching to any other remote process. When you are attached, if you do not have the correct project open, a dialog box appears when the application breaks. This dialog box asks for the location of the source files for the application. The file name that you specify in the dialog box must match the file name specified in the debug symbols on the Web server. For more information, see Attaching to Running Processes.
See Also
Tasks
How to: Enable Debugging for ASP.NET Applications
How to: Find the Name of the ASP.NET Process
Other Resources
Debugging ASP.NET and AJAX Applications