Click here to Skip to main content
13,552,297 members
Rate this:
Please Sign up or sign in to vote.
See more:
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.

Posted 24-Jan-13 10:58am
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

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.
SAKryukov 25-Jan-13 22:59pm
Agree, a 5.
Tim-Stevens 26-Jan-13 10:56am
Thanks. However I'm not mixing debug & release at all: The Release configuration works fine. One component I use (written by someone else, no source), exists as both release DLL & debug DLL. When I build my code Debug, I link against their Debug DLL, & when in Release, I link against their Release DLL. Their DLL is built with VS2008. All I want to do is (when built Debug) as part of my testing, put my Debug build on another machine that does have VS2012, but does not have VS2008. To do this, I have to get the debug runtime (msvcr90d.dll) onto that specific machine.

I know that in VS2003 & earlier you could simply copy the DLLs. However now, you can't (well, you can copy them, but it doens';t load). Additionally, even as an Admin command prompt, I can't copy anything to winsxs (W7/64). I've come to the conclusion that this is impossible, or at least not worth the effort. Why does MS always make Windows stuff so difficult?
Philippe-Mori 28-Jan-13 21:15pm
I think he was talking about mixing different versions (VS 2008 and VS 2012) of the runtime DLLs in the same application which can lead to subtil problems.
HarveyBrydon 26-Jan-13 13:53pm
Ouch - too bad that the copy trick doesn't work any more. The debug dlls have never been licensable for redistribution and Microsoft did not provide them in the redist kits. It seems that they have specifically broken the copy trick. The OS now recognizes the difference between dlls copied to a "sensitive" area and dlls that have been installed from a .msi file. One possible solution would be to build a debugdlls.msi that install the debug dlls that you want.

Ask Google about "VS2008 deployment project". [You don't want a web deployment project, which seems to be popular.]
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

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.
SAKryukov 25-Jan-13 14:12pm
I would agree, a 5.

Thank you for sending me a notification on OP's post. Please see my comment on it.

Tim-Stevens 26-Jan-13 11:02am
Thanks (I'm not using MFC at all by the way). Tried it - used Process Explorer from sysinternals on my 2008/2012 machine to identify the precise version of the DLL & manifest being loaded. COpied the manifest & DLL onto the 2012 (no 2008) machine. Still will not load. Specifying the manifest for that DLL in the 2012 linker makes no difference. Removing the public keys from the manifest makes no difference.

Maybe I'm being stupid, but I can't get this to work, sorry. If someone can write a 'hello world' CRT-app in VS2012 or 2010, in debug mode, and then get it running (as a debug build, linked against the debug runtime DLLs) on a 2nd machine that does not have VS installed, then this is basically analogous to what I'm trying to achieve - I've been unable to run any debug-linked code on a machine that does not have that version of VS installed.

I'll just have to get the others in the team to all install VS2008 just so we can run the debug build of our 2010/2012 app, I guess.
Albert-Holguin 26-Jan-13 16:51pm
I've done this before but I can't remember the details about it. Seemed relatively trivial at the time but I don't really remember exactly how I did it. Maybe you can just try a few different things until you get it, I'm away from my dev machines for the weekend so I can't help with specifics in the mean time.
Tim-Stevens 26-Jan-13 17:10pm
Thanks Albert. I can't help thinking I've missed something obvious, but I can't get it to work. SInce it's only for development, it's not really a problem, but I can't help thinking it must be solvable. It seems users (even running as Administrator) can't drop files into winsxs, & I've not managed to get a side-by-side install in the app's directory to work. All the examples I've found on the net refer to the release DLLs, I suspect.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

You need to install only one package, Microsoft Visual C++ 2008 Redistributable Package:[^].

You should be able to find and install similar package for others instruction-set architectures you need to use.

Albert-Holguin 25-Jan-13 14:06pm
OP posted comment directed at you in Solution 2.
HarveyBrydon 25-Jan-13 22:05pm
Negative - this does not solve the problem. Note that OP cites "msvcr90d.dll" which is a debug DLL and not in this package. Debug dlls are not licensed for distribution. Every system with the debug dlls is supposed to be licensed for visual studio.
SAKryukov 25-Jan-13 22:31pm
What's "negative", exactly? Answering does not mean solving the problem. Do you know the solution? I already told that debug DLLs are not redistributable. You debug with debug version, and that deploy non-debug version. Normally, debugging at customer's site is not an option. Isn't it logical?
HarveyBrydon 25-Jan-13 22:57pm
Yeah, I see you replied in another solution (your comments in #2 are correct). As for solution #1 though, your info is not correct and doesn't solve the OP problem and you don't mention debug dlls.

See what I said in solution #4.
SAKryukov 25-Jan-13 23:00pm
I just commented. I think I agree with your answer, up-voted it.
Rate this: bad
Please Sign up or sign in to vote.

Solution 6

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).
Tim-Stevens 28-Jan-13 8:39am
Thanks, however the 3rd-party DLL uses DLL (not static) linking against msvcr90d.dll. So even if I change all my code to static linking, the msvcr90d.dll DLL still gets loaded, since the 3rd-party DLL requires it. Otherwise your suggestion would work.
Rate this: bad
Please Sign up or sign in to vote.

Solution 7

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?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web04 | 2.8.180515.1 | Last Updated 12 Feb 2013
Copyright © CodeProject, 1999-2018
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100