dotnet
Design Description - .NET Core installation cleanup tool
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.
@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.
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
@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-yesflag.
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.
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!
I would think this relates to the tool. @KathleenDollard, since she wrote the description.