Hosting bundle do not uninstall old dotnet version

[Launster]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I got a windows server 2022 with dotnet 8.0.7 (intalled via the hosting bundle), when I upgrade to the last dotnet version (8.0.11) by using the Hosting bundle setup, the old version of dotnet is still here.

Expected Behavior

old runtime version should be uninstalled

Steps To Reproduce

Get a windows server 2022, install dotnet hosting bundle 8.0.7 then install dotnet hosting bundle 8.0.11 and check for dotnet runtime 8.0.7

Exceptions (if any)

No response

.NET Version

8.0.11

Anything else?

I saw this issue (#55950) which look like my problem.
I think my issue should have been fixed by this PR (#56459)

But it seems to not be the case.

dotnet --info output :

Host:
Version: 8.0.11
Architecture: x64
Commit: 9cb3b725e3
RID: win-x64

.NET SDKs installed:
No SDKs were found.

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

[nagababu0579]

I have the same issue. Started seeing this abnormal behavior starting from 8.0.8 version.

[wtgodbe]

This is due to #56459. We changed the way the Hosting bundle chains runtimes, so any installed runtime older than 8.0.8 needs to be manually un-installed. From 8.0.8 and on, you should see the behavior you expect (newer hosting bundle un-installs runtimes installed by older hosting bundle)

[nagababu0579]

@wtgodbe Can you please share any documentation which indicates this from 8.0.8 and higher. It's very important for us to inform customers what to do. Earlier we used to ask them to just install latest version on top of existing version.

Now if there is no old runtime installed, on installing hosting bundle installs runtime as expected. In case old runtime exist, then the new hosting bundle is removes old runtime and do not install new runtime. Not clear why we have different behavior based on old runtime.

This is a problem for us as we need to ask them to add runtime separately.

[wtgodbe]

@joeloff do you remember if we doc'd this behavior change? I can't find anything in the 8.0.8 release notes

@nagababu0579 if the hosting bundle doesn't install the new runtime when an old one is present, that's unexpected. Do you have any logs you could attach?

[nagababu0579]

@wtgodbe I am attaching the log files covering all these 3 below cases.

FirstTime_Installation.log: Contains first time installation logs [Installed 8.0.11 Hosting Bundle on top of 8.0.7 Hosting Bundle - - dotnet info command lists old runtime version]
Uninstall.log: Contains uninstallation logs[Uninstalled 8.0.11 Hosting Bundle]
SecondInstallation.log: Contains re-installation logs[Installed 8.0.11 Hosting Bundle - dotnet info command lists new runtime version]

FirstTime_Installation.log
Uninstall.log
SecondInstallation.log

[wtgodbe]

@nagababu0579 is it the dotnet runtime or the asp.net runtime that isn't getting updated on the first install? If it's the latter, I see in your logs that OPT_NO_RUNTIME=1 is being passed to the hosting bundle, which would explain why the 8.0.11 dotnet runtime isn't being installed. This could be because an earlier install of the hosting bundle was ran on the machine with this flag - the first time you run the hosting bundle installer, we write the values of switches like OPT_NO_RUNTIME or OPT_NO_SHAREDFX as registry keys. Then on subsequent installs, if no args are passed, we default to using the same flags that were passed on the previous install.

[nagababu0579]

@nagababu0579 is it the dotnet runtime or the asp.net runtime that isn't getting updated on the first install? If it's the latter, I see in your logs that OPT_NO_RUNTIME=1 is being passed to the hosting bundle, which would explain why the 8.0.11 dotnet runtime isn't being installed. This could be because an earlier install of the hosting bundle was ran on the machine with this flag - the first time you run the hosting bundle installer, we write the values of switches like OPT_NO_RUNTIME or OPT_NO_SHAREDFX as registry keys. Then on subsequent installs, if no args are passed, we default to using the same flags that were passed on the previous install.

[nagababu0579]

@wtgodbe When dotnet info command is run, .net core.app is not listed starting from hosting bundle 8.0.8 onwards when installed on top of version 8.0.7. We do not have this issue in versions 8.0.7 and before. This started only from versions 8.0.8 and higher.

If we uninstall hosting bundle (8.0.8 or higher) and re-install, then we can see .net core.app gets listed on running dotnet info command.

I am expecting the behavior (seeing .net core.app) should be same when we install 8.0.8 or higher on top of 8.0.7 and when we uninstall and reinstall 8.0.8 (or higher).

Moreover Shared Framework components and .Net runtime components are also no more displayed in control panel starting from 8.0.8 hosting bundle installation. These are displayed only when their direct software are explicitly installed and not when hosting bundle is installed.

We install software using chocolate packages. Can you please let me know if we need to correct anything to get asp.netcore.app installed properly? We never had this kind of issue until 8.0.7, only started from 8.0.8.

[wtgodbe]

Could you check the registry value for HKLM\SOFTWARE\Microsoft\dotnet\host\options\8.0\OPT_NO_RUNTIME before installing/uninstalling 8.0.8? I expect it is currently 1. If you set that to 0, I think installing 8.0.8 should work as you expect

[nagababu0579]

I checked and 'dotnet' key is not displayed until 8.0.7 version. In 8.0.11 version, I can see dotnet, but host key is not displayed.

[wtgodbe]

That's expected, 8.0.7 is when we started writing to that registry key for the hosting bundle. Were you able to check OPT_NO_RUNTIME? You can try Test-Path 'HKLM:\SOFTWARE\Microsoft\dotnet\host\options\8.0\OPT_NO_RUNTIME