[...] Or better still, the installer would block installation if its dependency was not present.
_Originally posted by @danmosemsft in https://github.com/dotnet/core-setup/issues/8368#issuecomment-536702808_
Seems like it might be a reasonable incremental fix to make to reduce the confusion when installing the Windows Desktop Runtime. Currently I don't know how to implement this, not sure how difficult it would be.
Ideally it would display a detailed message with the requirements and a link back to the downloads site.
/cc @dleeapho @MichaelSimons
Added 3.0 milestone to consider for a servicing release.
In 3.1, we're planning to implement https://github.com/dotnet/core-setup/issues/8504. That bundles the .NET Core Runtime installer in the WindowsDesktop installer, making this mitigation unnecessary because there is no dependency.
Ideally the bundling improvement can also be ported to 3.0 as a servicing fix, but if not, we should still consider adding/expressing this dependency in the installer as a servicing fix for 3.0.
/cc @vatsan-madhavan
Other options consider adding the runtime to this bundle, or rely on the installer description on the web download site.
When I was originally looking at this, I was trying to see how to do it within the framework of the WiX Dependency extension, which seemed risky based on limitations I was seeing.
But it might not be bad to implement in the WindowsDesktop Bundle... @joeloff showed me how the ANCM bundle is doing some registry searching for whether IIS is installed, and using that to display a non-blocking message in the installer UI. It leads me to believe we could have this be a warning (to avoid blocking install if the logic blows up) with not much difficulty including a link to the install site.
I can do some prototyping, but I think first we should check this against the 3.0 servicing bar in context of the various other issues in this space. /cc @leecow
Side note: the warning/error should be localized, to match the rest of the installer.
Here's what I think this would end up looking like--for the sake of the explanation, let's say this ships in 3.0.2. Both 3.0.0 and 3.0.1 have shipped at that point without changes related to this feature.
Add this to 3.0.2+ .NET Core Runtime MSI installer:
some 3.0.x .NET Core Runtime is installed. This is the same key for any future 3.0.x release.Add this to the Desktop bundle to check if a compatible .NET Core Runtime is installed:
3.0.0 or 3.0.1 (hard-coded), which didn't install the new reg key.some 3.0.x .NET Core Runtime is installed registry key.Risk: the .NET Core Runtime MSI is on the critical path of all Windows installers, including VS. Adding a new reg key doesn't seem risky, but the stakes are high if there's something our testing doesn't catch.
That all said, the root issue is already mitigated by:
With those in place, this feature has insignificant value. The only difference this adds on top of the mitigations above is that the user is told they're missing the .NET Core Runtime during installation, rather than when they try to launch their FDE app.
I believe we should not invest in this feature: closing unless there's a strong argument for it. (Note that it only applies to 3.0: in 3.1 we are removing this dependency by bundling the installers.)
Most helpful comment
Added 3.0 milestone to consider for a servicing release.
In 3.1, we're planning to implement https://github.com/dotnet/core-setup/issues/8504. That bundles the .NET Core Runtime installer in the WindowsDesktop installer, making this mitigation unnecessary because there is no dependency.
Ideally the bundling improvement can also be ported to 3.0 as a servicing fix, but if not, we should still consider adding/expressing this dependency in the installer as a servicing fix for 3.0.
/cc @vatsan-madhavan