2
votes

I have a C++ project I am building in VS2008. This project also links against a library (DLL + Import lib) that was built using VS2005 and thus loads VS2005 debug CRT library (everything is a debug build).

When attempting to run this executable built in VS2008, I get an error on loading due to that VS2005 DLL not finding the Debug CRT libraries, even though I have VS2005 installed with SP1. I've checked Windows updates too, so I'm not really sure what more I can do.

How do I diagnose this problem? I've looked at the Event Viewer in Windows and noticed that it can't find the debug VC80 CRT library, but that's all I know. There's a version mismatch somewhere in here I guess, I just don't know how to fix it since I don't know much about this manifest/side-by-side stuff.

The OS I'm building on is Windows XP 32-bit. I have VS2008 SP1 and VS2005 SP1 installed (so all debug manifests/CRT dlls should be available)

1
Do I understand this correctly that you have an executable A that uses VS2k8 dynamic libs, and a DLL B that uses VS2k5 dynamic libs? Lib mismatches are likely not going to fly.user7116
@sixlettervariables: That's correct. But it should work (and does work on a Windows 7 machine). But I'm trying to setup my environment and get it working on a Windows XP machine (same code, same DLLs) and it's just not working. I've gotten it to work on Windows XP before, but it's difficult to get consistent results. It seems like the slightest difference in Windows updates causes everything to break.void.pointer
I've had a lot of trouble with similar setups. It's better to either include the original required DLLs (not the full CRT) and best to rebuild in the same CRT from the sources.MPelletier
@MPelletier I'm not sure what you mean.void.pointer
You cannot deploy a program that has a dependency on the debug CRT, it will only be available when the machine has VS installed. You also really want to avoid having one program using multiple versions of the CRT, it can cause hard to diagnose memory corruption and leaks. You will need to rebuild the DLL.Hans Passant

1 Answers

0
votes

Learn to check or create or check appropriate assembly manifests.

Here is more info once you get that done.

On Windows XP, if an external manifest is present in the application's local folder, the operating system loader uses this manifest instead of a manifest embedded inside the binary. On Windows Server 2003 and later versions of Windows, the opposite is true—the external manifest is ignored and the embedded manifest is used when present.