Skip to main content

How to uninstall older .NET Core versions

Over time, your development machine and servers can accumulate multiple versions of .NET Core runtime and SDK installations. While having multiple versions is often necessary for compatibility, old versions you no longer need can consume valuable disk space and clutter your system. In this post, we'll walk through the process of safely identifying and uninstalling older .NET Core versions.

Why uninstall old .NET Core versions?

Before we dive into the how, let's understand why you might want to clean up old .NET installations:

  • Disk Space: Each SDK version takes up several hundred megabytes
  • Clarity: Fewer versions make it easier to manage your development environment
  • Security: Older versions may have known vulnerabilities
  • Maintenance: Keeping only what you need simplifies updates and troubleshooting

Checking installed versions

Before uninstalling anything, you need to know what's currently installed on your system.

Open your terminal or command prompt and run:

dotnet --list-sdks

This shows all installed SDK versions. You'll see output like:

3.1.426 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
6.0.425 [C:\Program Files\dotnet\sdk]
7.0.410 [C:\Program Files\dotnet\sdk]
8.0.404 [C:\Program Files\dotnet\sdk]

To check runtime versions:

dotnet --list-runtimes

Important considerations before uninstalling

Don't uninstall everything! Before removing versions, consider:

  1. Active Projects: Check which SDK versions your current projects target
  2. Team Requirements: Ensure you're not removing versions needed by team projects
  3. CI/CD Pipelines: Verify your build pipelines don't depend on specific versions
  4. Support Status: Keep at least one version that's currently in support

You can check .NET support lifecycle at Microsoft's official page.

Using the .NET Uninstall Tool

Microsoft provides an official uninstall tool that makes the process safe and straightforward.





After the installation has completed, the dotnet-core-uninstall tool is available in the command line.

Let’s first try the list command to see the versions it can find and delete:

dotnet-core-uninstall list

Now we use the dry-run command together with a filter to see what would be impacted when executing the delete:

dotnet-core-uninstall dry-run --all-below 8.0.0 --hosting-bundle

If you're satisfied with the preview, remove the versions:

dotnet-core-uninstall remove --all-below 8.0.0 --hosting-bundle

Next to cleaning up the hosting bundles, we can do the same thing for runtimes and SDKs:

dotnet-core-uninstall remove --all-below 8.0.0 --aspnet-runtime
dotnet-core-uninstall remove --all-below 8.0.0 --runtime
dotnet-core-uninstall remove --all-below 8.0.0 --sdk
Useful options
  • --all-below <version>: Remove all versions below the specified version
  • --all-but-latest: Keep only the latest version
  • --all-previews: Remove all preview versions
  • --sdk: Target SDK versions
  • --runtime: Target runtime versions
  • --force: Skip dependency checks (use carefully!)

Best practices for managing .NET Core versions

Some extra tips for managing your .NET Core versions:

  • Use global.json: Pin specific projects to specific SDK versions
  • Regular Cleanup: Schedule quarterly reviews of installed versions
  • Keep One LTS Version: Always maintain at least one Long-Term Support version
  • Document Dependencies: Keep track of which projects need which versions
  • Use Docker: For older projects, consider using Docker containers instead of installing old SDKs locally

Conclusion

Cleaning up old .NET Core versions is a straightforward process that can free up significant disk space and simplify your development environment. The official .NET Uninstall Tool provides the safest method, with preview options that let you see exactly what will be removed before committing to changes.

More information

.NET Uninstall Tool overview - .NET | Microsoft Learn

Popular posts from this blog

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...