Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, November 21, 2017 7:25 PM
My app uses VC++ 2015 x64 redist, for a mixed mode C++ assembly. Some of my users ran into this problem:
During installation of the VC++ 2015 Redist prerequisite the following error is presented:
Setup Failed ... 0x80070666 Another version of this product is already installed.
I troubleshooted (troubleshot?) a bit, came up with this minimal path to reproduce
- Install Win10 x64 on a VM, update fully.
- Install VC++ 2017 x64 Redist 14.11.25325.0 (latest version)
- Install VC++ 2015 x64 Redist 14.0.24215.1 (latest version). Setup fails.
This is a defect, assuming that redist from different VC++ editions can coexist. Is that a valid assumption? It seems to have worked in the past.
Any thoughts?
All replies (13)
Tuesday, November 21, 2017 11:26 PM | 1 vote
See /en-us/cpp/porting/binary-compat-2015-2017
Wednesday, November 22, 2017 9:44 PM
Thanks for the link, helped me understand what is going on.
Okay. So... Some PM at MS thought they had a good idea and good intentions here. Didn't go so well, did it?
The consequence of this is at an app installer using VC++ 2017 Redist as prerequisite will BREAK a completely different installer from another app vendor, that uses VC++ 2015 Redist as prerequisite.
This is completely, utterly brain dead. **The responsible PM should be taken out on the street and slapped with a wet trout. **
Thursday, November 23, 2017 11:48 AM
Actually, an installer could still break a completely different installer anyway.
You see, if you try to install a version of the VC redist which is the same major version but an older update, then more often than not the redistributable installer would just exit with a hard error. I have had plenty of things fail to install because they didn't check if the redistributable was installed. Visual Studio would even do it to itself if you installed the most up to date version of the redistributable and then install Visual Studio. It would complain about the failure to install the redistributable.
This may actually be classed as a failure in your installer to not verify if a compatible runtime was already installed.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Thursday, November 23, 2017 6:44 PM
This may actually be classed as a failure in your installer to not verify if a compatible runtime was already installed.
Sure.
But the point here is it's not my installer, it's Microsoft's ClickOnce installer as generated by the Publish function in VS. I didn't write a single line of code for the ClickOnce installer, just used the VS UI to specify prerequisites.
Expected behavior would be for either the C++ redist installer to accept that a newer version is installed and exit gracefully (instead of with an error code which makes the ClickOnce installer terminate), or (if possible) for the ClickOnce installer to ignore the failure code from the C++ redist installer and continue to install the app.
None of those are happening. I'm pretty sure I'm using ClickOnce as it was intended to be used. This is a product design flaw, either in ClickOnce or C++ redist installer. My wet trout comment still stands.
Now, I'm suspecting that my fix will be to customize the bootstrapper product.xml, package.xml for C++ redist to check for already installed version.
Friday, November 24, 2017 2:44 AM
You simply can avoid all these problems by using /MT link option in all of your modules. Then you don't need the redistributales in most cases. And other redist packages will never interfere.
Actually, not in this case. I have a mixed-mode C++ assembly, which cannot be statically linked to the runtime. This is well documented with the /clr and /MT switches - and the compiler will flog you if you try.
Friday, November 24, 2017 3:56 AM
VS2015 has not received an update in over a year despite known issues with its versions of the CRT and UCRT, many of which have been discussed in these forums. IMHO, the changed approach to binary compatibility implemented with VS2017 seems to be a way to enable MS to avoid maintenance of the VS2015 runtime.
To me it seems that MS views VS2015 as a dead product,
And please don't tell me that the solution is to update from VS2015 to VS2017. I'd prefer an updated VC++ 2015 redistributable that contains bug fixes. And since the UCRT is updated with Windows how about also giving developers a debug version that is in sync with the updated release versions? Gosh, that doesn't seem like much to ask for.
Friday, November 24, 2017 5:30 AM
Proposed solution:
I didn't want to copy the DLLs - Microsoft recommends against doing that, and for a good reason.
Instead, I attempted to modify the bootstrapper package for vcredist, specifically the product.xml file. In the InstallChecks section the following line was added, to extract the build number of the version of currently installed C++ 14 redist:
<RegistryCheck Property="VCRedistBuild" Key="HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64" Value="Bld" />
The assumption here is that for C++ 14, the build number will always increase for a new release Latest seems to be 25325 at this time, the bootstrapper package I based this on from VS2017 is 25008. Further down in the InstallConditions section the following line is added, to use the build number to determine if it's really necessary to run the installer:
<BypassIf Property="VCRedistBuild" Compare="ValueGreaterThanOrEqualTo" Value="25008"/>
Repeat for x86.
An alternative would be to check the version string value at the same registry key.
The effect is as predicted, the setup.exe generated by publish now does neither download nor execute C++ 14 redist if 25008 or later build is already installed.
I'm sure this fix can be improved - feel free to suggest.
Bottom line: the problem exists for VS2017 as well. The bootstrapper packages are not compatible with the ClickOnce installer.
Wednesday, November 29, 2017 9:30 AM | 1 vote
Hi LarsV,
Thank you for sharing the proposed solition.
You could also see Visual C++ 2015 Redistributable Setup Failed 0x80070666 (x64 & x86) :
To get around it:
1. downloaded the latest Visual C++ 2015 Redistributable package and ran the following from the command line:
vc_redist.x64.exe /uninstall
A popup will show with the option to repair the installation. The repair succeeded and I was able to continue on past the point I was blocked by this.
Meanwhile, please also check and install Windows update before do the Visual C++ Redistributables.
Best Regards,
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].
Wednesday, November 29, 2017 10:03 PM
Hi LarsV,
Thank you for sharing the proposed solition.
You could also see Visual C++ 2015 Redistributable Setup Failed 0x80070666 (x64 & x86) :
To get around it:
1. downloaded the latest Visual C++ 2015 Redistributable package and ran the following from the command line:
vc_redist.x64.exe /uninstall
A popup will show with the option to repair the installation. The repair succeeded and I was able to continue on past the point I was blocked by this.
Meanwhile, please also check and install Windows update before do the Visual C++ Redistributables.
Best Regards,
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].
This is actually not a good answer - it would seem that you did not read the original question. I am posting the following for posterity, to help readers avoid the confusion your answer can create.
My original posting was related to building an installer that performs the c++ redist install.
Your answer was for an end user trying to interactively install only the c++ redist, which is quite a different scenario.
-Lars
Wednesday, May 9, 2018 8:18 AM
I agree with LarsV's solution. One thing to note, though, is that installing VC++ 2017 on top of VC++ 2015 seems to remove the registry entry on the location stated by LarsV. Has anyone made any solution for cases like this? I am also wondering though why upgrade will remove this entry. Is it by design or a bug?
Wednesday, May 16, 2018 1:55 AM
I too noticed the same thing EarlMR has seen, VC++ 2017 on top of VC++ 2015 removes the relevant registry key.
This is almost certainly a bug, as repairing VC++ 2017 after getting into this state corrects the issue and adds the registry key back. I'm unsure where the correct place is to post this as a bug but I'll happily do so if somebody could point me in that direction.
Thursday, September 27, 2018 3:03 PM
I faced the same issue and was searching that both VC++ 2015 and VC++ 2017 can co-exist on same machine or not.
So after reading the threads, resolved the issue and it can co-exist.
I installed VC++ 2015 (x86) and VC++ 2017 (x64) then my application worked successfully.
But if you tried to install both x86 or x64 then will face the issues.
Friday, February 7, 2020 7:54 PM
WOW! Thank you. Our Wrapper already went through and checked for pre reqs and tried to install. Of course it failed on 2015 because 2017 was installed. 2017 was fine with app so no big deal if the msi would just finish install. I found a manifest.xml and found a reference to the 2015 version, as soon as I removed it, msi installs fine and I'm good whether my system had 2017 or nothing and the wrapper installs 2015. Thanks so much!