TL;DR What is the sane way to automate invokation of VS 2017 vc_redist
when called in a chain of several installers?
The Visual C++ Redistributable Installer that MS provides for VS 15.x (VS 2017), namely both (14.15.26706 - VS 15.8.4)):
vc_redist.x86.exe
vc_redist.x64.exe
As part of our full product installation, I have to run several vcredist installers (also older versions) silently.
The problem now is that these installers will refuse to install if a reboot is pending (eg "HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Session Manager" - PendingFileRenameOperations
).
When calling these installers with vc_redist /q
, they will even trigger an immediate system reboot. This can be fixed by calling them with /q /norestart
, however:
When calling vc_redist /q /norestart
, and if a reboot is pending prior to this installer, it will return MSI exit code 3010
which indicates that a reboot is required.
However , AFAIK, this exit code also indicates, that this very setup requires a reboot to complete.
So, I cannot distinguish whether this installer was succesful and just requires a reboot at the very end of my installation sequence (I do install otehr stuff before and after) - or whether the installer actually refused to do anything and I would need to restart the system and start this installer again!
How can I call this vc_redist in a chain of different third party installers and
Not sure these helkp with the question, but for completeness sake.
"No action was taken because a reboot of the system is required."
This is an InnoSetup built installer for our "product suite", that will be used by customers, the installation order goes as follows:
As you can see from this sequence, rebooting after each vcredist woud be insane, and luckily it seems only the 2017 redist exhibits this unfortunate behaviour so far.
Of note : My trial runs on my dev machine all started with a reboot already pending at "step 0", and both the VC2005 and VC2010 installer run just fine (as verified through their GUI progress) even if a reboot is pending before hand. It's the VC2017 installers that refuse to do anything if a reboot is pending.
MSU Packages : After decompiling the vc_redist.x64.exe
- which is a WiX bundle - using this command:
dark.exe -x Extract vc_redist.x64.exe
I found that the bundle installs: Update for Universal C Runtime in Windows - KB2999226 . This component consists of Windows Update files ( *.msu
- used by Windows Update) and not just MSI files. I would suspect that they could be designed to require a reboot before allowing installation, but I don't have proof .
Suggestion : Run a check to make sure KB2999226 is installed. How to do this? I don't know a Win32 call, but the WiX guys will probably know. Here are some other suggestions .
The actual Windows Update Files are (over time these file names could change as new versions of this installer with the versionless file name - vc_redist.x64.exe
- are released):
Windows6.0-KB2999226-x64.msu
Windows6.1-KB2999226-x64.msu
Windows8.1-KB2999226-x64.msu
Windows8-RT-KB2999226-x64.msu
In other words for Vista, Windows 7, Windows 8 et al. Various Server OS's as well. Windows 10 has this component built-in.
Corporate Deployment : In a corporate environment I would deploy these
*.msu
files via the distribution mechanism available - whatever it might be - for example SCCM - before installing thevc_redist.x64.exe
package.This should yield better control of the distribution process as you get error messages straight from the MSUs themselves.
Frankly these are core-SOE components in my opinion. I don't know why Microsoft keep these runtimes out of the main OS installation. They are crucial for most software.
A description of the decompilation approach using the WiX toolkit's dark.exe
binary can be found here: How can I compare the content of two (or more) MSI files?
Strictly speaking, error 3010 is a success result. It means that the install has completed but requires a reboot. I'm not aware of anything to indicate that it means the install didn't start at all. The typical "won't install if reboot pending" is a result of using a launch condition based on the MsiSystemRebootPending property. Failures due to this launch condition do not return return a 3010 result - they usually return a 1602 error as a kind of "user cancel" error.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.