Design Description - .NET Core installation cleanup tool

[leecow]

Problem

From the beginning, .NET Core was optimized for side-by-side installations to solve a number of problems inherent in the .NET Framework installation and deployment models. Consequently, 1.x and 2.x installers for Windows and macOS would install successive updates to versioned sub-directories. Because of a desire to enable easy fallback to previously installed versions, the installers did not provide functionality which removed previous patch versions as updates were installed. This resulted in systems with a high number of patch versions installed. The problem is particularly acute in Visual Studio scenarios where users may have opted into Preview channels which see a significantly higher number of updates.

Strongly negative feedback from internal and external customers began increasing in the 2.1 and 2.2 development cycles.

Currently, the only options for removing unwanted versions of the .NET Core Runtimes and SDKs is to manually walk through Add/Remove Programs (Windows) or manual deletion of directories (macOS). This issue does not impact Linux installations as the update functionality was implemented for the 2.1 release.

Proposal

The Windows installer for 3.0 has been updated to remove the previous patch version after a new release has been installed. Similar updates will be made to the Mac installer though this may not be possible for the 3.0 release.

To assist customers with pre-3.0 installation cleanup, a guided tool will be provided to enable the controlled clean up of a system such that only the desired versions of the Runtime and SDKs remain. Control input will be through a combination of the command line and interactive input.

dotnet-uninstall

Verb	Argument or option	Help text/Description	Notes
list		List the .NET Core SDKs that are installed globally on the machine	This is the same as dotnet --list-sdks
uninstall	<string[] versions>	Remove the .NET Core SDKs specified
uninstall	--all	Remove all .NET Core SDKs installed globally on the machine
uninstall	--all-lower-patches	Remove .NET Core SDKs that have been replaced by higher patches
uninstall	--all-but-latest	Remove all .NET Core SDKs, except the highest version
uninstall	--all-but <string[] versions>	Remove all .NET Core SDKs, except those listed	Not logical with `uninstall <string[] versions>
uninstall	--all-below	Remove all .NET Core SDKs below specified version. The specified version will remain
uninstall	--all-previews	Remove all .NET Core Preview SDKs that are marked as previews
uninstall	--all-previews-but-latest	Remove all .NET Core Preview SDKs that are marked as previews, except the latest preview.
uninstall	--major-minor <major.minor>	Removes .NET Core SDKs that match the specified major.minor version.
uninstall	-v, --verbosity	Set the MSBuild verbosity level. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].

Out of scope

Verb	Argument or option	Help text/Description	Notes
uninstall	--leave-visual-studio-support	Leave .NET Core SDKs that Visual Studio needs	This is going to be tricky, perhaps needing a VS versions white list, but the benefit will be significant. Likely leave to the larger installer work.

Platform-specific considerations

• Windows: The tool will need to drive msiexec based on .NET Core installation data available in the registry.
• Mac: .NET Core installations on Mac systems do not leave behind a registered presence. Installation enumeration operations will be based on default installation directory contents (/usr/local/share/dotnet).
• Linux: Linux installations are well managed by the Package Managers and do not experience the same install version bloat. No changes in this area are planned.

[leecow]

@livarcocc @KathleenDollard - as a safety gate, would it be desirable for each verb to report what it will be uninstalled with a y/n prompt? This could be 'suppressed' with a -y, --assume-yes flag.

[KathleenDollard]

I just wanted to point out that I'm super not crazy about having a tool called dotnet-uninstall that specifically does SDK only things without specifying that. I think these are the right options, just not yet happy with how we are conveying them. I am not convinced that we can't get the syntax right and have the tool be called dotnet sdk, but if we don't want to do that, we could use another prefixing command.

If we want to make the verb dotnet-sdk-uninstall or dotnet-sdkuninstall I believe the second isn't Posix compliant), then that would be fine. The first would be sensible to people later transitioning to the dotnet sdk uninstall verb

[KathleenDollard]

@livarcocc @KathleenDollard - as a safety gate, would it be desirable for each verb to report what it will be uninstalled with a y/n prompt? This could be 'suppressed' with a -y, --assume-yes flag.

How disastrous is the uninstall? It would be annoying, but would it be OK to make a mistake? We don't normally have interactivity with CLI verbs, and I'd like this to be as consistent as possible with that behavior.

Perhaps the default behavior should be the same as -try for PowerShell. Just tell me what you would do, and then have a --do-it flag (not sure the right name, but that has a ring to it this morning).

dotnet uninstall --all
<list of SDKs that would be uninstalled>
dotnet uninstall --all --do-it
<done, they are gone>

That would require the confirmation, but be more automatable I think.

[yuchong-pan]

Hi @leecow, for the --verbosity option, do you mean the verbosity level setting of this tool instead of the MSBuild verbosity level? I'm just wondering if this is a typo. Thanks!

[leecow]

I would think this relates to the tool. @KathleenDollard, since she wrote the description.