Microsoft has released a public preview of dotnetup, a cross-platform toolchain manager that installs, updates, and removes .NET SDKs and runtimes inside the user's account rather than a system-managed directory. As reported on the .NET Blog, the tool was announced on October 15 by Chet Husk, program manager for the .NET SDK, and follows the model of rustup and nvm.
According to the documentation, commands and behavior may change between preview releases, and production machines should keep using the installers, package managers, or Visual Studio.
The design, as described in the announcement, tracks intent instead of versions. A developer asks for a channel such as latest, lts, preview, daily, a major like 10, a minor like 10.0, or a feature band like 10.0.1xx, and dotnetup resolves it to a release. Exact versions, as the post notes, stay pinned during updates.
Several requirements can share one managed installation, and the tool reads the nearest global.json so team builds stay deterministic. Furthermore, according to the docs, files live under the user's local data directory on Windows, macOS, and Linux, and dotnetup never writes to Program Files\dotnet or /usr/share/dotnet.
Installation uses a bootstrap script fetched from aka.ms with curl or irm. As described in the docs, it places the binary in ~/.dotnetup after checking its SHA-512 checksum, and dotnetup init then installs the latest stable SDK and configures the shell. The docs list three access modes: none runs .NET through dotnetup dotnet without touching the environment, shell edits the shell profile, and everywhere, the Windows-only default, changes the system PATH and needs elevation.
The docs also warn that everywhere mode takes precedence over machine-wide copies, including the one Visual Studio installs, so projects needing an SDK dotnetup has not installed fail to build. To avoid that, setup reportedly offers to migrate existing machine-wide installs.
As reported, monthly servicing becomes a single dotnetup update, which re-resolves every tracked channel and installs the newest matching versions. Individual runtimes can be targeted, for example dotnetup runtime install aspnetcore@10.0, and the docs list the SDK, .NET runtime, ASP.NET Core runtime, and Windows Desktop runtime as supported components. After an update, as stated in the post, dotnetup removes any component no remaining requirement needs, and sdk uninstall or runtime uninstall trigger the same cleanup.
Moreover, preview and daily builds install side by side through dotnetup sdk install preview or dotnetup runtime install daily, although the docs note that daily builds are not code-signed. dotnetup self update refreshes the tool itself. Over the dotnet-install scripts, the post claims tracking of installed components, signature and checksum validation, faster multi-version installs, and one CLI surface on every platform. The stated roadmap includes admin-level installs on Windows, replacing the script-based parts of the GitHub Actions and Azure DevOps tasks, and agent skills so AI assistants reach for the tool by default.
Meanwhile, on r/dotnet, one developer with months of use praised the simpler Linux setup, but the top comment asked why anyone would pick dotnetup over mise, which several already use.
Others criticized the curl-to-shell bootstrap, asked for winget, apt, or Homebrew packages, noted that Visual Studio does not see dotnetup installs, and wanted dotnet-ef and other CLI tools managed too. In reply on the blog, Husk stated that packages are planned after user validation.
For interested readers, full documentation, including the command reference and telemetry details, is available on Microsoft Learn, and feedback goes to the dotnetup category of the dotnet/sdk GitHub discussions.
About the Author
Almir Vuk
Show moreShow less