Remote debugging with Visual Studio 2008

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.