Debugging can often be handled on a
developer’s local machine, but some problems exist solely in a test
or production environment, thus requiring debugging within this
environment. Microsoft provides the
Remote Debugger with Visual Studio .NET (VS.NET) to handle
debugging an application on another machine.

Remote debugger setup

Microsoft provides two ways to debug a remote
application:

  • Remote debugging via DCOM and the Machine
    Debug Manager
  • Remote Debug Monitor

Since the second approach is more applicable to
C/C++ and native code, I’ll focus on the first one. In that method,
the Machine Debug Manager is installed via VS.NET setup. You can
install a full version of VS.NET or select the Remote Components
Setup link on the main VS.NET installation screen. This selection
provides two options:

  • Native
    Remote Debugging:     Installs components that enable a debugger to
    connect for debugging of native code only.
  • Full
    Remote Debugging:     Installs components that enable a debugger to
    connect for debugging of native code, managed code running on the
    CLR (Common Language Runtime), and script (VBScript or JScript). If
    SQL Server is installed on the machine, components for SQL remote
    debugging will be installed as well.

In this article, C# code is debugged, so
we’ll select the second option. This installs all necessary
remote debugging files on the system. Once the remote debugging
components are installed, you must set up system privileges that
allow access for remote debugging.

  • To debug another user’s
    process:     You must be an administrator on the machine where the
    process runs. This applies whether you’re attaching to another
    user’s application or working with a Web application by attaching
    to the aspnet_wp.exe process.
  • To debug your own
    process:     You must be an administrator or be listed in the
    Debugger Users group.

You’ll be working with your own code/process,
so adding your name to the remote system’s Debugger User’s group is
sufficient. At this point, the machine is ready to be used for
remote debugging.

Debugging an application remotely

With the remote machine set up, you can access
your application from your own instance of VS.NET. This assumes
that the application to be debugged is located on the remote
machine. If not, you should copy the necessary file(s) to the
machine.

The example in this article is a simple
command-line application, so the executable is copied to a location
on the remote machine. You’ll debug the following simple C#
application:

using System;
using System.Threading;
public class HelloWorld {
public const System.String message = “World”;
[STAThread]
public static void  Main(System.String[] args) {
Thread t1 = new Thread(new ThreadStart(Test1));
Thread t2 = new Thread(new ThreadStart(Test2));
t1.Start();
t2.Start();
}
static void Test1() {
Thread.Sleep(5000);
System.Console.Out.WriteLine(“1. Hello: ” + message);
}
static void Test2() {
Thread.Sleep(1500);
System.Console.Out.WriteLine(“2. Hello: ” + message);
} }

It’s a simple C# console application that uses
two threads with each thread sending output to the console.
Debugging this application requires the following steps within the
VS.NET IDE:

  1. Open the application’s project file.
  2. Access the application’s properties via the Project | HelloWorld
    Properties file menu.
  3. Select the Debugging category within the Configuration Properties
    folder in the Properties window.
  4. Change the Debugger Mode setting from Project to Program.
  5. For the Start Application setting, enter the complete path to the
    HelloWorld.exe file copied to the remote computer. (On my test
    machine, this is c:\HelloWorld.exe.)
  6. Set Enable Remote Debugging to True.
  7. For the Remote Debug Machine setting, enter the machine name or IP
    address for the remote machine.
  8. If you want to do mixed-mode debugging of managed and unmanaged
    code, set Enable Unmanaged Debugging to True.
  9. Click OK to save your changes.

Now you’re ready to debug this application.
When you choose Debug | Start from the file menu, the application
is started on the remote machine. You can set breakpoints in the
code within VS.NET, and the remote program will stop execution when
it reaches the breakpoint(s). Then, you can step through the code
(or whatever debugging action you choose) and try to pinpoint the
runtime problems—if there are any. Note: You can use the same
approach if you’re using another .NET language such as VB.NET.

Potential issue you may encounter

While the Remote Debugger is an excellent tool
included with the VS.NET IDE, you may encounter problems when you
try to use it. For instance, gaining administrator level access to
the remote machine may be restricted. System administrators get
nervous when granting administrator-level access to any machine and
equally anxious about installing new applications on the machine.
This may be more of a problem if you’re dealing with a production
machine.

Alternative approaches

Another way to approach debugging or monitoring
production-level code is recording runtime exceptions in the event
log or database, or possibly e-mailing the messages to your inbox.
An excellent approach involves using the
Exception Handling Application Block and the
Logging and Instrumentation Application Block, which are freely
available from Microsoft.

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!