Problems after compiling with Multithreaded-DLL runtime library

[Andreas Schmitt]

I am workin on a 2 part project right now. The first part is a DLL, the
second part a normal exe using that DLL.

When I use the VS2005 standard setting for compiling with the
Multithreaded-DLL runtime library (compiler option /MD )everything works
fine on my PC. But when I try to run the thing on a friends PC or my
laptop I get:

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

It works if I compile with (static)Multithreaded runtime-library
(compiler option /MT ) but of course that increases the file size
significantly.

Can someone enlighten me what the problem is here?
I always thought the only problem could be not having the MSVCR80.DLL
around, but my friend does have Visual studio 2005 installed just as I
do and copying that dll into the same folder doesn't help either.

Any help would be appreciated

 

[JS]

I had a similar problem last week. Get the vcredist off of your
computer and install it on the other computer. Perhaps you have
VS2005 SP2 and the other computer does not have SP2. That was my
problem last week.

 

[Andreas Schmitt]

I had a similar problem last week. Get the vcredist off of your
computer and install it on the other computer. Perhaps you have
VS2005 SP2 and the other computer does not have SP2. That was my
problem last week.

I kinda want to write a DLL that can be used on any Windows Platform,
whether VS2005 is installed or not.
So that as a fact means that compiling with Multithreaded-DLL runtime
library is a No-Go for that, right?

What is that good for anyway? No user of the compiled programm will have
the runtime-DLL if he doesn't have Visual2005?
When is that compiler setting useful? Just for using it for testing?
I mean I can't always distribute the entire vcredist together with my
programs just so people can run them.

 

[adebaene]

I kinda want to write a DLL that can be used on any Windows Platform,
whether VS2005 is installed or not.
So that as a fact means that compiling with Multithreaded-DLL runtime
library is a No-Go for that, right?

Not exactly.
If you compile against a DLL version of the CRT, you need to
redistribute it alongside your own binary.

When is that compiler setting useful?

Almost always. This is the recommended setting for several reasons
(eg, disk space, possibility fot the DLL to be "serviced" by Microsoft
in the case of a security patch, etc....)

Just for using it for testing?
I mean I can't always distribute the entire vcredist together with my
programs just so people can run them.

Why not?

Anyway, it all depends on how you redistribute your soft.
If you have a setup for your app, you can integrate the CRT within the
setup (the MSMs are installed on your dev machine when you install/
update Visual Studio 2005).

On the other hand, if you absolutely want to be able to distribute
your app by simple copy, then you need either :
- to redistribute vcredist.exe and have the user launch it.
- to copy the content of <Visual Studio Install Path>\VC\redist
\x86\Microsoft.VC80.CRT alongside your binary (in the same directory).
- to link statically against the CRT.

2nd and 3rd options are easier, but they are less recommended because
they do not allow the CRT to be serviced by MS in case of a security
breach.

Arnaud
MVP - VC

 

[Andreas Schmitt]

Almost always. This is the recommended setting for several reasons
(eg, disk space, possibility fot the DLL to be "serviced" by Microsoft
in the case of a security patch, etc....)

Why not?

Anyway, it all depends on how you redistribute your soft.
If you have a setup for your app, you can integrate the CRT within the
setup (the MSMs are installed on your dev machine when you install/
update Visual Studio 2005).

On the other hand, if you absolutely want to be able to distribute
your app by simple copy, then you need either :
- to redistribute vcredist.exe and have the user launch it.
- to copy the content of <Visual Studio Install Path>\VC\redist
\x86\Microsoft.VC80.CRT alongside your binary (in the same directory).
- to link statically against the CRT.

2nd and 3rd options are easier, but they are less recommended because
they do not allow the CRT to be serviced by MS in case of a security
breach.

I see. Thanks for clearing that up. I was always wondering what this was
really for and when it was used.
And I never noticed before that those DLLs were distributed with several
games I own. I found a msvcr71.dll in my SIlent Hunter directory for
example.
But it seems that now I also have to copy not only the dlls but also the
..manifest file?
So to get such an application to run I need to copy

Microsoft.VC80.CRT.manifest
msvcm80.dll
msvcp80.dll
msvcr80.dll

into the application directory. Is that correct?

 

[Nathan Mates]

What is that good for anyway? No user of the compiled programm will have
the runtime-DLL if he doesn't have Visual2005?
When is that compiler setting useful? Just for using it for testing?
I mean I can't always distribute the entire vcredist together with my
programs just so people can run them.

If you're just using C/C++, you can avoid all this nonsense by
turning off 'Manifest' files. (Frankly, I feel that manifests are a
half-baked solution to a problem, as they cause MUCH more problems
than it's worth. Maybe in the next version of VS.NET, manifests won't
cause major headaches like this.). To turn off manifests, just do the
following:

- Right-click on your exe's project in the solution explorer, select
Properties.
- Under Configuration Properties -> Linker -> Manifest File, set
'Generate Manifest' to NO.
- Under Configuration Properties -> Manifest Tool -> Input and Output,
set 'Embed Manifest' to NO.

Eventually, I feel that manifests may well be useful. It's typical
for MS software to be decent around version 3.0. But, I feel that
manifests are something that slipped out the door well before v1.0.

Nathan Mates

 

[Andreas Schmitt]

If you're just using C/C++, you can avoid all this nonsense by
turning off 'Manifest' files. (Frankly, I feel that manifests are a
half-baked solution to a problem, as they cause MUCH more problems
than it's worth. Maybe in the next version of VS.NET, manifests won't
cause major headaches like this.). To turn off manifests, just do the
following:

- Right-click on your exe's project in the solution explorer, select
Properties.
- Under Configuration Properties -> Linker -> Manifest File, set
'Generate Manifest' to NO.
- Under Configuration Properties -> Manifest Tool -> Input and Output,
set 'Embed Manifest' to NO.

Eventually, I feel that manifests may well be useful. It's typical
for MS software to be decent around version 3.0. But, I feel that
manifests are something that slipped out the door well before v1.0.

What does the binary's manifest have to do with runtime-library dependency?

 

[Nathan Mates]

If you're just using C/C++, you can avoid all this nonsense by
turning off 'Manifest' files. [...]
Eventually, I feel that manifests may well be useful. It's typical
for MS software to be decent around version 3.0. But, I feel that
manifests are something that slipped out the door well before v1.0.

What does the binary's manifest have to do with runtime-library dependency?

The manifest tells the OS (well, XP and up, Win2000 and before
ignore it, proving once again that Win2000 is one of the best things
to ever come out of MS) exactly what runtime-libs it needs. If there's
no manifest, it falls back on the usual "find a DLL by name" that
everyone knows how to work since Windows 3.x. I would consider
manifests *FAR* less broken if they'd fall back on the "find a DLL by
name" behavior if the precise version isn't there. Basically, if
things don't *work*, out of the box, for most people, then they're not
ready yet for public use.

Nathan Mates

 

[Andreas Schmitt]

The manifest tells the OS (well, XP and up, Win2000 and before
ignore it, proving once again that Win2000 is one of the best things
to ever come out of MS) exactly what runtime-libs it needs. If there's
no manifest, it falls back on the usual "find a DLL by name" that
everyone knows how to work since Windows 3.x.

That doesn't change anything about the fact that the binary will still
need the DLLs...

 

[Arnaud Debaene]

I see. Thanks for clearing that up. I was always wondering what this was
really for and when it was used.
And I never noticed before that those DLLs were distributed with several
games I own. I found a msvcr71.dll in my SIlent Hunter directory for
example.

Yeap. It means that Silent Hunter is compiled with Visual 2003.

But it seems that now I also have to copy not only the dlls but also the
.manifest file?

Yes, that's new with Visual 2005 : The CRT are signed and use the
side-by-side feaure of recent OSes (Windows XP and up). See
http://msdn2.microsoft.com/en-us/library/ms235624(VS.80).aspx.

For a complete overview of the deployement of Visual C++ applications, see
http://msdn2.microsoft.com/en-us/library/zebw5zk9(VS.80).aspx

So to get such an application to run I need to copy

Microsoft.VC80.CRT.manifest
msvcm80.dll
msvcp80.dll
msvcr80.dll

into the application directory. Is that correct?

Yes, this is one option.

The best solution on the other hand is to have the DLLs installed in the SxS
directory (side-by-side DLL cache). This can be done :
- by running vcredist.exe
- through the Microsoft_VC80_CRT MSM that is in C:\Program Files\Common
Files\Merge Modules on your developpement machine. This last option requires
that the MSM is integrated in an MSI setup (either buid a "Setup" project in
Visual 2005, either se a 3rd party yool such as InstallShield).

Arnaud
MVP - VC