Automatic Updates of .NET 6 and .NET Core 3.1 leaving behind previous runtimes and SDKs

[cuellartech]

We have automatic updates of .NET Core 3.1 and .NET 6 enabled in our Enterprise, using WSUS with Configuration Manager as the deployment tool.

We are experiencing an issue where the updates leave behind older versions of the SDKs and Runtimes installed.

Programs and Features in Control Panel only show the latest version of the SDK, but registry entries in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall are left behind as well as the files.

[greenEkatherine]

@dsplaisted could you please have a look if it is an issue with SDK?

[dsplaisted]

@joeloff Could you take a look at this?

[joeloff]

Do you have Visual Studio installs? Installs could have additional references which means they won't get cleaned up necessarily. You can run REG QUERY HKLM\SOFTWARE\CLASSES\Installer\Dependencies\ /s /f dotnet_runtime /k for example to get a list of all the runtime installs. For any given key, you can check if they contain any values under the dependents key,

Also, do you have any logs from the installs that were run through WSUS? That would probably be the easiest way to tell whether there are shared installs that are being retained

[cuellartech]

Checking those keys, multiple runtimes have values under the "dependents" key, including one that would indicate Visual Studio, which we have installed.

I have logs, gathered from the Temp folder of one of the affected machines. This specific machine hasn't received the 6.0.10 update but has two runtime versions after last month's 6.0.9 update. I've also included logs from when the 6.0.8 update was installed back in August, which did remove 6.0.7. I guess that's where some confusion lies as some updates seem to remove the older versions and others don't. This leaves some workstations with odd gaps in their installed runtimes, although preferably we would only see the latest version.

dotnet_Logs.zip

dotnet_Logs_Previous.zip

[joeloff]

Thanks. Just looking at the 3.1.28 runtime log, it shows that it detected multiple dependencies because of the standalone SDK and standalone runtimes. It also shows that Visual Studio is holding on to a 3.1.28 runtime installation

[8030:81C8][2022-09-21T22:08:04]w327: Will not uninstall package: dotnet_runtime_3.1.28_win_x64.msi, found dependents: 1
[8030:81C8][2022-09-21T22:08:04]w328: Found dependent: VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}, name: Unknown

The VS dependency tracking is a bit more complicated. The actual reference count is managed by VS, so it only writes a single standard value to the registry. All that means is that there is at least one instance of VS that's holding on to the 3.1.28 runtime.

The SDK install is similar. When trying to remove 3.1.422, the log shows multiple dependencies like this one

[80A0:7E94][2022-09-21T22:07:38]w327: Will not uninstall package: {6A280A78-51BD-4C80-8E58-EA2136AAA5F3}, found dependents: 2
[80A0:7E94][2022-09-21T22:07:38]w328: Found dependent: {231e3b76-4d0f-4e60-9d69-f11c9c448630}, name: Microsoft .NET Core Runtime - 3.1.28 (x64)
[80A0:7E94][2022-09-21T22:07:38]w328: Found dependent: {c2acf7e6-0112-4768-91c1-52b819ed91f2}, name: Microsoft .NET Core SDK 3.1.423 (x64)

[cuellartech]

Interesting. I guess my question is why are these dependencies preventing removal? I assume it's to prevent any issues with projects or builds?

And if VS is the reason, what can we do to ensure older versions are being removed at update time? And why was the removal of 6.0.7 successful but not 6.0.8?

All of this seems contradictory to the blog post regarding automatic updates, .NET Core 2.1, 3.1, and .NET 5.0 updates are coming to Microsoft Update, which explicitly states that these are in-place updates that should remove previous patch versions.

A lot of questions I know, but I'm just trying to understand as much as possible so I have a detailed explanation for management. Especially as we are getting dinged on vulnerability scanning with all of these older versions being left behind.

[joeloff]

The dependencies are only there to ensure we don't remove something that's need by another product installation. Updates will clean up, but it's when you have multiple points of acquisition where the same underlying installer can be acquired that things get more complicated.

The standalone bundles (EXE installs) each ship a number of MSIs. The same MSI also ship in VS. Let's say you start with a clean machine and install an SDK, e.g. 3.1.422. All the MSIs now have a reference to the bundle.

If you install a copy of VS which has the exact same MSIs, VS doesn't reinstall them, but instead simply adds a second reference to each MSI. If you now decided to remove the standalone SDK, the entry in Add/Remove Program will be taken away and the references will be removed, but the MSIs won't be uninstalled.

If we had removed the MSIs and you tried to build a .NET project in VS then we effectively broke another application. What makes things really complicated is that we ship multiple bundles for each release. There are separate bundles for the .NET runtime, ASP.NET and Desktop Runtimes. All these runtimes also ship in the SDK and most releases have multiple SDKs.

We did make changes in Microsoft Update in September to avoid over offering updates. Originally, the MU/WSUS detection would detect individual MSIs and then try to offer the best update. This was a problem when VS was present on the machine. Instead of allowing VS to be updated, MU could run first and if it detected the SDK, offer the standalone SDK. Technically you've now acquired an additional item you did not previously have installed. This can lead to the situation you're seeing.

The new behavior is to only offer updates for the standalone bundles (EXE). That means if you acquired the SDK through VS, we won't offer the standalone SDK through MU and you'd have to update it by updating VS.

I understand the concern with scans, especially in large environments.

@jamshedd as an FYI.

[marcpopMSFT]

Old issue triage: we don't a good solution for uninstall beyond the uninstall tool. Assigning to Ashnaga who's doing acquisition customer development