Runtime: Make the .NET Desktop Runtime installer express its dependency on the .NET Core Runtime

Created on 30 Sep 2019  路  4Comments  路  Source: dotnet/runtime

[...] 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

area-Setup donotuse_Triaged

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

All 4 comments

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:

  1. Add a registry key along the lines of some 3.0.x .NET Core Runtime is installed. This is the same key for any future 3.0.x release.

    • This allows checking if there's a compatible 3.0 runtime enabled without iterating through possibilities or evaluating semver. (I don't think the WindowsDesktop installer can reasonably do either.)

Add this to the Desktop bundle to check if a compatible .NET Core Runtime is installed:

  1. Check for either of the old 3.0.0 or 3.0.1 (hard-coded), which didn't install the new reg key.
  2. Check for the some 3.0.x .NET Core Runtime is installed registry key.
  3. If either condition is true, we're good to go.

    • Otherwise, display a non-blocking warning linking the user to the download site.

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.

  • There is no technical benefit to installing the .NET Core Runtime before the .NET Desktop Runtime.
  • In theory, the warning could allow the user to save time downloading the .NET Core Runtime installer while continuing the .NET Desktop Runtime installation. However, this requires the user to know that it's ok to continue the .NET Desktop Runtime installer despite the warning, which seems unlikely.
  • I wouldn't expect the warning's UX to be significantly better vs. the Host dialog message, due to limitations in installer authoring.
  • With the new download page, I expect this scenario to be hit much less often.

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.)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omajid picture omajid  路  3Comments

nalywa picture nalywa  路  3Comments

jzabroski picture jzabroski  路  3Comments

GitAntoinee picture GitAntoinee  路  3Comments

chunseoklee picture chunseoklee  路  3Comments