CODEWITHSUNDEEP
c++visual-studiovisual-studio-2013
Scott Langham
Scott Langham

Reputation: 60411

Visual Studio C++ Redistributable Compatibility

We have products that are built with Visual Studio 2013 With No Update. I would like to update our build machine to Visual Studio 2013 Update 3.

We release patches and hot-fixes for our products that contain a subset of the product's binaries. I am concerned about what will happen if I update our build machines and we produce a patch using them. A patched installation of our product would contain a mix of dlls and exes that are built with different versions of compilers and which are built against different versions of the Visual Studio C++ Redistributables.

Would the 2013 Update 3 version of the redistributable need to be redistributed with a patch?

Are different update versions of the redistrubutables compatible, and is this scenario supported?

Upvotes: 2

Views: 1204

Answers (1)

Martin Ba
Martin Ba

Reputation: 38941

Soapbox

A patched installation of our product would contain a mix of dlls and exes that are built with different versions ...

And there you already have a problem: Our policy is to always patch everything together. Each set of (our) C++ binaries that is distributed is fully self-contained, we do not do partial updates of any set of C++ binaries - too much chance something might break, independently of VC runtime issues.

(Of course if you have modules that are "firewalled" behind a C DLL API, that's something different.)

As to the Question

The way I understand the Microsoft C(++) Runtime libraries from 2010 onwards, they all get installed into "System32" and are versioned per major version, so normally one Windows system only has one single set of VS2013 Redist installed and available for all applications that use default settings (i.e. no messing with manifests and WinSxS).

This means that all VS2013 redistributable libraries must be fully forwards and backwards ABI compatible, so it should generally not matter if the build server has a different "minor" redist version than the customer machine. As long as all modules use the DLL VCruntime versions, there can only be one loaded into any process at any time, so all modules see the same that should be compatible.

Still, I think you would be doing yourself a favor to include the (newest) VCRedist into your patches to rule out any potential bugs caused by old versions that would only manifest on the customer machine.

The way the VCRedist is shared, you (or anyone else) don't guarantee much about its minor version anyway, so you might as well make sure that the client machines at least run minimal the version you're using.

Upvotes: 1

Related Questions