Hosting Bundle installer removes existing x64 runtime if OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 are used

[jberezanski]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

On a 64-bit machine where the core Runtime 6.0.11 and the ASP.NET Runtime 6.0.11 are already installed (both x64 and x86), running the Hosting Bundle 6.0.11 installer with the OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 parameters results in the ASP.NET Runtime x64 being uninstalled (but only that one runtime; core runtimes x64 and x86, as well as ASP.NET runtime x86 remain installed).

With .NET 7 the problem is worse. In a similar scenario, on a machine with 7.0.0 core and ASP.NET runtimes installed, running the Hosting Bundle 7.0.0 installer with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 causes the uninstallation of both x64 runtimes (core and ASP.NET).

The problem first started happening with the Hosting Bundle 6.0.5. Version 6.0.4 is the last one to behave correctly.

It seems this happens only if the existing installed runtime is the same version as the Hosting Bundle being installed. When runtimes 6.0.5 were installed and Hosting Bundle 6.011 was invoked the problem did not occur (no runtimes got uninstalled).

Expected Behavior

The Hosting Bundle installer invoked with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 should not touch any existing installations of the core Runtime or ASP.NET Runtime (regardless of their bitness).

Steps To Reproduce

Initial machine configuration:

• a clean installation of Windows 10 Enterprise 21H2 x64
• minimal IIS installed via Enable-WindowsOptionalFeature -Online -FeatureName IIS-StaticContent -All
• all steps done in Windows PowerShell

Helper function used in all cases:

function DownloadAndInstall
{
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory = $true)] [Uri] $InstallerUri,
        [string[]] $ExtraArguments
    )

    $fileName = Split-Path -Leaf -Path $InstallerUri.LocalPath
    $filePath = Join-Path -Path $Env:TEMP -ChildPath $fileName
    $ProgressPreference = 'SilentlyContinue'
    Write-Host "Downloading $InstallerUri to $filePath"
    Invoke-WebRequest -UseBasicParsing -Uri $InstallerUri -OutFile $filePath

    $logName = '{0}.{1:yyyyMMddHHmmss}.log' -f $fileName, (Get-Date)
    $logPath = Join-Path -Path $Env:TEMP -ChildPath $logName
    $allArguments = $ExtraArguments + @('/install', '/quiet', '/norestart', '/log', $logPath)
    Write-Host "Invoking: $filePath $allArguments"
    $p = Start-Process -FilePath $filePath -ArgumentList $allArguments -PassThru
    $p | Wait-Process
    Write-Host "Exit code: $($p.ExitCode)"
    if (@(0, 3010) -notcontains $p.ExitCode )
    {
        throw "$fileName failed with code $($p.ExitCode)"
    }
}

Case 1: .NET 6.0.11

DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/8cf88855-ed09-4002-95db-8bb0f0eff051/f9006645511830bd3b840be132423768/dotnet-runtime-6.0.11-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/719bfd7c-bce2-4e73-937c-cbd7a7ace3cb/d4f570d461711d22e277f1e3487ea9c2/dotnet-runtime-6.0.11-win-x86.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/e874914f-d43d-4b61-8479-f6a5536e44b1/7043adfe896aa9f980ce23e884aae37d/aspnetcore-runtime-6.0.11-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/94504599-143a-4d53-b518-74aee0ebecca/dac4a7b1f7bdc7b4e8441d6befa4941a/aspnetcore-runtime-6.0.11-win-x86.exe'
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/db07eed5-297a-45b8-bea2-1e93c623a88c/6e5a8d3432e6213f071be3751ae53a08/dotnet-hosting-6.0.11-win.exe' -ExtraArguments @('OPT_NO_RUNTIME=1', 'OPT_NO_SHAREDFX=1')
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info

Result: after Hosting Bundle installation the ASP.NET Runtime x64 is missing.

Case 2: .NET 7.0.0

DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/87bc5966-97cc-498c-8381-bff4c43aafc6/baca88b989e7d2871e989d33a667d8e9/dotnet-runtime-7.0.0-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/75c0d7c7-9f30-46fd-9675-a301f0e051f4/ec04d5cc40aa6537a4af21fad6bf8ba9/dotnet-runtime-7.0.0-win-x86.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/388543cf-e110-4425-be62-2dfa1635586c/fab629ebe2c7b2edfa0f2ee9171de26b/aspnetcore-runtime-7.0.0-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/aa4da7f2-fa27-47b1-9ad0-ac07dcecb730/00101e955bae403e5a2a424b3c29fb78/aspnetcore-runtime-7.0.0-win-x86.exe'
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/8de163f5-5d91-4dc3-9d01-e0b031a03dd9/0170b328d569a49f6f6a080064309161/dotnet-hosting-7.0.0-win.exe' -ExtraArguments @('OPT_NO_RUNTIME=1', 'OPT_NO_SHAREDFX=1')
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info

Result: after Hosting Bundle installation the entire x64 .NET is missing, even dotnet.exe.

Case 3: .NET 6.0.5

DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/b395fa18-c53b-4f7f-bf91-6b2d3c43fedb/d83a318111da9e15f5ecebfd2d190e89/dotnet-runtime-6.0.5-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/205afc96-c1cf-499e-a02b-5222f0806f9b/c97f9ee3ce58cae4ffe746732fa99784/dotnet-runtime-6.0.5-win-x86.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/042e2559-fe53-4793-b385-665b7c1ca6d5/308ffacc925383207a8f1a27a1df8bdc/aspnetcore-runtime-6.0.5-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/6d6093d9-1547-410f-91e5-cd1c84cd29cc/ade04a37ae559ec060b331146fefed0e/aspnetcore-runtime-6.0.5-win-x86.exe'
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/ae1014c7-a005-4a0e-9062-b6f3056ded09/da5d731f5ead9e385427a77412b88fb0/dotnet-hosting-6.0.5-win.exe' -ExtraArguments @('OPT_NO_RUNTIME=1', 'OPT_NO_SHAREDFX=1')
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info

Result: after Hosting Bundle installation the ASP.NET Runtime x64 is missing.

Case 4: .NET 6.0.4

DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/2e97f1f0-f321-4baf-8d02-0be5f08afc4e/2a011c8f9b2792e17d363a21c0ed8fdc/dotnet-runtime-6.0.4-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/08e41641-f1b4-47b4-9ed9-c8672614f093/ea66a30f9f8ac7320ea0d7f6e4d5d2d9/dotnet-runtime-6.0.4-win-x86.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/2162932c-987a-4de8-ae2a-f7d327bb39a8/97fe1cb950c2bccf44b7c3fe6aa45b53/aspnetcore-runtime-6.0.4-win-x64.exe'
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/c2093d31-b27e-4876-891c-750247cf1faa/33b9191b128a1d33671549972403994e/aspnetcore-runtime-6.0.4-win-x86.exe'
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info
DownloadAndInstall 'https://download.visualstudio.microsoft.com/download/pr/0c2039d2-0072-43a8-bb20-766b9a91d001/0e2288a2f07743e63778416b2367bb88/dotnet-hosting-6.0.4-win.exe' -ExtraArguments @('OPT_NO_RUNTIME=1', 'OPT_NO_SHAREDFX=1')
& "${Env:ProgramFiles}\dotnet\dotnet.exe" --info
& "${Env:ProgramFiles(x86)}\dotnet\dotnet.exe" --info

Result: this version works as expected - all 4 runtimes remain present after Hosting Bundle installation.

Exceptions (if any)

N/A

.NET Version

First found in 6.0.5 (see bug description).

Anything else?

Attached are PowerShell console commands and output from the four scenarios described in Steps To Reproduce, as well as log files created by the installers.

v6.0.4-console.txt
v6.0.4-logs.zip
v6.0.5-console.txt
v6.0.5-logs.zip
v6.0.11-console.txt
v6.0.11-logs.zip
v7.0.0-console.txt
v7.0.0-logs.zip

[adityamandaleeka]

cc @wtgodbe @joeloff

[wtgodbe]

Am I understanding right that the scenario is - runtime version X is already installed, then when running the hosting bundle for the same version X with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1, that runtime gets uninstalled? Are you running the hosting bundle just for the purpose of getting ANCM?

This does sound like a bug, and may be a scenario we didn't already consider. I'd suggest working around this for now by not passing those switches, we'll look in to creating a fix.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[joeloff]

@wtgodbe this is likely an issue with not passing the commandline option through to the uninstall of the previous hosting bundle, so when that runs, it detects that the installed runtime matches the runtime it carries and proceeds to remove it.

[jberezanski]

@wtgodbe

runtime version X is already installed, then when running the hosting bundle for the same version X with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1, that runtime gets uninstalled?

Correct. (However, only the 64-bit runtime gets uninstalled; the 32-bit runtime remains installed.)

Are you running the hosting bundle just for the purpose of getting ANCM?

That's right. I'm forced to do that because of the lack of an ANCM-only installer (which I had asked for some years ago, but despite a favorable reaction in the initial discussion the installer never materialized). I'm using a modular approach to server configuration and I want to have completely separate control over the installation of runtimes and ANCM.

[jberezanski]

@joeloff

this is likely an issue with not passing the commandline option through to the uninstall of the previous hosting bundle

The problem occurs also on a clean machine, with no previous hosting bundle installed (please see the reproduction steps).

[joeloff]

Thakns, I think I know what's going on here.

@wtgodbe for EXE packages, if the install condition is false, the bundle will remove the package, even during an install when it detects that it is present. See this

It's likely detecting the bundle as it matches what's being installed and skipped from the hosting bundle so the engine believes it needs to be removed.

I'll sync with you to see if we can find a workaround. WiX v3 is not taking any changes at the moment (other than critical and security AFAIK) and this behavior has been around for about 10 years now. The one option to work around this is to pull in the standalone MSIs instead of the actual runtime bundles, but this would be a significant change.

[jberezanski]

Looking from a different angle: the problem first started happening in 6.0.5. What changed from 6.0.4 and could that change be reverted?

[wtgodbe]

Looking from a different angle: the problem first started happening in 6.0.5. What changed from 6.0.4 and could that change be reverted?

#41057

We don't want to revert that change, since in most scenarios, users who uninstall the hosting bundle would want it to uninstall its associated runtimes, if it was the source of those runtime installs. It looks like in your particular scenario that's leading to bad behavior - I'll work with @joeloff to see if we can find a solution