Microsoft releases dotnetup preview, a .NET version manager that skips admin rights

What dotnetup is

Microsoft released the public preview of dotnetup on October 15, 2026, a cross-platform toolchain manager for .NET SDKs and runtimes. The announcement was made by Chet Husk, program manager for the .NET SDK, on the .NET Blog, and the tool follows the model already familiar from rustup (Rust) and nvm (Node.js).

The key difference from the traditional installer is where the files live. Instead of writing to Program Files\dotnet on Windows or /usr/share/dotnet on Linux and macOS, which requires administrative privileges, dotnetup keeps everything in the user account's own local data directory, across all three operating systems.

The official documentation is upfront about the project's stage: commands and behavior may change between preview releases, and production machines should keep using the official installers, package managers, or Visual Studio.

Channels instead of version numbers

The design, as described in the announcement, tracks intent rather than an exact version. A developer requests a channel such as latest, lts, preview, or daily, a major version such as 10, a minor version such as 10.0, or a feature band such as 10.0.1xx, and dotnetup resolves that into a concrete version.

Exact versions, according to the documentation, stay pinned during automatic updates, which prevents a routine update from silently swapping the version a project expects. Multiple version requests can share a single managed installation, and dotnetup reads the nearest global.json to the project to keep team builds deterministic.

Installation and the three access modes

Installation uses a bootstrap script fetched from aka.ms via curl or irm. According to the documentation, the script places the binary in ~/.dotnetup after verifying the SHA-512 checksum, and the dotnetup init command installs the latest stable SDK and configures the shell.

The documentation lists three access modes:

• none: runs .NET through dotnetup dotnet, without touching the system environment.
• shell: edits the user's shell profile.
• everywhere: the default mode on Windows only, changes the system PATH and requires elevated privileges.

The documentation also warns that the everywhere mode takes precedence over machine-wide copies, including the one Visual Studio installs. In practice, this means projects that need an SDK dotnetup didn't install can simply fail to build. To avoid that scenario, the setup process offers to migrate existing machine-wide installations into dotnetup.

Monthly updates and automatic cleanup

Monthly maintenance becomes a single command, dotnetup update, which re-resolves every tracked channel and installs the newest versions that match each one. Individual runtimes can also be targeted directly, as in dotnetup runtime install aspnetcore@10.0. The documentation lists the SDK, the .NET runtime, the ASP.NET Core runtime, and the Windows Desktop runtime as supported components.

After an update, dotnetup removes any component that no tracked requirement still needs, and the sdk uninstall or runtime uninstall commands trigger the same cleanup. It's behavior similar to what language package managers already do, but new for Microsoft's native .NET ecosystem.

Preview and daily builds side by side

Preview and daily versions install side by side with stable builds through dotnetup sdk install preview or dotnetup runtime install daily, although the documentation makes clear that daily builds aren't digitally signed. The dotnetup self update command updates the tool itself.

Compared with the dotnet-install scripts Microsoft already distributed, the company claims tracking of installed components, signature and checksum validation, faster multi-version installs, and a single command-line surface that's the same on any platform.

What the community is already questioning

On r/dotnet, the initial reception mixes praise and skepticism. One developer who has used the tool for months praised the simplified setup on Linux, but the thread's top-voted comment asked why anyone would choose dotnetup over mise, a tool several people already use to manage versions across multiple languages, not just .NET.

Other criticisms raised by the community:

• The bootstrap model via curl or irm piped straight into the shell, with no native package.
• Requests for winget, apt, or Homebrew packages instead of the script.
• The fact that Visual Studio doesn't see installations made by dotnetup.
• The lack of management for CLI tools such as dotnet-ef.

Responding on the blog itself, Husk said native packages are planned, but depend on validation with preview users before they enter the roadmap.

Roadmap and what's missing

The roadmap Microsoft disclosed includes admin-level installs on Windows (currently restricted to everywhere mode), replacing the script-based parts of GitHub Actions and Azure DevOps tasks, and creating agent skills so AI assistants use dotnetup by default when setting up environments.

For .NET developers in Brazil, the most immediate benefit targets locked-down corporate machines, where asking for administrator privileges to switch SDKs is real, recurring friction. The question that remains open, raised by the community itself in the source, is whether it's worth adopting a .NET-only tool when mise already solves the same problem for several languages at once, within a single workflow.