Remote debugging an app with the DEBUG versions of the CRT when VS is not installed on the remote machine

Question

First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).

I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:

1. As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
2. Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.

Answer 1

The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.

By default, they're located in the following path:

<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist

Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.

But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)

---

Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.

To do that:

1. Right-click on your project in the Solution Explorer and select "Properties".

2. Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.

3. Expand the "C/C++" item in the TreeView, and select "Code Generation".

4. Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".

   Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)