Hello all,
Firstly, release builds are fine. I need help with Debug builds on a couple of test machines - not end-user machines.
I have a 3rd-party DLL that's been built as Debug with VS2008. My VC++ code uses this, & compiles in 2010 or 2012 (in W7). However to build & run in 2012 or 2010 on my dev machines, I need to also have VS2008 installed, just so that the Debug CRT DLLs are available, so that my 3rd-party DLL can load (as part of my VS2012 Debug app). I appreciate that I'm not allowed to redistribute the debug DLLs.
I'd like to avoid having to install VS2008 on all my dev machines. So I need to deploy the VS 2008 version of msvcr90d.dll on those machines. However I've been unable to do this. I've read various articles about manifests, about removing the public-key from the Microsoft.VC90.DebugCRT.manifest file (or not). I've tried adding this manifest file to my VS2012 project, but nothing works. I can link, but not run.
Has anyone actually managed to get the debug VS2008 CRT dll msvcr90d.dll installed on a machine that doesn't have VS2008 installed? I don't want to add it to the winsxs system cache - I just want a side-by-side install for testing my app.
Thanks!
Tim.
You should ask/buy updated DLLs from the third-party vendor. This will avoid you problems and maybe even fixes some problem that the vendor has fixed since then.
Maybe an alternative would be to install the Express version of Visual C++ 2008 on your other computers.
On the other hand, it might not be a good idea to install older version after the newest one anyway as it might be less well tested and it might affect newer installations somehow.
Maybe the best thing to do would be to only use release version on that other computer and do main debugging on the one that has VS 2008 installed.
Finally, what about using the release version of the third-party DLL? Does it cause you any problem?
Posted 28 Jan '13 - 15:23
There are compiler options, in the Properties/C++/Code Generation/Runtime Library.
If you link with Multi-threaded (/MT or /MTd) you don't need to deploy runtime separetaly, because it is linked statically. You need to deploy the runtime if you link with Multi-threaded DLL (/MD or /MDd).
After installing the distributable package for VS2008, find the release version of the dll and add the debug dlls to the same directory. [I assume that this still works; I used to do it up to about VS2003 or so.]
Note that the debug dlls are not a part of the distributable package and are not licensed for distribution. Microsoft used to have a tech article on how to install the debug dlls when trying to debug a problem on a specific machine, but I can't find it anywhere (and it might be obsolete/wrong with VS2008).
One other thing that is troublesome in your problem statement is that you seem to be mixing debug and release DLLs in your development code. You should only use one environment or the other, or you will experience a lot of GPFs and BSODs. If you are developing code where new/delete for a class is done in different DLLs for example, you will potentially mess up your heap. Many structures are different sizes in debug and release versions.
tl;dr: You are looking for trouble if you mix debug/release DLLs in an app.
Posted 25 Jan '13 - 16:13
I believe if you copy and paste the MFC dlls and manifest file onto the same directory as the file which requires it (exe or dll) it will use it. It does require the manifest file otherwise if won't find them there. I've done this before and it works fine.
This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
Submit an article or tip
Post your Blog