Remote Debugging in VS 2005

What do you do when you cannot reproduce an issue that is occuring in production in your development environment? Enter the nightmare that is Remote Debugging. For the better part of a day, I have been trying to remotely debug my Exchange transport agent on a production system. Unfortunately, I cannot reproduce the error in our development environment and I cannot install VS 2005 on the Exchange server, so I am forced to pull apart the DLL in production to see exactly what is going on. Well, to my surprise, Microsoft apparently wanted to make this as difficult as possible to accomplish. After scouring the Internet, I seem to have found a solution. Some notes that may save you some time:

  • To enable Remote Debugging, you need to run the MSVCMON.EXE file for your platform located under Program Files\Microsoft Visual Studio 8\Common 7\IDE\Remote Debugger (if you are on an x64 machine, the x86 version will be under Program Files (x86) and the x64 version under Program Files).
  • Be sure that the version of MSVCMON.EXE matches the version of VS 2005 on the debugging system.
  • The system running VS 2005 will need to know the path to the symbols file on the remote system. It is best to copy the symbols file to the same location as your DLL and set the path under Tools > Options > Debugging (tick Show all settings) > Symbols. Click the folder icon and enter the UNC path to the appropriate location. It is also best to browse to that folder via My Computer to ensure the debugging system can connect to the UNC share properly.
  • If your system running VS 2005 is behind a NAT firewall, forget about using Remote Debugging. All the testing I have performed and all the information I have found simply says this will not work. Furthermore, you will run into all kinds of problems if there is a firewall between the systems. It is best to use a system on the same subnet as the remote system.
  • Debugging managed code will not work using the “Remote (Native only with no authentication)” transport or “No Authentication” mode (as indicated by the “native only”) meaning you will have to enable authentication (use “Default” transport). Note that you can view the output of debug messages using the No Authenticate mode, but you will not be able to step through code or set breakpoints.
  • If the systems are not in the same domain or in domains that do not have trusts configured in both directions, you will need to create local users on each system so neither box can be a domain controller. The local users will need to have the same username and password.

Outlook 2007 Form Regions

New to Microsoft Outlook 2007 is Form Regions. These nice little pieces of code attach as “sub-forms” to existing forms in Outlook 2007. You can have them display adjoining to the standard Outlook form, as a separate tab, or replace the Outlook form entirely. Technet has a few great samples to play with:

Walkthrough: Creating an Outlook Form Region
http://msdn2.microsoft.com/en-us/library/aa942741(VS.80).aspx

Building an Outlook 2007 Form Region with a Managed Add-In
http://msdn2.microsoft.com/en-us/library/bb226713.aspx

Outlook 2007 Sample Add-ins: Rules Add-in, Travel Agency Add-in, and Prepare for Meeting Add-in
http://msdn2.microsoft.com/en-us/library/bb226710.aspx

You really have free reign with what you can do here … except that form regions do not currently support managed controls, meaning you’ll need to stick with ActiveX controls for now … though any ActiveX control will work. Here’s a screenshot from an “alpha” version of our ticketing system that uses form regions:

Screen1

The nice thing with forms regions is that they can attach to a standard Outlook form or to a customized form and they finally look and feel like part of Outlook. No more Office 97 style controls. The controls can access user defined fields or, like in our case, we populate them with data from SQL.