How to deploy Debug CRT VS2008 msvcr90d.dll on W7 test machine?

Question

4.00/5 (1 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.

Thanks!
Tim.

Posted 24-Jan-13 10:58am

Tim Stevens

Add a Solution

5 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

H.Brydon · Answer 1 · 2013-01-25T16:13:00

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.

Posted 25-Jan-13 16:13pm

H.Brydon

Comments

Sergey Alexandrovich Kryukov 25-Jan-13 22:59pm

Agree, a 5.
—SA

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.

H.Brydon 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.]

Albert Holguin · Answer 2 · 2013-01-25T08:08:00

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.

Posted 25-Jan-13 8:08am

Albert Holguin

Comments

Sergey Alexandrovich Kryukov 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.

—SA

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.

Sergey Alexandrovich Kryukov · Answer 3 · 2013-01-24T11:38:00

Solution 1

You need to install only one package, Microsoft Visual C++ 2008 Redistributable Package: http://www.microsoft.com/en-us/download/details.aspx?id=29[^].

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

—SA

Posted 24-Jan-13 11:38am

Sergey Alexandrovich Kryukov

Comments

Albert Holguin 25-Jan-13 14:06pm

OP posted comment directed at you in Solution 2.

H.Brydon 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.

Sergey Alexandrovich Kryukov 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?
—SA

H.Brydon 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.

Sergey Alexandrovich Kryukov 25-Jan-13 23:00pm

I just commented. I think I agree with your answer, up-voted it.
—SA

armagedescu · Answer 4 · 2013-01-28T00:31:00

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).

Posted 28-Jan-13 0:31am

armagedescu

Comments

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.

Philippe Mori · Answer 5 · 2013-01-28T15:23:00

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?

How to deploy Debug CRT VS2008 msvcr90d.dll on W7 test machine?

5 solutions

Solution 4

Solution 3

Solution 1

Solution 6

Solution 7

Add your solution here

Preview 0

Existing Members

...or Join us