If I compile code using the Visual C++ 2008 compiler, do I need to have the matching service pack of the runtime library for that compiled code to run correctly?
Suppose I compile code with Visual C++ 2008 compiler (any edition). Will this work with the SP1 VC++ 2008 runtime library?
Conversely, if I compile code with a Visual C++ 2008 SP1 compiler (any edition). Will this work with the RTM VC++ 2008 runtime library?
Probably.
This is part of the reason that MS introduced the idea of Side by Side assemblies. Your code specifies its preference, and the OS gets to offer the assemblies it currently has available. If there is a match, your code runs. If not, no luck.
You do have to follow all the usual guidelines for application manifests and probably make the installation of the runtime library available in your installation package in any case.
Related
I've been looking around and I'm not sure I see a clear answer to this so I'm sorry if this has been asked before; my "Google-Fu" is failing me.
We are developing software against .NET Framework but historically we have had to include a number of 3rd party components. Also, historically, these tended to come with various dependencies on Microsoft Visual Studio C++ runtime versions. This has led to us distributing as part of our initial installation process:
Microsoft Visual Studio C++ 2005 Redistributable (SP1) - build 8.0.61001
Microsoft Visual Studio C++ 2008 Redistributable - build 9.0.30729.6161
Microsoft Visual Studio C++ 2010 Redistributable - build 10.0.40129
Microsoft Visual Studio C++ 2012 Redistributable - build 11.0.61030
But as the years have gone on many of the 3rd party components we used have been replaced with newer and better ones, and we include them to our Projects through NuGet. And I'm finding that as I install our software on systems without installing the above first most of our applications are working perfectly normally without errors. So I'm starting to think a lot of the above are no longer necessary.
Ideally I would just like to chuck 'em all. Relieve the pressure on our support staff to install all these components as well as our software when setting up machines for first use.
It would be great if I could just tell them "look, just install VC++ redistributable version xyz and anything that needs one of the above four builds will work just fine"
I see many resources online claiming that, for example, the 2017 redistributable replaces the 2015 one, and so on but does that backward compatibility go all the way back to the 2005 SP1 version?
My second question is a bit more generic and I don't really expect many answers to that one but.
are there any well known 3rd party developer tools that you know are using one of the four Redistributables mentioned in my list above? For example, we use Crystal Reports runtime 13.0.17 - oh how I wish we could dump that and move on .... And one of our support staff has already identified that that sometimes won't install if the 2005 SP1 runtime is missing. Trying to find out such info from online resources is like looking for a needle in a haystack....
the 2017 redistributable replaces the 2015 one, and so on
Yes, for certain values of "and so on" ;-) The 2015, 2017 and 2019 redistributables are binary compatible with the most recent release thereof. Quoting Microsoft from C++ binary compatibility between Visual Studio 2015, 2017, and 2019:
The runtime libraries and apps compiled by any of these versions of the compiler [2015, 2017, 2019] are binary-compatible. It's reflected in the C++ toolset major number, which is 14 for all three versions. [...] Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017 or 2019. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
does that backward compatibility go all the way back to the 2005 SP1 version?
No. Quoting again from the same page:
The Microsoft C++ (MSVC) compiler toolsets in Visual Studio 2013 and earlier don't guarantee binary compatibility across versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions. The ABIs, object formats, and runtime libraries are incompatible.
To make things even worse, VS 2005 and 2008 did not have one single set of redistributables, but instead several different versions that were installed in SxS (side by side) mode. From Side-by-side assembly:
In side-by-side, Windows stores multiple versions of a DLL in the WinSxS subdirectory of the Windows directory, and loads them on demand. This reduces dependency problems for applications that include a side-by-side manifest. [...] Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries.
are there any well known 3rd party developer tools that you know are using one of the four Redistributables mentioned in my list above?
This is way too wide for any useful answer. You'll have to (a) identify which tools/components/etc you are using, and (b) which are the dependencies of each, including (though not limited to) the C/C++ runtimes.
So here is my situation: We have some applications built using VC++ 2010, but others are now built with VC++ 2013.
In the past, when setting up a client machine, only VC++ 2010 Redistributable was installed, but with the development of some of these applications now in VC++ 2013 we need to install the VC++ 2013 Redistributable.
I know that the Redistributable packages are installed side by side and that applications developed in VC++ 2010 will go to their appropriate file set if it exists on the machine.
But can a VC++ 2010 project run reliably with just the VC++ 2013 redistributable installed?
This question occurred to be when I saw that Microsoft named the VC++ 2010 and 2013 redistributable install files the same. For example, vcredist_x86.exe.
Thanks for your time!
No, your VS2010 built app will need msvcr100.dll (etcetera), the VS2013 installer will deploy msvcr120.dll
Doing anything to force VS2010 to use the VS2013 runtime library is very unlikely to turn out well. The new C++11 language standard has caused lots of upheaval in the runtime libraries. The good kind of upheaval, but not exactly very compatible with old compilers.
You must therefore install the VS2010 runtime libraries as well.
I am trying to execute a C# program on Windows XP (SP3) which references a managed C++ DLL compiled with VS2012. When compiling the C++ DLL, I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and set minimum required version to 5.01 in linker options, and I already installed Visual C++ 2012 Redistributable Package on the Windows XP machine. But it didn't work.
Any idea on this?
As you mentioned Platform Toolset and v110_xp option, I'd risk assuming the question is about an unmanaged C++ DLL. Anyway, try compiling your DLL with the original VS 2012 distribution (no updates) and see if it works. I dealt with a similar issue caused by VS 2012 Update 2, which is described here. You could test each of your dependency DLLs (including VC++ redistributables) with DependencyWalker, to check if any of them is using a Win32 API not implemented by Windows XP. Just do it under XP itself.
When I moved my C++/CLI application to another Win 7 machine, it said that MSVCR100.dll is missing although that was a release version of the application. What is the file MSVCR100.dll ? Is it possible to combine it with my application,if how? Any other suggestions?
MSVCR100.dll is part of the VC++ 2010 runtime; it's a dedicated downloadable from Microsoft and required for most programs compiled with VC++ 2010.
Due to the newish side-by-side (SxS) deployment of DLLs, it's not so simple to extract the handful of files and deploy them manually.
http://www.microsoft.com/download/en/details.aspx?id=8328
Apparently, SxS is so 2008. Visual C++ 2010 just uses all different filenames for everything.
You need to ensure that the .NET Framework and the Microsoft Visual C++ 2010 Redistributable
are both installed on the new machine, either that, or package the necessary dlls with your deployment.
I have an InstallShield installation that uses custom actions that depends on the Visual C++ Runtime 8.0 sp1. In the past, I was able to install the runtime using the merge module provided by Microsoft with Visual Studio. Based on the way the Visual C++ Runtime 8.0 sp1 side-by-side installation works on Vista, the runtime cannot be used until the commit sequence of the installation.
This means that I must either move the executing of my custom actions to the commit sequence (undesirable, since the installation can't be rolled back during this sequence if something goes wrong) or install the Visual C++ Runtime before my installation using an InstallShield prerequisite.
I would prefer to install the Visual C++ Runtime as a prerequisite, but a prerequisite for this is not provided by InstallShield, so I had to write my own. I was able to figure out how to configure the prerequisite to install the runtime, but I don't know how to determine if it is already installed. Is there a registry key or file version I can check to determine this?
I found blog posts that describes detect the Visual C++ Runtime 8.0 and Visual C++ Runtime 8.1. Basically, you can use the MSI Automation Interface to look for the product codes for each of the runtimes.
You could also look for the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] where [ProductCode] is the product code for the runtime you're trying to detect (eg. {7299052b-02a4-4627-81f2-1818da5d550d} is the product code for the x86 version of the 8.0 sp1 runtime).
These methods only work to detect if the runtime redistributable package is installed; it is possible that the runtime is installed even if these methods don't indicate so (eg. if it was installed as a merge module instead of using the redistributable), but it shouldn't hurt anything to install the redistributable package in this case.