Installing MS debug DLLs for remote debugging

Question

I have a .NET app that I would like to install on a VM for remote debugging purposes.

The app uses a native VC++ DLL which links to MFC and the MSVC runtime libraries via DLL.

When I run depends on the VM, it says that the DLL needs the following DLLs:

mfc90d.dll    
msvcm90d.dll    
msvcp90d.dll    
msvcr90d.dll    
msjava.dll

Also, it reports the following error:

Error: The Side-by-Side configuration information for [dll path] contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).

I'd prefer not to have to install the complete Visual Studio 2008 on the VM just to debug this.

What is the best method for installing the required DLLs onto the VM?

Answer 1

The debug DLLs are provided in the vc\Debug_NonRedist subdirectory. Properly deploying them is explained in this MSDN Library article.

Answer 2

It is possible to install the debug redistributable files for VC++. Microsoft even gives them to you. You just have to stay clear of the ones found in system32 directory as they don't work by simply copying them over to another machine.

Check out this blog: http://wdy501.blogspot.com/2010/07/dealing-with-visual-studio.html

And I used the blog to find the debug .dlls for VS 2012 and was successful in copying them over to another machine and running a debug version. Just be aware that MS puts the "debug_nonRedist" files in a directory structure labeled "Microsoft Visual Studio 11.0". Here is the full path I found the CRT debug dlls I needed:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC110.DebugCRT

The only benefit I see for myself in using the debug versions is that I can stay in debug mode on my developing computer and quickly take the code over to another computer for testing under a slightly different environment. I see no good reason to use a debug version in the final release.

Answer 3

There is/was a bug in vs2008 after the SP1 update where the manifest versions were not updated. To get around this I had to do this on the remote machine:

edit Microsoft.VC90.DebugCRT.manifest change version="9.0.30729.4148" to version="9.0.21022.8"

edit Microsoft.VC90.DebugMFC.manifest

change version="9.0.30729.4148" to version="9.0.21022.8"

[update] In looking for a reference for this I found

Important: If you do this with Visual Studio 2008 SP1, make sure you put the following in your precompiled header:

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

http://qualapps.blogspot.com/2008/07/visual-studio-2008-c-redistributable.html