Describe the bug

All .NET Core bundles may be installed in any order. A newer version is typically installed on top of an older one and always results in success with files upgraded to the new version (sometimes requiring a reboot).

The reverse is also possible - a customer may install an older version after installing a newer one. You might ask why anyone would do this, here are some reasons:

E.g. 1 - A customer has deployed a runtime version say 3.1.16 using our bundles across their environment. Now they are also a WSUS user and have approved only security updates for automatic deployment. The latest update 3.1.16 happens to be a non-sec release, so they would get offered the last sec update say 3.1.15. This means WSUS will try to offer and install 3.1.15 on top of 3.1.16.

In this above example, the 3.1.15 bundle needs to recognize that a newer version is present and do nothing other than return success.

E.g. 2 - a customer has deployed the latest update 3.1.16 from MU or WSUS or any other means. Later, they try installing an app developed by an ISV (or anyone really) that ships with 3.1.0 (or even 3.1.15) redistributed with the app. The app may try to this older version without detecting for the newer version first, and that should succeed. If the installer for the app sees the .NET Core bundle failing it might fail the entire install for the app even though the pre-requisite for the app has been met.

There are several other similar scenarios where this (success blocker) needs to work.

To Reproduce

1. Install .NET Core runtime (or ASP.NET Core runtime or Desktop runtime or SDK) bundle for 3.1.15.
2. Install an earlier version of the same bundle say 3.1.14.

Expected result: Installing an older version on top of the newer one should be a no-op with success. The second install attempt should return success (return code 0), not a failure or a blocker message and also no files should be downgraded.

The Ask: Update the ASP.NET Core Runtime and Hosting Runtime bundles to include success blockers. This is needed for 6.0, 5.0, 3.1 and 2.1.

From @joeloff:
Here’s what people need to do for each bundle.

1. If your bundle is not using WiXBalExtension, add a reference to the extension under the WiX element

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">

If you’re manually compiling the bundle, include the extension for Candle/Light using -ext WixBalExtension.dll

2. In the BootstrapperApplication or BootstrapperApplicationRef element, add the following

    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
      <bal:WixStandardBootstrapperApplication SuppressDowngradeFailure="yes"/>
    </BootstrapperApplicationRef>