Core: Asp.net Core hosting 2.1.5 uninstall will not remove the Core Runtimes 2.1.5 from add remove programs.

[penegiashok]

Asp.net Core hosting 2.1.5 uninstall will not remove the Core Runtimes 2.1.5 from add remove programs.

General

we have installed .Net core Hosting 2.1.5 on our servers, after some security vulnerabilities we have upgraded to .net Core Hosting 2.1.13
while we try to uninstall the .net Core hosting 2.1.5 .exe we still see the .net core Runtime 2.1.5 in our add remove programs.

dd_dd_DotNetCoreWinSvrHosting__20191107162714.log
dd_dd_DotNetCoreWinSvrHosting__20191107162714_000_AspNetCoreSharedFramework_x64.log
dd_dd_DotNetCoreWinSvrHosting__20191107162714_001_AspNetCoreSharedFramework_x86.log

[scalablecory]

@dagood

[dagood]

I think this is expected due to how these hosting installers are built, and you have to uninstall the runtime too. @joeloff can you confirm? Is this documented somewhere?

On the technical side, I believe the situation is that these hosting bundles contain the .NET Core Runtime EXE/bundle installers, not the MSIs, so the MSI ref-counting mechanism that normally handles this situation isn't available.

[penegiashok]

As we have number of servers where the old runtime is installed, is there a way for us to uninstall the old runtimes both x86 and x64 using command prompt or powershell ?
that would be helpful.
under the .net core documentation all it listed was to do it manually from Add/Remove programs.

[joeloff]

Nope, don't think this is documented. The Windows Hosting bundle chains the runtime bundles, so if anything else installed the same runtime bundle, you have to manually remove it.

I'll take a look at the logs, it might provide a hint as to what's holding the reference and update the comments

[dagood]

if anything else installed the same runtime bundle, you have to manually remove it.

It's a little worse than this in an experiment I did on a clean VM: installing the 2.1.5 hosting bundle then uninstalling the 2.1.5 hosting bundle leaves the 2.1.5 .NET Core Runtimes on the machine. No other references required. ~This seemed to match my thoughts about this being caused by bundles not having ref counts, so the hosting bundle uninstall can't decide whether or not it needs to uninstall the runtimes. (And I guess it doesn't, to be safe.)~ (Edit: This is not a complete picture, the bundle is marked "permanent", see below.)

is there a way for us to uninstall the old runtimes both x86 and x64 using command prompt or powershell ?

There are some powershell scripts floating around that will uninstall everything, maybe they can be adapted? Searching in the dotnet org I found https://github.com/dotnet/cli-lab that describes a guided tool for this scenario, but I'm not sure about its status. @leecow any guidance here?

[joeloff]

From the looks of the log it appears it's not detecting the installation state of the runtime bundle itself.

[joeloff]

If you run something like this:

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /reg:32 /s /f "*.NET Core*"

you'll get the a list of all installed .NET Core entries, e.g.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{B523578E-8F70-3EB0-83AD-B4DE300B7059} DisplayName REG_SZ Microsoft .NET CoreRuntime SDK

You'd want to look for runtime entries and specifically their UninstallString values and if it's an EXE, that should indicate that its a bundle. The UninstallString will contain the command to run to remove the bundle.

[joeloff]

I looked at the hosting bundle's manifest and I can confirm that the runtime was authored as permanent.

[leecow]

@dagood, the cli-lab project isn't quite ready for release and I wouldn't be comfortable recommending any of the other scripts floating around given this is an inherently destructive activity.

[carlossanlop]

@leecow @dagood any progress on this?