[DevBlog MS] Introducing dotnetup: A toolchain manager for .NET

[xSicKxBot]

Getting started with .NET on macOS and Linux has historically meant navigating a plethora of options: system package managers like

Code:

apt

or

Code:

brew

, platform-specific tarballs, or standalone shell scripts like

Code:

dotnet-install.sh

. While those methods have served us well, they often collide with administrative permissions, leave files scattered across root directories, or make keeping multiple runtime versions side-by-side more awkward than it should be.

That’s why we’re introducing the public preview of

Code:

dotnetup

, a new .NET toolchain manager built to install, manage, and update .NET SDKs and runtimes directly in your user account.

Why dotnetup?

If you’ve spent time in ecosystems like Rust (

Code:

rustup

) or Node (

Code:

nvm

), you’re already familiar with the power of a dedicated toolchain manager. The core goal of

Code:

dotnetup

is to drastically reduce concept count and friction when getting a .NET environment running:

• Consistent ux: The same commands and tools across every platform, regardless of the details of the installation
  
  
• Non-admin by default: Everything lives comfortably in user-owned folders, not system-owned – meaning zero need for elevated permissions.
  
  
• Side-by-side runtime management: Keep multiple servicing versions, preview channels, and daily builds installed at once without them stepping on each other’s toes.
  
  
• Track intent: Instead of managing versions, track majors or feature bands and let the tools keep you updated each month
  
  
• Respect for project pinning: Works seamlessly with your existing
  Code:

  global.json
  files so team builds remain predictable and deterministic.
  
  

Let’s walk through how to get started and how to use

Code:

dotnetup

for common day-to-day tasks.

Installing dotnetup and getting started

To get

Code:

dotnetup

on macOS or Linux, run the bootstrap script in your terminal:

macOS (Zsh):

Code:

[code]curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh | zsh[/code]

Linux (Bash):

Code:

[code]curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh | bash[/code]

PowerShell (

Code:

pwsh

):

Code:

[code]irm https://aka.ms/dotnetup/get-dotnetup.ps1 | iex[/code]

Once the script pulls down the binary, initialize your environment:

Code:

[code]dotnetup init[/code]

The

Code:

init

command sets up your shell profile so that

Code:

dotnet

is immediately available in your terminal sessions and fetches the latest stable .NET SDK.

https://devblogs.microsoft.com/dotnet/wp...tarted.mp4

Let’s check what’s installed in our local environment:

Code:

[code]dotnetup list[/code]

You’ll see a clean inventory of the SDKs and runtimes currently managed by

Code:

dotnetup

right in your home folder.

Keeping runtimes fresh month-over-month

Every month the .NET team ships servicing updates with security fixes and quality improvements. Keeping your local dev machine up to date helps you build and test against those fixes. For self-contained applications, you also need to republish and redeploy with the updated runtime. Updating your machine does not patch applications you have already shipped.

When using system installs, you may not be in control of your ability to update. With

Code:

dotnetup

, staying current is a one-liner:

Code:

[code]dotnetup update[/code]

This command resolves your tracked SDK and runtime channels again and installs the latest matching versions. For example,

Code:

10.0

tracks updates within .NET 10, while

Code:

latest

follows the latest stable SDK, including new major releases. Exact-version requirements stay pinned, so an installation requested as

Code:

10.0.3

will not advance during an update.

If you only want to install or refresh a specific runtime flavor, like the ASP.NET Core runtime on .NET 10, you can target it cleanly:

Code:

[code]dotnetup runtime install aspnetcore@10.0[/code]

https://devblogs.microsoft.com/dotnet/wp...ntimes.mp4

After a successful update,

Code:

dotnetup

automatically removes installed components that no remaining requirement needs. Versions that another channel or exact-version requirement still needs stay installed.

When you no longer need a tracked channel or exact version, remove that requirement with the corresponding

Code:

sdk uninstall

or

Code:

runtime uninstall

command.

Code:

dotnetup

then cleans up the installations that are no longer needed. See updating tracked installations for more details.

Testing nightly and preview builds

Beyond routine monthly servicing, many developers want to test bug fixes or check out new runtime capabilities before they hit stable release channels. Previously, testing a nightly runtime build meant hunting down raw installer tarballs from GitHub, manually unpacking them into custom directories, and tweaking environment variables by hand.

Code:

dotnetup

treats previews and nightlies as first-class citizens. You can install preview SDKs side-by-side with your stable setup:

Code:

[code]dotnetup sdk install preview[/code]

https://devblogs.microsoft.com/dotnet/wp...nstall.mp4

Or pull down the latest daily runtime build to verify an issue fix:

Code:

[code]dotnetup runtime install daily[/code]

Or grab an entire SDK to check out the entire toolchain:

Code:

[code]dotnetup sdk install daily[/code]

You get the flexibility to test daily builds across your user account and clean them up easily!

Updating

Code:

dotnetup

itself

We’ll be pushing features and fixes to

Code:

dotnetup

over time, and you can get them easily:

Code:

[code]dotnetup self update[/code]

Common questions

Here are quick answers to a few questions you might have:

I could do all of this with

Code:

dotnet-install.[sh|ps1]

That’s not a question.

But yeah, you could do most of this with the install scripts.
What you miss out on is

• management of the installed SDKs and Runtimes
  
  
• signature and checksum validation of the installed SDKs and Runtimes
  
  
• faster installation of multiple SDKs and Runtimes
  
  
• a unified CLI surface for doing this on every platform
  
  

Does dotnetup need sudo or root rights?

Nope.

Code:

dotnetup

is currently built for non-admin, user-local operation. All SDKs, runtimes, and metadata live entirely within your user directory.

In a future release we’ll be adding support for managing the system-level installs on Windows because of how prevalent those
are on that operating system.

Can I use dotnetup in CI pipelines?

Absolutely. Because

Code:

dotnetup

doesn’t require root privileges and runs smoothly non-interactively, it’s a great fit for containerized or ephemeral CI workers where you need to spin up specific SDK or nightly runtime versions on the fly.

What’s on the roadmap for

Code:

dotnetup

?

As mentioned, we’ll be looking into support for Windows admin
installers, but we also want to integrate

Code:

dotnetup

into CI/CD systems
like GitHub Actions and Azure DevOps – ideally through replacing parts of the implementations of those tools today that rely on the dotnet-install scripts.

We also want to iterate on the user experience to better fit how
you all use the tool, and flesh out agent skills so that automated
assistants use the tooling more naturally and reach for it by default.

Where should I go for more details?

For the full CLI reference, advanced configuration options, and deep dives, head over to the dotnetup documentation on Microsoft Learn.

If you have feedback, run into bugs, or want to share your thoughts on the experience, please drop by the dotnet/sdk discussions on GitHub. We’d love to hear how it works for you, or how we can make it better!

The post Introducing dotnetup: A toolchain manager for .NET appeared first on .NET Blog.