deploying msvc apps compiled in debug mode on another machine

[cptG]

hello!
i'm developing an app using Qt for my company. in order to be able to get minidumps when the app crashes during testing on my colleagues' machines, i switched from mingw32 to msvc (visual studio 2008).
if i'm not completely mistaken, the app needs to be compiled in debug mode in order for the minidump to make sense. but unfortunately i can't start the app on another machine if it's compiled in debug mode...
the errors are:

This application has failed to start because the configuration is incorrect. Reinstalling the application may fix this problem.

and after shipping with the msvcrt and mfc dlls from the redist/debugNoRedist-folders including manifests in the bin-dir:

The application could not be initialized properly(0xc0150002)
i compiled the app with

CONFIG+=embed_manifest_exe
DEFINES += _BIND_TO_CURRENT_VCLIBS_VERSION

checking the .exe with depends.exe, i see that there are only two dlls missings, which are loaded on-demand and they are missing on my machine, as well, so this shouldn't be an issue.

any hints?

thanks,
thomas

[borisbn]

I beat this problem by copying folder C:\Windows\winsxs to a target computer in the same place.
But, if I don't mistaking, it's not a legal way. M$ said, that you can redistribute ONLY release version.

[amoswood]

First ...

checking the .exe with depends.exe, i see that there are only two dlls missings, which are loaded on-demand and they are missing on my machine, as well, so this shouldn't be an issue.
I have found that using the depends.exe is unreliable for how that Microsoft uses side-by-side assemblies. So, a program always shows up with missing DLLs even though they aren't missing.

Second...
Instead of shipping with the msvcrt and mfc libraries, I would use the VC redistributable that Microsoft provides. To make a long story short on side-by-side assemblies, the Microsoft redistributables will be installed in the Windows directory where all applications can find them whereas the DLLs that you ship won't be.

Finally...
You need to make sure that you ship the MSVCRTD (debug version) dll library because it is a debug version.

[cptG]

first of all, i don't get the logic behind microsoft's assumption that debug-exes don't need to be distributed - like app-testing would only be done on the developer's machine... anyway...
i did ship the debug-dlls, i made sure of that. in fact, while the despair was growing i just slapped all .dlls and manifests i could find in \Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86 into my app's bin-dir.
about the WinSxS-solution: i don't wanna do that because, as borisbn said, it seems quite inelegant.
the step i took now was to make a setup-project with visual studio and include the proper .msm there (though it didn't list it as dependency, just to be sure ;) ) it made a nice msi-file with all files i told it to pack up, nice feature i must admit (i'm a visual studio noob)
i just sent the .msi to my colleague for testing, along with the hint to make sure that the latest service pack and the latest .NET-framework 3.5 SP1 is installed, cause i found these to be sollutions for the 0x10something error-code.
i'll let you know if this is solved the problem.

edit: amoswood, i did install the vcredist_x86.exe on that machine, but it only ships release-dlls if i'm not mistaken (according to MS's logic i would assume that) and one for debug-dlls is (of course) nowhere to be found...

cheers, cptG

[cptG]

ok, i gave up on this one.
especially since i just found out that i can generate debuginfo for a release build as well, so i can have meaningful minidumps from those, too.

cheers, cptG