Repository navigation
Incorrect Windows Installer Check for VC++ Redistributable Dependency #4665
Description
The root cause of this issue is that the check is specific to a registry key that gets created when the VC++ redistributable package is directly installed via the suggested link. It overlooks scenarios where those files are installed via Windows Update.
A secondary issue is that the test should be tagged to only execute on Windows systems.
Steps to reproduce
Build the MSI for a Windows SKU using commit 54e892a and run it on a system that does not have Visual Studio 2015 or the VC++ redistributable package installed via MSI. The dependency is required, but it can be installed via Windows Update.
Expected behavior
The MSI installs without error.
Actual behavior
The failure message is, "PowerShell requires the Visual Studio C++ 2015 x64 redistributables to be installed..." This occurs on a fully patched system that has the dependency installed via Windows Update.
Environment data
Beta.5 + commit 54e892a
Activity
iSazonov commentedon Aug 25, 2017
Christoph Bergmeister (@bergmeister) Could you please look the Issue?
De4pin commentedon Aug 25, 2017
asking on msdn.microsoft.com
daxian-dbw commentedon Aug 29, 2017
May be related to #4315
bergmeister commentedon Sep 2, 2017
Mike Richmond (@mirichmo) @w1748587889 Any news why the VC++ installation via Windows Update is missing the registry entry?
In general the problem is that each minor update of the VC15++ runtime gets a new registry Guid, so it is impractical to assert against a specific version, therefore one needs to look if 'some' version oft the VC15++ distributables is installed. Therefore it might be good as well to check on your side if any minor version (or at least the first released one) would work?
Alternatives for a generic check that VC++15 is installed:
Installedvalue is1forHKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\VC\Runtimes\x86(64bit) andHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\11.0\VC\Runtimes\x86(32 bit)Could you please check if this would pass on a system with the distributables installed via Windows Update?
SteveL-MSFT commentedon Sep 2, 2017
A file based check may be simplest and sufficient. If the registry entries aren't documented, you can't rely on them. I think a custom action should be last resort.
iSazonov commentedon Sep 2, 2017
It seem we can use MsiQueryProductState API https://blogs.msdn.microsoft.com/astebner/2010/05/05/mailbag-how-to-detect-the-presence-of-the-visual-c-2010-redistributable-package/
bergmeister commentedon Sep 2, 2017
Ilya (@iSazonov) Your approach would still require a custom action (i.e. embedd our own custom .net dll with the code to call it) in order to call it from within WiX as far as I can see.
Steve Lee (@SteveL-MSFT) I'll look into the file based approach then but it will only be a basic check because the VC++ team decided to make it super complex and deprecate merge modules since 2015, see their own blog post here for details. Out of curiosity: Why are those distributables required (the reason should be documented as well imho)?
iSazonov commentedon Sep 2, 2017
We can still check registry https://stackoverflow.com/questions/851677/how-to-check-for-installed-package-in-wix-3-0
SteveL-MSFT commentedon Sep 2, 2017
Christoph Bergmeister (@bergmeister) we should probably follow the VC++ team's advice then. The redist is required since we compile with VC++
iSazonov commentedon Sep 3, 2017
I see in the blog post:
Should we package this with PowerShell Core for all Windows (excluding Windows 10?)?
bergmeister commentedon Sep 3, 2017
Ilya (@iSazonov) Because they deprecated merge modules for VC++2015 (see the comment woes in their blog post here), including the runtime has become super complicated. Yes, you could do it and you basically have the choice between having to include around 10 dlls (per bitness) that amount to around 20MB or 100 dlls (per bitness) that amount to 2MB. But I think Steve Lee (@SteveL-MSFT) just wanted a check as a minimum viable feature because those pre-requisites are already present in most cases due to Windows Update or other software that has already installed them.
SteveL-MSFT commentedon Sep 4, 2017
Christoph Bergmeister (@bergmeister) if we expect most systems to have these binaries via Windows Update, I think we're ok with the minimal check until we get additional customer feedback