Visual C++ Redistributables without using VCRedist_x86.exe

dllvisual c++winsxs

I'm developing in an environment that is severely constrained, but the developers also have tight control over.

VCRedist_x86.exe – A 4Mb redistributable – is no fun (four hours to transfer). I'd really prefer to just redistribute MFC90.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll – that's more like 2Mb. However, Redistributing Visual C++ Files says:

It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++ applications without a manifest binding the application to these libraries. For more information, see Choosing a Deployment Method.

My original plan of copying the DLLs into the program's working directory doesn't seem to
work in this brave new world of manifests.

My next guess is to bodge up the registry entries required to populate the files into the WinSxS directory and populate it myself (rather than using the 4 meg program).

[edit] The software is frequently updated, so DLLs are strongly preferred to static linking. [/edit]

How can I sucessfully distribute the necessary files but keep the overhead down?

Best Answer

[I'm the current SxS maintainer at Microsoft]

I would strongly suggest against removing the publicKeyToken attribute from manifests. Private deployment of the dlls will work just fine with this attribute left intact. However, removing it will prevent your app from benefiting from security updates should there be a newer version of the CRT installed centrally on the target machine, as the dependencies will no longer match up.

So, to summarize: it's safe to embed your manifest, with the default. Copy the CRT manifest + DLL files directly into your executable's directory, with no edits. That's it. Compatible Win2k+.

Related Solutions

C++ – msvcr90.dll dependency in VS 2005 C++ project

This looks like a "Side-by-Side Assemblies" issue to me.

From what I can tell, Microsoft in an attempt to stop the DLL Hell problems of past years has introduced a concept of "Side-by-Side Assemblies".

In a nut shell it means that your application needs to tell Windows which version of the CRT it was designed to work with. When the application is installed Windows will make sure you application gets its own private copy of these DLL files.

To make it all work you need to embed the application's DLL dependencies into the applications Manifest file and attaching it to the project using the Manifest Tool, Input and Output section of the application project settings.

As an example here is the manifest I use for the Zeus for Windows IDE:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
      name="Xidicone.Windows.Zeus for Windows"
      version="3.9.6.69"
      processorArchitecture="X86"
      type="win32" />

  <description>Zeus for Windows</description>

  <dependency>
    <dependentAssembly>
      <assemblyIdentity
            type="win32"
            name="Microsoft.VC80.CRT"
            version="8.0.50608.0"
            processorArchitecture="x86"
            publicKeyToken="1fc8b3b9a1e18e3b" />
    </dependentAssembly>
  </dependency>

  <dependency>
    <dependentAssembly>
      <assemblyIdentity
          type="win32"
          name="Microsoft.Windows.Common-Controls"
          version="6.0.0.0"
          processorArchitecture="X86"
          publicKeyToken="6595b64144ccf1df"
          language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

Finally, if you plan to make an installer you will need to add the same versions of these DLL files to the application installer or alternatively have your installer run the Microsoft CRT redistributable installer.

FWIW I only found out about this when a user reported that Zeus no longer ran on Windows XP because of a missing MSVCRT runtime DLL file, yet Zeus had been working fine for over 10 years without ever once having to ship with a MSVCRT runtime DLL file.

Php – C++ EXE made in VC++ 2008 runs on Windows 7 but not XP

Try using Dependency Walker on XP to see if you can find any missing dependencies.

Also check the Event Viewer. And make sure you're building the application in Release mode.

Dependency Walker showing a dependency on DWMAPI.DLL is often an incorrect reporting, which can result from having a dependency on mshtml.dll on an XP box with IE7. Did you check the Event Viewer?

The build errors that you posted suggest that you're linking to libraries that are NOT built with /MT flag. Make sure you rebuild everything in your solution; your 2 DLLs, the .EXE and any static libraries with that same flag, assuming you own the DLLs as well.

Related Topic