Remote Debugging basics
Here is the article that explains the basics for remote debugging in details: “Remote debugging with Visual Studio 2008”
The summary from the same article:
Getting the remote debugger to work
To get the remote debugger up and running, you must install it on the remote computer (ie, the server in the previously described scenario) and then configure it. Configuration is complex because the remote debugger authenticates both ways; that is, the machine running Visual Studio needs to authenticate on the remote machine, and the remote machine needs to authenticate on the machine running Visual Studio.
Installation
When you install Visual Studio 2008, remote debugging components install by default. In addition, the remote debugger is readily available on the Visual Studio installation media. The installation disc contains a directory called Remote Debugger, which has two folders (x64 and x86) that contain the set-up application for the specific platform. This installs the remote debugging monitor (msvsmon.exe). In my example, it is installed on a server.
Once the installation application runs, the configuration wizard runs. The configuration wizard allows you to set up the remote debugger to run as a service or as an application. Running the remote debugger as a service means that it will run all the time, so you may want to run it as an application so it can be run only when needed. At this point, security becomes an important aspect of set-up.
Security
The remote debugger must run using a user account that has the appropriate privileges. It must use an account that has at least the same privileges as the account used to run the application being debugged.
When working with ASP.NET applications, the ASP.NET worker process (aspnet_wp.exe) usually runs with an account called ASPNET, so you must use this account (or an account with equal or greater privileges) to remotely debug it. A safe bet is running the remote debugger with administrative level access, but this is not advisable for a production environment since the remote debugger needs to communicate with your debugger via the network, thus putting the server at risk of being hacked. I like to create a specific account for the remote debugger with a name like VSDebugger and make sure it has appropriate access.
Using the remote debugger
Once you install all the components, you can use the remote debugger with your own applications. Follow these steps to use it with a C#/VB.NET application:
|> In Visual Studio, choose Properties on the Project menu.
|> Select Debug from the Properties page.
|> For the Start Action setting, select Start External Program and in the field type the complete path to the executable on the host computer (running the remote debugger monitor).
|> Under Start Options in the working directory box, type the directory where the executable is located.
|> Select Use Remote Machine and type the name of the remote computer in the field. You can specify any command line arguments to pass to the application on the remote computer.
|> Start the Remote Debugging Monitor on the remote computer.
|> In Visual Studio, you can begin debugging the application via the usual Debug menu by selecting Start to begin a debugging session.
When working with an ASP.NET application, be sure to reference the remote computer by name and not the IP address. Also, the application's web.config file must have the debug attribute set to True. The site's security settings must allow windows authentication (or anonymous), and make sure there are no firewall restrictions that may disable remote debugging. MSDN offers more information about setting up remote debugging.
Go to the source
Visual Studio 2008's remote debugger feature allows you to investigate code issues where they occur. You may use Visual Studio on your development machine and connect to the problem code on a remote host; this allows you to find problems specific to the host environment. During set-up, it's important to use the proper accounts with necessary access. Add the remote debugger to your developer toolbox for those situations where problems are unique to an application's environment.