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?
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.
Related
Is there a reason (I guess yes but I try to discover it) to install 2019 redistributable when deploying a C++ application built with vc142 since applications seems to work perfectly with the previous redistributable package (coming with vc141)? I have in mind that both are binary compatible, but more than that, dumpbin /exports of msvcp140.dll and vcruntime140.dll from 2017 and 2019 redistributable produce the same output; file size are identical too.
Did I miss something?
Apparently there is no gotcha, the libraries are comptible, see : https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019
The article states: "This reflects the fact that both the runtime libraries and the applications compiled with either version of the compiler are binary compatible."
Maybe there are performance related differences.
As vs 2019 supports later c++ standard than 2017, this leaves one to wonder how this is possible with the old runtime libraries. I guess the differences are all built into the main executable/dll and don't require any changes in the runtime dlls.
I've stumbled upon the issues with having the wrong MSVC run-time when linking or running apps written in C or C++. Because of that, I try to be exact on using the correct versions.
I see that the SDL (Simple DirectMedia Layer) library is pre-compiled with MSVCRT, which AFAIK is compiled with MSVC 4.2 to 6.0. Still, that pre-compiled library works fine with my apps compiled with the much later Visual Studio 2015 v14.
How come there are no issue with linking old MSVCRT with MSVCR140, e.g. SDL?
Is there a way to make a library be compatible with any greater Visual Studio compiler?
How is this solved with using other compilers, e.g. GCC or even on Linux or Mac?
Because the, let's call them vintage, runtimes are used so widely they're always there. But more recent runtimes, used by a newer Visual C++, might not be automatically present. Also, Visual C++ standardised on a single runtime library for some time, ensuring backwards compatibility with existing applications. Somewhere around Visual Studio 2012 this was dropped in favor of version specific runtimes.
You need to package your application into an installer that also installs the necessary runtime (or runtimes if you require more than one).
Linux applications are packaged (RPM, YUM etc.) with dependencies on runtime components. Basicaly the same as a Windows installer. Dependencies are either part of the package or satified by the distro. Linux shared libraries are versioned, multiple versions can be installed side-by-side and an applications can link against specific versions if required.
So i'm fairly new to VS and coding and I've recently made a small snake game in a C++ console application project, which works fine but i would like to get it to work on another PC without VS. The closest i have found to answering my question were these other StackOverflow questions here and here. i have installed the vs installer projects extension to try make it a setup project and include the required dependencies but i cant work out how to do this. Does anyone have any info to guide me through my last step of this problem or am i completely on the wrong track?
If the application uses dynamic runtime (which is the default), it uses the VS DLL files. To provide them, the Visual Studio Runtime Redistributable for that particular VS version needs to be installed on the target machine (as mentioned in your second link).
So that means you need to setup the installer that way. I didn't use it, but there might be some options that the resulting setup can either contain or download and install the VS redistributable automatically.
See also here: How to install redistributable with visual studio setup? (but it is for VS 2013, there might be some changes in 2015)
Well, you don't tell us what kind of project your C++ console app is...
Using only C++, your app can be built with different versions of the CRT, like for instance:
V120 (VS-2013)
V120_XP (VS-2013 w/ XP support)
V140 (VS-2015)
V140_XP (VS-2015 w/ XP support)
Even on VS 2015, you can choose the version of the CRT you want, and use an older version, if needed.
Anyway, the target computer will need the DLLs for the correct CRT version.
Microsoft provides them. You can either ship them with your product, if you have a custom installer, or use the installer provided by Microsoft.
MSDN - Determining Which DLLs to Redistribute
For instance, using V120:
msvcp120.dll
msvcr120.dll
Your project might also use .NET.
In such a case, you also need to install the correct version in the host machine.
I have a software with a couple of executables, that depends on both VC++ 2012 and VC++ 2010 (msvc110.dll, and msvc100.dll, something like that). I want to ship my application with the 2012 version redistributable, that is 7mb, and avoid using the 2010 redistributable so I reduce the size of the installer.
My question is, is the 2012 version of the redistributable backwards compatible with the 2010 version? Or should I embed both of them in the installer?
Note that the executables are already compiled, and I don't have the source code to compile them using the same version.
Unfortunately if you don't ship the runtime the module was compiled against,if it does not exist on the target system, your app will fail. How it fails depends on how you built your app (e.g. linked lib dll, versus OpenLibrary module).
As for compatibility, our team had similar questions so I wrote experimental test code using VS2005, VS2010 and VS2012 modules where one module would create a std::vector (etc) and pass it to another module for use. It failed badly. Extremely easy to reproduce this experiment.
You will need to ship both.
You have several exe, just ship them all or mark it down as a requirement for your app.
DLLs are not big.
If you can rebuild apps to align them so they use the same crt, that would be better.
How to remove msvc dlls (example: msvcr100.dll) dependency to run qt appliation?
I've developed a qt application which runs just fine in dveloper machine but unable to run on any other machine gives error message "program can't start because MSVCR100.dll is missing from your computer". I can solve this error by copying that file in the application folder but I dont want to copy, instead I want to link statically or some other way to remove that dependency.
Thanks in advance
The issue is that you are probably trying to run an application on a machine which has a different Visual Studio (MSVC) version installed than the version that was used for building your application itself.
Generally, the correct solution is to install the corresponding Visual Studio redistributable package on the target machine. It is not a "workaround" or "hack" because if you wish to use an application built with different runtime libraries, etc, then it is expected. Here you can read a bit more about it:
Redistributing Visual C++ Files
Yes, it is a bit unfortunate, and apparently MS has not managed to make it the most ideal, but after all, it is simple enough to circumvent. Note that the target machine would not only have issues with your application, but in general with any distributed in a similar fashion.
The other way to solve the issue is to build the application with the same environment that is installed on the target machine, but this can easily go haywire if you need to supply the application to several machines with versatile setup. Now, I would say this is the "hackish" approach.
You will need to grab the redistributable for this particular problem from here:
Microsoft Visual C++ 2010 Redistributable Package (x86)
Microsoft Visual C++ 2010 Redistributable Package (x64)
Even if you went down for statically hacking this around somehow, you would need to deal with nasty consequences when using your application with DLLs and static libraries, etc.
As far as I know, you can't link statically to Visual Studio Redistributable. Any application built with Visual Studio Compiler needs the corresponding msvcXXX.dll to run. Installers containing all dll for each specific version of MSVC are available here: http://search.microsoft.com/en-us/DownloadResults.aspx?q=redistributable
If you want avoid errors for your users when you distribute your application, you have some solution. A commonly used is to install the right redistributable package before installing your application on the user machine. Often used tools (NSIS, Inno Setup, etc.) have options to run other executable in the process. And each Microsoft redist package can be run silently (without any window display to user).
Note: This problem is absolutely not related to qt. It comes directly from the compiler you choose.