dotnetup enters public preview: a user-local toolchain manager for .NET SDKs and runtimes
Victoria Shinder2 min readMicrosoft has released a public preview of dotnetup, a toolchain manager that installs, manages and updates .NET SDKs and runtimes directly in the user's account. The .NET blog post introducing it compares it to rustup for Rust and nvm for Node.
Why a new installer. The post says that on macOS and Linux, getting .NET has meant choosing between system package managers such as apt or brew, platform tarballs and scripts like dotnet-install.sh. Those methods, it says, often collide with administrative permissions, leave files across root directories and make keeping several runtime versions side by side awkward. The goals listed for dotnetup are the same commands on every platform, no elevated permissions (everything lives in user-owned folders), side-by-side installs of servicing versions, previews and daily builds, tracking a major version or feature band instead of exact versions, and respect for global.json pinning so team builds stay deterministic.
Getting started. On macOS and Linux a bootstrap script is piped to the shell (curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh | bash, or zsh); on Windows the PowerShell equivalent uses irm https://aka.ms/dotnetup/get-dotnetup.ps1 | iex. An init step then sets up the shell profile so dotnet is available in new terminal sessions and fetches the latest stable SDK.
Monthly servicing. A single update command re-resolves the tracked SDK and runtime channels and installs the newest matching versions. In the post's example, a 10.0 channel follows updates within .NET 10, while latest follows the newest stable SDK including new major versions; an exact version such as 10.0.3 stays pinned. Individual runtime flavours can be targeted, for example dotnetup runtime install aspnetcore@10.0. After a successful update, dotnetup removes components no remaining requirement needs. The post adds a reminder that updating a developer machine does not patch self-contained applications that have already shipped; those must be republished with the new runtime.
Previews and nightlies. dotnetup sdk install preview installs a preview SDK next to the stable one, and dotnetup runtime install daily or dotnetup sdk install daily pulls the latest daily build to check a fix, replacing what the post describes as hunting for tarballs and setting environment variables by hand.
Compared with the install scripts. The post concedes that most of this can be done with dotnet-install.sh/.ps1, and lists what those lack: management of installed SDKs and runtimes, signature and checksum validation, faster installation of several versions and one CLI on every platform. dotnetup does not need sudo or root; Microsoft says it fits containerised or ephemeral CI workers. The roadmap includes managing system-level installs on Windows, integration with GitHub Actions and Azure DevOps, ideally replacing parts that rely on the install scripts today, and agent skills so automated assistants reach for the tool by default. Feedback goes to the dotnet/sdk discussions on GitHub.
Source: .NET Blog, "Introducing dotnetup: A toolchain manager for .NET" — https://devblogs.microsoft.com/dotnet/introducing-dotnetup/