Visual Studio 2005 security updates and CRT DLL ve

Question

Recent Visual Studio 2005 security updates may be causing problems for us.

We build and internally distribute SDKs written in C++. These SDKs are a collection of header files and static libraries only. After installing the security updates our SDKs now depend on the newer versions of the MSVC CRT DLLs. These SDKs are used downstream in projects which produce EXE files.

If one of these EXE files is built with a mix of SDKs (some from before the security updates, some from after), then the EXE file produced makes reference to two sets of MSVC runtime DLLs. E.g:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
            </assemblyIdentity>
        </dependentAssembly>
    </dependency>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
            </assemblyIdentity>
        </dependentAssembly>
    </dependency>
</assembly>

Does this mean that at runtime this EXE will be using both versions of the DLL? Does this mean we must distribute both versions of the MSVC Runtime DLLs with this EXE?

Is there a simple way to avoid this problem without forcing all SDKs to be built with the Visual Studio 2005 security patches in place? (This would be undesirable for some of the older and quite stable SDKs that we don't want to rebuild unnecessarily)

Is is possible to simply rewrite the manifest file on either the SDKs or the final EXE file so that only one version of the MSVC CRT DLLs are mentioned?

---

My understanding is that the relevant updates are as follows:

Security update for Microsoft Visual Studio 2005 Service Pack 1: KB971090

http://go.microsoft.com/fwlink/?LinkId=155934

Security update for Microsoft Visual Studio 2008 Service Pack 1: KB971092

http://go.microsoft.com/fwlink/?LinkID=155933

---

I have discovered two other questions which are similar:

VC++: KB971090 and selecting Visual C Runtime DLL dependencies

Does the latest Visual Studio 2005 Security Update cause C runtime library issues when hot fixing customer sites

Answer 1

1) Yes it means the runtime is using both versions - something you never want to happen. It should only ever reference a single version of the DLL(s)

2) There is a method that I've developed to force the version to be the SP1 version (without the security update). I've outlined it here

3) You could disable manifests entirely and do them by hand, but I don't recommend this, as it's a pain to maintain different manifests for your debug and release, and it's an error-prone way of dealing with the problem. It would be better to use the workaround I mentioned in (2) above.

Answer 2

As Ted says, at runtime your executable will be trying to use both versions of the DLL. This is probably because you haven't fully recompiled the entire project (or you are using external libraries that have been compiled to depend upon the .762 runtime).

The good news is that if both these libraries are installed on your client systems then the side-by-side redirection policy will mean that only the latest is loaded. By far the more detrimental side-effect you will notice is when only one is installed (probably .762) that the application will fail to start with the old "application is not configured correctly, reinstalling may fix this problem" error message.

Does this mean we must distribute both versions of the MSVC Runtime DLLs with this EXE?

The easiest solution for you would probably be to just ship the latest version of the visual c++ runtime redistributable which you can get from the following link.

http://download.microsoft.com/download/6/B/B/6BB661D6-A8AE-4819-B79F-236472F6070C/vcredist_x86.exe

It can be a bit of a pain because it asks the user to click "I agree" on a EULA page and requires admin priveledges but by general consensus it is the best option if you can get the user to install it.