Remote debugging with Visual Studio 2008 ASP.netASPUPVB.NETVB

I recently examined the JavaScript debugger features in Visual Studio 2008 that aid in locating problems in Web pages. But if you often have to track down bugs in an application installed on another machine, you should check out Microsoft's remote debugger tool with Visual Studio 2008. Here's a closer look at its set-up and usage.

Example scenario

You develop an application and then deploy it to another server when a problem occurs. The code works on your development system, so finding the bug just became more complicated. You may have access to the application environment, but you rarely want to install a full copy of Visual Studio on a server. This is where the remote debugger enters the picture.

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.

What debugging tools or techniques do you use in your projects? Have you ever used the Visual Studio 2008 remote debugger? Share your thoughts and experiences with the Web Developer community.