如何使用 PowerShell 脚本卸载旧版本的 .NET SDK 和运行时？

Question

In one PowerShell script, I am trying to install the latest version of .NET SDKs and runtimes then uninstall the older versions.

I am currently using 2 resources from Microsoft:

• dotnet-install.ps1
• dotnet-core-uninstall-1.2.206301

List of SDKs and runtimes:

Host (useful for support):
  Version: 5.0.2
  Commit:  cb5f173b96

.NET SDKs installed:
  No SDKs were found.

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.25 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.25 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.12 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.2 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.25 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.12 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.2 [..\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App]

I try to remove these older versions by running this command:

dotnet-core-uninstall remove --all --runtime

Error Output:

dotnet-core-uninstall : Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target
of an invocation.
At line:1 char:1
+ dotnet-core-uninstall remove --all --runtime
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Unhandled excep... an invocation.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

 ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.DotNet.Tools.Uninstall.Shared.Commands.UninstallCommandExec.AskItAndReturnUserAnswer(IDictionary`2 bundles,
String userResponse)
   at Microsoft.DotNet.Tools.Uninstall.Shared.Commands.UninstallCommandExec.Execute(IBundleCollector bundleCollector)
   at Microsoft.DotNet.Tools.Uninstall.Shared.Configs.CommandLineConfigs.<>c__DisplayClass40_0.<.cctor>b__6()
   at Microsoft.DotNet.Tools.Uninstall.Shared.Exceptions.ExceptionHandler.<>c__DisplayClass0_0.<HandleException>b__0()
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean
wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Delegate.DynamicInvoke(Object[] args)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__21_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__22_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__20_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__11_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

According to Microsoft, the uninstall tool has limitations..

On Windows, the tool can only uninstall SDKs and Runtimes that were installed using one of the following installers:

• The .NET SDK and runtime installer.
• The Visual Studio installer in versions earlier than Visual Studio 2019 version 16.3.

Has anyone found a workaround for this or maybe another way to uninstall these SDKs and runtimes installed by the dotnet-installer.ps1 script? I would greatly appreciate any suggestions or tips. Thank you.

Answer 1

This is not exactly an answer, but instead more of information I've found regarding the dotnet-installer script and the SDK it "installs"

According to Microsoft Docs for dotnet-installer.ps1 script

The install scripts do not update the registry on Windows. They just download the zipped binaries and copy them to a folder. If you want registry key values to be updated, use the .NET installers.

Install directory default is %LocalAppData%\Microsoft\dotnet on Windows and /usr/share/dotnet on Linux/macOS.

-InstallDir|--install-dir

Specifies the installation path. The directory is created if it doesn't exist. The default value is %LocalAppData%\Microsoft\dotnet on Windows and /usr/share/dotnet on Linux/macOS. Binaries are placed directly in this directory.

Perhaps the answer is to search this folder for SDK installations and remove the folders?

However, according to this dotnet sdk issue from 2017, these "installations" are not really doing anything. 'Dotnet' does not search this path for SDKs. Maybe this has changed, but I did not find anything saying otherwise.

'dotnet' does not consider versions that were installed to the user's AppData folder; this is by design.

It seems like the SDK installations done by the dotnet-installer.ps1 script are meant only to be used in that same session and then forgotten about!

By default, the script adds the install location to the $PATH for the current session . Override this default behavior by specifying the -NoPath|--no-path argument. The script doesn't set the DOTNET_ROOT environment variable.

dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:
dotnet-install: - The SDK needs to be installed without user interaction and without admin rights.
dotnet-install: - The SDK installation doesn't need to persist across multiple CI runs.
dotnet-install: To set up a development environment or to run apps, use installers rather than this script. Visit https://dotnet.microsoft.com/download to get the installer.