views:

286

answers:

2

I'm developing a 64-bit in-proc VC++ ATL COM server that basically just redirects all calls to an out-proc COM server. So my COM server basically does nothing.

Initially it used the C++ runtime in a DLL (/MD compiler switch). I've noticed that when I deploy it on a clean 64-bit Win2k3 regsvr32 fails with an error: LoadLibrary({fileName}) failed – This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Google helps - the problem is that VC++9 runtime is not installed. The problem persists even when msvcr90.dll is in the same directory as my COM server. That as I guess is because of how search for dependent libraries works - it doen't look into the same directory and I need the msvcr90.dll in Windows\System32 or the like. Since this is a complication to my deployment I switched to using the statically linked C++ runtime (/MT compiler switch). Now it deploys fine. The size of the .dll file is 110k only (was 45k) so it doesn't bother me.

Now I've heard a lot about how bad it is to mix different versions of C++ runtime in one process - CRT state can be broken, hell can break loose and so on. Do I have to think of this and expect problems from changing /MD to /MT especially since I don't know what version the COM server consumers are using?

+1  A: 

It should not be a problem.

The static linking basically takes the required functions from a library and puts them into the code of your DLL (thus the increase in size). It should then work just the same as if you wrote those functions in your code yourself.

HS
And what about possible difference in the binary layout of data structures from the runtimes?
Georg Fritzsche
+2  A: 

As far as I know the Static runtime is deprecated in VS since VS2005.

The problem is that the Visual C Runtime is a side by side dll. That is it must be loaded from the c:\windows\winsxs directory. This is why placing it in the same directory is no longer works.

The correct solution is to install the correct CRT redistributable on the client system.

See http://msdn.microsoft.com/en-us/library/ms235316.aspx for more information

This might be the correct redistributable: http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en

Installing the correct one will place the runtime dlls in the winsxs directory.

iain
Can you provide a reference for the deprecation of the statically linked runtime library in VS2005?
Charles Bailey
I cannot find a reference deprecating the static library. My first assertion is probably wrong. I read all around me when I had problems with 3rd party dlls and the VS2005 runtime, I probably merged the static runtime library and the (now gone single threaded runtime library). The static runtime library is fine, but can cause problems if you split your app across different dlls.
iain
OK, I know that they don't encourage it due to the possibility of having old library bugs that don't get fixed by system updates but sometimes (distributing a single .exe) it's just simpler to not have to do the whole installed, admin privilege's, side-by-side assemblies thing. A library fix is just distributed via a re-built .exe.
Charles Bailey