dotnetup：也许是 .NET 开发者一直在等的工具链管理方式
Intro
.NET 11 将引入一个全新的 .NET 版本工具 dotnetup 和之前手搓的 dotnet-install 还在用脚本装 .NET？试试这个托管版 dotnet-install 类似，它会是 NativeAOT 的工具以避免依赖 .NET SDK。
对于很多 .NET 开发者来说，“安装 .NET” 这件事其实并不复杂。
真正复杂的，往往是下面这些问题：
• 电脑里装了好几个 SDK，到底当前用的是哪个？ • 想试一下 preview 版本，又怕把现有环境搞乱 • 公司电脑没有管理员权限，很多安装方式根本用不了（最近就经常遇到这个问题，公司电脑的权限比较严，更新 SDK 都会有问题） • 老项目、新项目、实验项目同时推进，版本切换越来越麻烦
如果你对这些场景很熟悉，那 dotnetup 很值得关注。
它不是一个单纯的安装脚本，而是一个面向 用户级安装 的 .NET 工具链管理器，使用 install 脚本还需要针对不同系统有不同的适配(bash/powershell script)，对于经常跨系统工作的开发者来说可以使用更统一的工具来管理我们的 .NET SDK 了。它想解决的核心问题很明确：
让开发者可以更轻松、更安全、更可控地安装、更新和管理 .NET SDK 与 Runtime。
而且，这一切 不一定需要管理员权限，也 不一定要依赖系统级包管理器。
Why
过去很多开发者对 .NET 的使用方式，大致都是这样的：
1. 去官网下载安装包 2. 装到系统目录 3. 配置 PATH 4. 如果要切换版本，再想办法处理环境问题
这套方式当然没有问题，它稳定、成熟、可靠。
但当开发环境越来越复杂以后，开发者真正需要的，已经不只是“把 SDK 装上”。
我们更需要的是一种工具链管理能力。
比如：
• 我想长期跟随 LTS 版本 • 我想单独试试最新 preview • 我想把新版本装到用户目录里，不碰系统环境 • 我想在终端里默认使用某个 .NET 版本，但不要影响整台机器 • 我想让多个项目并行工作时，版本管理更有秩序
dotnetup 的出现，正是朝这个方向迈出的一步。
What
dotnetup 是面向用户级安装的 .NET 工具链管理器。它允许您安装、更新和管理 .NET SDK 和运行时，而无需管理员权限或系统包管理器。
它的职责不是只做一次安装，而是持续帮你管理：
• 安装哪些 SDK / Runtime • 跟踪哪个版本通道 • 如何更新 • 如何让终端或系统识别这些安装 • 如何在不打扰现有环境的前提下，引入新的 .NET 版本
它更是在为 .NET 安装提供一种现代化的开发者体验。
Install
可以通过官方提供的脚本进行安装
macos/linux:
curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh | bash
windows:
iwr https://aka.ms/dotnetup/get-dotnetup.ps1 | iex
这些脚本将下载最新版本的 dotnetup 并将其安装到你的用户目录中 ~/.dotnetup，然后打印说明以更新 $PATH，以便 dotnetup 可以在您的终端中使用。
安装配置好之后可以通过 dotnetup -h 来验证
它解决的，不只是安装问题
很多人第一次看到 dotnetup，可能会觉得：
“哦，就是一个更方便的安装器。”
但如果仔细看它的设计，会发现它解决的其实是版本治理问题。
第一类问题：权限受限
在企业电脑、实验室设备、受管开发环境里，开发者经常拿不到管理员权限。
这时候，系统级安装路线会非常受限。
而 dotnetup 支持在用户目录中安装和管理 .NET，这一下就把很多原本麻烦的场景打通了。
第二类问题：多版本并行
现实开发中，很少只有一个项目、一个 SDK 版本。
你可能会同时遇到：
• 维护中的老项目，需要稳定版本 lts• 新项目，想跟进当前最新版本 latest• 试验性项目，需要 preview 甚至 daily build preview• 某些项目依赖特定 feature band 10.0.x
如果仍然用传统方式去处理，很容易陷入环境混乱。
而 dotnetup 提供了一个更清晰的抽象：频道（channel）
频道机制：把“版本管理”变成“策略管理”
这是 dotnetup 很有意思的地方。它没有只让你输入一个死板的版本号，而是提供了一组“频道”概念，频道分成两类：
• 基于版本的频道 可以指定一个版本号或版本范围 10,10.0.2xx,10.x等• 基于类型的频道 可以版本特征类型对其进行分组——例如 preview/lts/lastest等
具体使用示例如下：
• latest• lts• preview• 10.0• 10.0.1xx• 10.0.100
这意味着什么？
意味着你安装的，不只是一个版本，而是一种跟踪策略。
例如：
• 选择 latest：你希望始终使用最新稳定版• 选择 lts：你希望稳定跟随长期支持线• 选择 preview：你愿意持续尝试新的预览版本• 选择 10.0.1xx：你只希望在某个 feature band 内更新• 选择 10.0.100：你只想锁死到一个精确版本，不自动变化
需要更新时，只需要进行 dotnetup update 即可更新所有追踪的 channel，可以使用 dotnetup list 查看跟踪的 channel
第一次使用时，dotnetup 会怎么做？
dotnetup 支持交互式初始化。第一次运行时，它不会直接丢给你一堆参数，而是一步步引导你完成设置（你也可以后续通过 dotnetup init 来再次配置）
这个流程大概会围绕两个问题展开：
1）你想安装哪个频道？
也就是你想跟踪哪个版本线。
2）你希望如何使用 dotnetup 管理的 .NET？
这就引出了它的另一个亮点：三种使用模式。
How would you like to use dotnetup?
Isolation Mode
Use 'dotnetup dotnet' to consume installs managed by dotnetup.
New installs can be used alongside your existing installs.
> Terminal Mode (Suggested)
Configure the current shell profile to use installs managed by dotnetup.
Only applications launched from the shell will leverage dotnetup installs.
Replacement Mode (Windows only)
The system will be configured to use dotnetup installs over any other installs.1. Isolation Mode：先别动我现有环境
隔离模式下，你需要通过 dotnetup dotnet 来调用由它管理的 .NET。
比如：
dotnetup dotnet --version
这种方式非常适合：
• 想先试试看 • 不想碰系统 PATH • 不想影响机器上现有 .NET • 希望显式区分“系统 dotnet”和“dotnetup 的 dotnet”
说白了，这是一种最稳妥的“试用模式”。
2. Terminal Mode：让终端默认用它
这是文档中推荐的模式，也是大多数开发者最可能选择的方式。
它会更新你的 shell 配置文件，比如：
• .bashrc• .zshrc• PowerShell 的 $PROFILE
然后你在终端里直接运行 dotnet 时，默认就会走 dotnetup 管理的安装。
这很像一个折中方案：
• 不强行替换系统所有行为 • 但在你最常用的开发终端里，已经把体验切到新的工具链上
对于以 CLI 为主的开发者来说，这几乎就是“最自然的状态”。
3. Replacement Mode：我就想彻底接管
替换模式会更进一步，在系统层面修改 PATH 和 DOTNET_ROOT，让 dotnetup 管理的版本优先生效。
目前这个模式只支持 Windows，并且通常需要管理员权限。
这种方式适合的是：
• 非常明确地想让 dotnetup 成为默认 .NET 来源 • 对环境控制要求更高 • 已经理解其影响范围的高级用户
如果只是日常开发，很多人其实用 Terminal Mode 就已经足够，但是想要完全使用 dotnetup 管理 .NET SDK 的话推荐修改 PATH 和 DOTNET_ROOT 环境变量， DOTNET_ROOT 可以通过 dotnetup --info 来查看 dotnetup 的 dotnet 安装位置
dotnetup .NET 的工具链体验正在变得更现代
从公开文档来看，dotnetup 不只是为了“下载 SDK 更方便”这么简单。
它背后体现出一种很明显的产品思路：
1. 用户级优先
不是所有开发都应该建立在系统级权限之上。
2. 渐进式接入
先隔离、再终端、最后系统替换，开发者可以一步一步来，而不是一次性承担全部风险。
3. 用“频道”表达意图
相比死记硬背版本号，频道更符合开发者的思维方式。
4. 为并行开发和快速试验做准备
现代开发工作流里，“多个版本共存”已经是常态，不是例外。
这些思路放在今天来看，其实非常合理。
因为开发者早就不满足于“能装上就行”了，大家更在意的是：
• 可控性 • 可迁移性 • 可回退性 • 与现有工作流的兼容性
而 dotnetup 恰好在这些点上切得很准。
独立工具
dotnetup 目前仍然是一个独立且自包含的工具(Native AOT tool)，而不是直接内嵌在 .NET SDK 中。
因为这意味着：
• 它可以独立演进 • 它可以独立更新 • 某些策略能力不需要绑定到 SDK 的发布周期 • 它本身可以更快试验新设计
换句话说，现在的 dotnetup 更像是一个有明确产品方向的新能力入口。
More
目前已经开始使用这个工具来管理 macos 上的 .NET SDK 了，还是比较丝滑的，不会遇到之前使用 homebrew 安装还得管理员 approve 的情况了。
dotnetup 另外一个比较好的地方是支持 daily build，有需要的话可以使用 daily build 来更快地体验新的功能，而且按规划后面还是有一个类库支持开发者在核心基础上添加更多支持，后面可以考虑把 dotnet-install 的更新功能等基于这一类库来实现。
目前这个工具还在 preview 欢迎大家进行下载体验并给出自己的反馈让它变得更好, 在 GitHub Discussion 里查看或添加新的反馈
https://github.com/dotnet/sdk/discussions/categories/dotnetup
