Microsoft Releases dotnetup in Preview: Easier Management of Multiple .NET Versions

You open an older .NET project to fix a production bug. Another project needs a newer SDK, while a third is testing a preview release. Before changing any code, you need to check which SDK each project will use and whether installing another version will affect your existing environment.

According to the supplied Publickey report dated October 19, 2026, Microsoft has released dotnetup, a .NET toolchain manager, in public preview to address this problem.

dotnetup is a tool for installing and managing multiple .NET toolchains on a single machine. It provides a consistent command-line experience across Windows, macOS, and Linux. It can be installed in a user directory without administrator privileges and supports existing global.json settings that control SDK selection.

For developers working on projects with different requirements, the useful change lies in ongoing management: maintaining the environments they need, selecting the right SDK, and updating within the intended release line.

Working on Projects with Different Requirements on One Machine#

Consider a developer working across four repositories:

• A production application that must continue using an approved SDK.
• A service that can accept updates within a selected release line.
• A shared library tested across multiple .NET environments.
• An experimental application using preview builds.

Simply installing the latest SDK will not meet all four requirements. The production application needs predictable builds. The service needs maintenance updates. The library needs compatibility testing, and the experimental application needs access to software under development without other projects inadvertently adopting it.

.NET already supports installing multiple SDKs side by side. The question is how easily developers can maintain them and determine which SDK a project will use.

With this preview, Microsoft positions dotnetup as a management tool dedicated to these tasks. Publickey compares its role to Rust’s rustup and the Node.js version manager nvm. These tools let developers maintain multiple versions instead of treating installation as a single, fixed choice.

The comparison explains the purpose. It does not imply that dotnetup has identical commands, selection rules, or features.

What the dotnetup Preview Offers#

The supplied article describes several features that could make everyday .NET environment management easier.

Consistent Operation Across Operating Systems#

dotnetup aims to provide the same commands and tools on Windows, macOS, and Linux.

For teams using different operating systems, this could reduce the need for separate setup instructions for each OS. A shared development guide becomes easier to use when the basic installation and management process is consistent.

There are limits, however. A common command-line interface does not make operating systems interchangeable. Native dependencies, platform-specific workloads, and application behavior still require separate verification.

Installation Without Administrator Privileges#

According to the article, dotnetup stores the environments it manages in the user’s directory rather than in system folders. Installation therefore does not require elevation to administrator privileges.

This is useful on organization-managed devices where developers cannot freely modify system software. It also lets developers maintain their own toolchains without making machine-wide changes with every installation.

Internal policies still apply, however. Even when installation does not require administrator privileges, an organization may restrict executable downloads or require approved distribution sources.

Multiple Versions, Including Previews#

The preview supports installing and managing multiple versions and builds side by side, including preview releases.

This makes it easier to evaluate an upcoming release while retaining the SDKs required by existing projects. The key point to verify is whether each repository continues to select its intended SDK after another version is installed.

Installations can coexist successfully while an unexpected version is selected. Version selection deserves as much attention as installation.

Updates Within a Selected Release Line#

The article also describes the ability to track a major version or release channel and update accordingly.

This addresses a recurring maintenance challenge for teams: receiving bug fixes and security updates without unintentionally moving to another major release.

However, this should be understood as an update management feature, not as evidence of unattended patching. The supplied material does not establish whether updates happen automatically, what triggers them, or exactly how tracking settings interact with project settings.

Teams should check the preview documentation for these details before building a maintenance policy around the feature.

Why global.json Support Matters#

For existing teams, dotnetup’s support for global.json may be its most useful compatibility feature.

.NET projects can use global.json to specify SDK selection requirements, including version and roll-forward behavior. Keeping this configuration in the repository lets everyone working on the code see the expected development environment.

The distinction between the SDK and the runtime matters here. global.json controls SDK selection; it does not, by itself, define every runtime requirement of the deployed application.

Teams evaluating dotnetup therefore need to verify two things separately:

1. Whether the repository selects the expected SDK when a developer runs .NET commands. 2. Whether the built application runs correctly in the intended deployment environment.

Satisfying the first does not guarantee the second.

Support for existing global.json files should also mean that teams do not need to discard repository settings just to try a new installation management tool. Even so, compatibility should be verified against real projects, particularly when roll-forward settings could make several installed SDKs eligible for selection.

How It Differs from dotnet-install#

Microsoft already provides dotnet-install, so a new installation tool needs a clear purpose.

Publickey describes dotnetup as similar to the existing tool but with a stronger focus on ongoing management of multiple versions. That is the practical distinction. It would be misleading to suggest that multiple .NET installations could not coexist before dotnetup.

An installation script helps place an SDK or runtime in a specified location. A toolchain manager aims to simplify the work that continues afterward: maintaining multiple installations, tracking release lines, and accommodating each project’s version requirements.

For a developer who installs just one SDK and rarely switches projects, the distinction may offer limited value. For developers maintaining several release lines or regularly testing previews, it could reduce recurring setup work.

Teams with reliable installation scripts should weigh the management benefits against the cost of changing their current workflow. A public preview is an opportunity to experiment, not a requirement to migrate.

Five Steps to Evaluate It on Real Projects#

A useful trial should establish whether dotnetup makes existing work more predictable. Start on a development machine where problems with a preview tool would be manageable.

1. Record the Current Environment#

Before installing anything, record the SDKs and runtimes already available. Run dotnet --version in two representative repositories and note the selected SDK.

Also check how they were installed: through an OS package manager, Visual Studio, an installation script, or another method. This information can help explain unexpected SDK selection later.

2. Review Project Requirements#

Choose two repositories with different SDK requirements. Review each repository’s global.json, including its roll-forward settings.

If a repository has no explicit SDK configuration, decide whether that is intentional. Adding a toolchain manager will not resolve an unclear team policy about which SDK developers should use.

3. Install dotnetup Using Microsoft’s Official Instructions#

Follow the latest preview documentation for your operating system. Verify the download source before running an installation command.

The supplied article does not include installation commands, so copying guessed syntax would introduce avoidable risk. Check how installing the tool changes command lookup and resolution, and whether a new terminal session is required.

4. Test SDK Selection and Builds in Both Repositories#

Install the required environments using the documented dotnetup procedure. Return to each repository and check the selected SDK again.

Then build the projects and run their existing tests. Confirm that adding a second SDK or a preview SDK has not changed the first repository’s behavior.

This is the central acceptance test for the evaluation: both projects must remain usable with their intended settings.

5. Evaluate Updates Separately#

Try release tracking only after confirming that basic installation and SDK selection work.

Check what an update changes, whether the selected SDK changes afterward, and how to restore the previous working environment. Record the results so other developers can reproduce the process.

What the Current Preview Has Yet to Demonstrate#

According to Publickey, Microsoft plans to work on system-level management on Windows, CI/CD integration, and user experience improvements.

These are roadmap items. They should not be treated as completed features in the current preview.

CI requires particular care. An environment set up in a developer’s user directory does not automatically translate into a reproducible build-agent configuration. Before changing a pipeline, verify noninteractive installation, version selection, caching behavior, and failure handling against the actual preview documentation.

There is also no need to replace every existing installation method at once. Environments managed through Visual Studio and established build images may have different requirements from an individual developer’s command-line environment.

Start with Two Repositories#

The most promising benefit of dotnetup is practical: reducing manual work when multiple projects on the same machine need different .NET environments.

If SDK installation, preview testing, and release-line maintenance already consume your team’s time, the public preview is worth evaluating. The checks are straightforward: the right SDK is selected, builds succeed, and update behavior is understandable.

Choose two repositories with different requirements, record the SDKs currently selected, and follow Microsoft’s official dotnetup preview instructions. Confirm that both projects continue to build with their intended versions before expanding adoption.

Source: https://www.publickey1.jp/blog/26/netdotnetupnet.html