.NET Core Uninstall Tool MSI is unsuitable for automation; request for standalone ZIP version reinstatement or MSI fix

[rand0mnz]

We are attempting to deploy and automate the use of the .NET Core Uninstall Tool across our organization using Microsoft Intune and other endpoint management tools. Unfortunately, the current delivery method — via a single dotnet-core-uninstall.msi — has several critical issues that make it unsuitable for scalable, automated use:

Problems with Current MSI:

• The MSI installs to C:\Program Files (x86), even on 64-bit systems, causing confusion and file path issues.

• Even when run from an elevated Administrator PowerShell session or SYSTEM context (via Intune Win32 apps or Proactive Remediations), the tool throws:

"The current user does not have adequate privileges. See https://aka.ms/dotnet-core-uninstall-docs"

• The MSI package does not extract usable standalone binaries (e.g., dotnet-core-uninstall.exe + required Microsoft.Deployment.DotNet.Uninstall.*.dll files), making it impossible to repackage or relocate.

• The tool cannot be invoked reliably from scripts, automation, or Intune even under elevated permissions, completely defeating its purpose in enterprise environments.

Previous ZIP Format Worked:

• Earlier versions of the tool (e.g., v1.6.0) were distributed as ZIP files that included the standalone executable and all required DLLs.
• These could be reliably deployed, copied to a standard location (e.g., C:\Program Files\dotnet-core-uninstall), and invoked with Start-Process -Verb RunAs or from SYSTEM context without issues.

Request: Please either:

1. Reinstate the ZIP distribution of the tool (e.g., as dotnet-core-uninstall.zip with the full EXE + DLLs), or

2. Fix the MSI installer so that:

• It installs to a 64-bit path (C:\Program Files)
• It works when invoked from an elevated shell or system context
• It exposes a usable install structure for scripting and automation

This tool is essential for keeping systems clean of deprecated SDKs and runtimes (e.g., .NET Core 3.1, 5.0), especially in security-conscious environments. A fix would significantly improve enterprise support.

[joeloff]

Can you clarify what is not being "extracted" and why you cannot invoke it?

You should be able to create your own zip.

1. Download the MSI
2. Create a folder, e.g. C:\uninstall, then run msiexec /a dotnet-core-uninstall.msi TARGETDIR=C:\uninstall. This will extract the MSI contents and you can zip it up and distribute through Intune, CCM, etc.

You can use Powershell + the zip to create a deployment in CCM or Intune.

[rand0mnz]

Following your note, we revisited this and tested using the full directory extracted from the MSI. This approach has worked successfully.

That said, we’re unclear on why the current distribution requires extracting files from the MSI and re-packaging them into a ZIP just to deploy via Intune. If the tool is now officially packaged as an MSI, why isn’t it suitable for direct deployment as a Line-of-Business (LOB) app in Intune? It would be helpful to understand the intended deployment workflow or any known limitations with the MSI in this context.

This feels like a somewhat blunt approach compared to previous versions of the tool. In version 1.6.0, we were able to deploy the tool simply by distributing a ZIP package containing the required binaries:

Required files (from the x64 ZIP):

• dotnet-core-uninstall.exe
• Microsoft.DotNet.Core.Uninstall.dll
• Microsoft.DotNet.Cli.Utils.dll
• System.CommandLine.dll
• System.Runtime.CompilerServices.Unsafe.dll
• LICENSE.txt
• README.md

Minimum files needed for scripted/headless use:

• dotnet-core-uninstall.exe
• Microsoft.DotNet.Core.Uninstall.dll
• Microsoft.DotNet.Cli.Utils.dll
• System.CommandLine.dll
• System.Runtime.CompilerServices.Unsafe.dll

Usage was simple:

dotnet-core-uninstall.exe list
dotnet-core-uninstall.exe remove --all-previews --yes

With the newer MSI-based installer:

• The tool installs only to C:\Program Files (x86)\dotnet-core-uninstall\
• A portable ZIP distribution is no longer available.
• This introduces complications for automation, scripting, and Intune-based deployments—especially when precise pathing or repackaging is needed.

Given that, it’s unclear why an MSI is now required just to extract the same set of files we previously deployed directly. If this is the intended long-term distribution format, could you clarify whether there are plans to improve portability or support direct use as an Intune LOB deployment?

[joeloff]

The tool was never designed for large deployments. Originally, the tool was designed for developers to help clear out SDKs. When .NET began shipping in VS 2017, it shipped using the standalone bundle (EXE) installer. Because that could be installed outside of VS, the SDK would be left behind when VS is uninstalled. Over time, users were left with a large number of SDKs that consumed a lot of disk space, especially since it installed to Program Files and developers often partitioned machines to keep folders like Program Files on SSD drives and the leftover SDKs consumed it very quickly.

That's just some background. From what I can tell, the tool has always been distributed as an MSI, though we did have a tar file for non-Windows. The zip only contained source code. The earliest release I see is 0.1.0 preview

I agree, MSIs are definitely not ideal for SCCM/Intune distribution. The application is compiled as a self-contained application, so the runtime needs to be distributed and it's possible that updates we made to migrate it away from NET Core 3.1 to .NET 8 may have complicated things.

Let me follow up with the team

[rand0mnz]

Ok that makes sense...

Thank you for the quick response and for looking into this.

The reason we've been using dotnet-core-uninstall is because our organization (and many others in the UK) is pursuing Cyber Essentials Plus (re)certification, which introduces stricter compliance checks year-on-year. For 2024/5 one of the flagged issues involves residual or outdated .NET Core runtimes and SDKs left behind after upgrades. These are now being reported as critical and/or high vulnerabilities that require remediation.

From our research, the dotnet-core-uninstall tool appears to be the recommended and most effective method to cleanly remove these older components, so we’ve tried to integrate it into our remediation process. We appreciate your efforts in maintaining the tool and helping us stay compliant.

Thanks again!

[matthew-gerber-cla]

Hello, has there been any further discussion internally on this subject? Requiring an MSI to be installed in order to uninstall old versions makes remediation of security findings quite inconvenient. Ideally, .NET would never leave behind old versions but having a portable package for this would be the next best thing.