Testing VS2005 Debug Version on a Non Development Machine

1. Overview

Ever had the need to test a debug version of your code on a clean non-dev machine, but failed to do so because the application crashes on startup?

In Visual Studio 2005 (I am not familiar with the situation in other versions), one cannot execute debug versions of compiled code¹ on a non-dev machine².
This happens due to that fact that Microsoft removed the debug version DLLs from its redistribution pack (though I'm not sure why they did it).

2. The Solution  

The common solution to the problem at hand is to install VS2005 on the test machine. It is done by many. But then again - that’s not really why you're reading this article, right?

Turns out Microsoft has a built-in solution to the problem. I found it to be well hidden to the naked eye. That's why I wrote this article.

2.1 Special Note

Before continuing, I would like to emphasize that this solution should be used for internal testing (on test machines) only.
Microsoft End User License Agreement (EULA) prohibits redistributing the debug DLLs to customers.

Now that we got the legal stuff covered, I'll let you in on the secret.
The way to enable debugging on a non-dev machine is to create a setup application that will deploy the debug DLLs to the machine. The setup application will come in a modest size (~8MB).

To install a VS2005 DVD or an 8MB setup?.. hmm..

2.2 The Steps for Creating the Setup Application  

1. Create a new setup project under Visual Studio 2005 (File / New / Project / Other Project Types / Setup and Deployment).
2. In the Solution Explorer, right click on the project’s name and select Properties.
3. Set the Target Platform property value (e.g. x86).
   You may want to alter the Title, ProductName, etc. at this point.
4. In the Solution Explorer, right click on the project’s name and select Add / Merge Module.
5. From the list of modules, pick the ones that begin with Microsoft_VC80_Debug (the ones that begin with policy_8_0_Microsoft_VC80_Debug will be added as detected dependencies).

We're practically done. You may build your solution now.
I recommend building the release version of the setup program (no worries - it will still install the debug version DLLs :)).

All is nice. Nonetheless, I suggest the following enhancements.

2.2.1 Removing the Installation Folder Wizard Page 

The Installation Folder page lets the user select a destination folder for the setup files. However, since we're dealing with debug DLLs that will be copied to the system folder, this page is redundant and may be disposed of.
To do so:

1. Left click the project’s name - an icons toolbar will appear at the top of the Solution Explorer window.
2. Select the User Interface Editor - a tree with the setup pages will appear.
3. Remove the Installation Folder node from both installation flavors.

2.2.2 Warning  Message

The User Interface Editor is already open. You may find it useful to put a nice warning message, stating that this application is designated for internal use only and may not be distributed outside company boundaries. Easy does it:

Right click the Welcome page, select Properties Window and update the CopyrightWarning as needed (you might want to alter the WelcomeText as well - up to you :)).

2.3. To Finalize

• Compile the setup project.
• Copy the resulting *.msi and setup.exe files to the target machine.
• Install. 
• Cross your fingers and run your debug version.

Worked for me!

Disclaimer 

In this part, I would like to officially inform you that exercising the so-noted suggestions is at your own risk and I take no responsibility for any corruption that may be introduced due to any of the above.
(*) 'Any corruption' includes (but is not limited to) breaking a fingernail due to a bad execution of fingers crossing (!)
Be warned!

Still.. Worked for me :)

^1. My specific case is an MFC application with integrated .NET code (particularly - WinForms code involved) in both C++/CLI and C# DLLs.

^2. By non-dev I mean a machine that doesn't have Visual Studio 2005 installed on it, e.g. lab machines, QA machines, etc. 

History

• 17^th February, 2009: Initial post