How to select against which version of the Visual C++ libraries the application is compiled?

I'm using Visual Studio 2008 for C++. When compiling, Visual Studio compiles against the header files of the VC 9.0 libraries. However, there are different versions of this library available:

• v9.0.21022.8 (= RTM)
• v9.0.30729.17 (= SP1)
• v9.0.30729.4148 (= SP1 with security update)

I'd like to know whether it is possible to tell Visual Studio which version it should compile against.

The reason I think this is important is because the application's installer needs to make sure that the correct version of the Microsoft Visual C++ 2008 Redistributable Package is installed. To me it feels like I don't have any control over this dependency, as apparently some Windows Update (not a Visual Studio update) can change this dependency. I'd like to keep using the same version to avoid the overhead of making the installer upgrading the Redistributable Package.

Note that this situation is different from my earlier q开发者_StackOverflowuestion, as that one was about link time. Neither am I looking for a way to control the version that is put in the embedded manifest file, as that is explained here.

The manifest that's included with your binaries is automatically generated by the VS build system. Important headers that determine the version dependency that's emitted into the manifest are vc\include\crtassem.h and crtdefs.h. The former declares the CRT version. Note that it already has support for the RTM version vs the "latest" version with the _BIND_TO_CURRENT_CRT_VERSION macro. The latter contains #pragma comment directives to embed the /manifestdependency linker option into the .obj file, which in turn makes the linker auto-generate the manifest.

You don't have to do it this way, you can simply turn off the linker options that generate the manifest and write your own. That gives you complete control over the CRT version that your app binds to. Whether you are ahead with this is a bit questionable. You would probably still be shipping the old version of the CRT that got updated in July of last year, it contained a critical security bug. Customers tend to be a bit unhappy about getting software installed on their machine that has well documented and solved security flaws.

The next thing you'd have to do is take control of the deployment of the DLLs. You'll have to deploy the DLLs into the WinSxS side-by-side cache yourself.

That will work, if you figure out how, but it isn't likely to survive for very long. Windows Update, if enabled, may discover that the machine is using an unpatched version of the DLLs and will update it. And deploy a publisher policy to redirect load requests. It is likely that your machine has such a policy file in place if you see your manifested version request resulting in the load of another version. The somewhat unescapable conclusion is that this is MSFT's DLL and they'll do with it what they think is necessary. Look at applocal deployment to avoid this.

It's this just a question of which directory your configuration is set to build against. As long as you have all the versions of headers on your machine and the libraries they link against I don't see why this can't be a new configuration for each version.

If the issue is things like SP1, there's not much you can do. Microsoft considers the runtime, in effect, a component of the operating system. It therefore gets updates and patches the same as any OS component.

There shouldn't be a problem with this, normally - the patches are bugfixes and security updates after all. In principle, each change should make your apps more stable. Not quite always true, but in any case there isn't much you can do about it.

There are options to change the runtime, but they are related to thread-safety and similar issues. There's a few relevant places in the project properties. In particular, in the C/C++/Code Generation tab you can select which run-time library to use.

If you are seriously worried, you can choose a statically linked non-DLL runtime. Users can still update their runtime DLL, but it won't improve the stability of your app when they do so.

You can do this using manifest resource files, which are written in XML.

We had to do this at a previous place of employment, unfortunately (or perhaps, more fortunately), I was not exposed to the in depth details of how it was done. This article looks about the closest to what we did that I could find on the subject.

Update0

Here is MSDN documentation regarding manifest file generation, and their use in isolating applications and building side by side assemblies.