Microsoft has launched a public preview of dotnetup, a cross-platform toolchain manager that installs, updates, and removes .NET SDKs and runtimes within a user's personal account instead of system-managed directories. Announced October 15 by Chet Husk, program manager for the .NET SDK, the tool follows patterns established by rustup and nvm, according to a report published on InfoQ. The new manager aims to simplify version control for .NET developers by tracking intent rather than specific version numbers.
The toolchain manager operates by allowing developers to request channels such as latest, lts, preview, or daily, as well as major versions like 10, minor releases like 10.0, or feature bands like 10.0.1xx, which dotnetup then resolves to a specific release. Files are stored under the user's local data directory on Windows, macOS, and Linux, and the tool never writes to Program Files\dotnet or /usr/share/dotnet. Installation happens through a bootstrap script retrieved from aka.ms using curl or irm, which places the binary in ~/.dotnetup after verifying its SHA-512 checksum. The tool offers three access modes: none runs .NET through dotnetup dotnet without modifying the environment, shell edits the shell profile, and everywhere—the Windows-only default—changes the system PATH and requires elevation. Monthly servicing becomes a single dotnetup update command, which re-resolves every tracked channel and installs the newest matching versions. Individual runtimes can be targeted, such as dotnetup runtime install aspnetcore@10.0, with supported components including the SDK, .NET runtime, ASP.NET Core runtime, and Windows Desktop runtime.
According to the announcement, dotnetup tracks intent instead of versions, and exact versions stay pinned during updates. After an update, dotnetup removes any component no remaining requirement needs, and sdk uninstall or runtime uninstall trigger the same cleanup. The documentation warns that everywhere mode takes precedence over machine-wide copies, including the one Visual Studio installs, so projects needing an SDK dotnetup hasn't installed fail to build. To prevent this issue, setup offers to migrate existing machine-wide installs. Preview and daily builds install side by side through dotnetup sdk install preview or dotnetup runtime install daily, though the documentation notes that daily builds aren't code-signed.
The tool claims several advantages over the dotnet-install scripts, including tracking of installed components, signature and checksum validation, faster multi-version installs, and one CLI surface on every platform, as stated in the post. Microsoft's roadmap includes admin-level installs on Windows, replacing the script-based parts of GitHub Actions and Azure DevOps tasks, and agent skills so AI assistants reach for the tool by default. However, community reaction on r/dotnet has been mixed—one developer with months of use praised the simpler Linux setup, but the top comment questioned why anyone would choose dotnetup over mise, which several already use. Others criticized the curl-to-shell bootstrap, requested winget, apt, or Homebrew packages, noted that Visual Studio doesn't see dotnetup installs, and wanted dotnet-ef and other CLI tools managed too. In response, Husk stated that packages are planned after user validation. 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. The documentation cautions that commands and behavior may change between preview releases, and production machines should continue using the installers, package managers, or Visual Studio. Organizations evaluating toolchain standardization may find the shift from system-wide to user-scoped installations challenges existing deployment workflows. Teams accustomed to centralized SDK management will need to weigh the flexibility of intent-based channel tracking against the operational overhead of coordinating user-level installations across development environments.