目录

为了修复生产环境中的 bug，你打开了一个旧的 .NET 项目。另一个项目需要较新的 SDK，还有一个项目正在试用预览版。在修改代码之前，你必须先确认各个项目会使用哪个 SDK，以及安装其他版本是否会影响现有环境。

据所提供的 Publickey 于 2026 年 10 月 19 日发布的报道，Microsoft 为解决这一问题，推出了 .NET 工具链管理器 dotnetup 的公共预览版。

dotnetup 是一款用于在同一台机器上安装和管理多个 .NET 工具链的工具。它在 Windows、macOS 和 Linux 上提供一致的命令行操作方式，无需管理员权限即可安装到用户目录中，也支持用于控制 SDK 选择的现有 global.json 配置。

对于需要处理多个不同要求项目的开发者来说，真正有用的变化在于持续管理：维护所需环境、选择合适的 SDK，并在预期的发布系列内进行更新。

在同一台机器上处理多个要求不同的项目#

假设一位开发者需要处理四个代码仓库。

  • 必须继续使用已获批准的 SDK 的生产应用。
  • 可以接受在所选发布系列内更新的服务。
  • 需要在多个 .NET 环境下测试的共享库。
  • 使用预览版构建的实验性应用。

仅安装最新的 SDK，无法满足这四种需求。生产应用需要可预测的构建结果，服务需要维护更新，共享库需要兼容性测试，而实验性应用则需要能够使用开发中软件的环境，同时避免其他项目误用这些版本。

.NET 早已支持多个 SDK 并存安装。问题在于，开发者能否轻松维护这些 SDK，并清楚掌握项目会使用哪个 SDK。

在此次预览中，Microsoft 将 dotnetup 定位为专门处理这些工作的管理工具。Publickey 将其作用类比为 Rust 的 rustup 和 Node.js 的版本管理工具 nvm。这些工具让安装不再是一次性的固定选择，而是允许用户持续维护多个版本。

这一比较旨在说明其用途，并不意味着 dotnetup 的命令、选择规则和功能与这些工具完全相同。

dotnetup 预览版提供的功能#

所提供的文章介绍了几项可能简化日常 .NET 环境管理的功能。

在不同操作系统上采用相同的操作方式#

dotnetup 致力于在 Windows、macOS 和 Linux 上提供相同的命令和工具。

对于使用不同操作系统的团队，这可能减少需要为各个系统单独编写的配置步骤。如果基本的安装和管理流程一致，统一的开发指南也会更容易使用。

不过，这也有局限。命令行界面一致，并不意味着操作系统可以随意替换。原生依赖、平台专属工作负载和应用行为，仍需分别确认。

无需管理员权限即可安装#

据文章介绍，dotnetup 将所管理的环境保存在用户目录中，而非系统文件夹中。因此，安装时无需提升至管理员权限。

这对使用组织统一管理设备、无法自由修改系统软件的开发者很有帮助。开发者也能维护自己的工具链，而不必在每次安装时修改整台机器的环境。

不过，公司内部政策仍然适用。即使安装不需要管理员权限，组织也可能限制可执行文件的下载，或要求使用经过批准的分发来源。

支持包括预览版在内的多个版本#

此次预览版支持并存安装和管理多个版本及构建，包括预览版。

这样，开发者就能在保留现有项目所需 SDK 的同时，更轻松地评估下一版本。需要重点确认的是：安装其他版本后，各个仓库是否仍会选择预期的 SDK。

即使多个版本能够正常并存安装，也可能选中非预期的版本。因此，对版本选择应给予与安装同等的重视。

在所选发布系列内更新#

文章还介绍了跟踪主版本或发布通道，并按所选范围进行更新的功能。

这回应了团队反复面临的一项维护需求：在避免意外升级到其他主版本的同时，获取 bug 修复和安全更新。

不过，应将其理解为更新管理功能，而不能据此认为补丁会在无人干预的情况下自动应用。从所提供的资料中，无法确认更新是否自动执行、由什么触发，以及跟踪设置与项目配置之间具体如何关联。

团队在依赖这项功能制定维护策略之前，需要查阅预览版文档，确认详细行为。

为什么支持 global.json 很重要#

对于现有团队而言，dotnetup 对 global.json 的支持，或许是兼容性方面最实用的功能。

在 .NET 项目中，可以通过 global.json 指定 SDK 选择要求，例如版本和向前滚动（roll-forward）行为。将这项配置纳入仓库管理后，所有参与代码开发的人都能了解预期的开发环境。

这里需要区分 SDK 与运行时。global.json 控制的是 SDK 选择，仅靠它并不能定义待部署应用的全部运行时要求。

因此，评估 dotnetup 的团队需要分别确认以下两点。

1. 开发者执行 .NET 命令时，仓库是否会按预期选择 SDK。 2. 构建后的应用能否在目标部署环境中正常运行。

满足第一点，并不意味着一定满足第二点。

由于支持现有的 global.json，团队应该不必仅仅为了试用新的安装管理工具，就放弃仓库原有的配置。即便如此，仍应在实际项目中验证兼容性。尤其是在向前滚动配置可能使多个已安装 SDK 都成为候选项时，更需要留意。

与 dotnet-install 的区别#

Microsoft 已经提供了 dotnet-install，因此新的安装工具需要有明确的用途。

Publickey 将 dotnetup 描述为与现有工具相似、但更侧重于持续管理多个版本的工具。这才是实际使用中的区别。如果让人以为在 dotnetup 出现之前无法让多个 .NET 版本并存，就会造成误解。

安装脚本有助于将 SDK 或运行时放到指定位置。工具链管理器则旨在简化安装之后持续发生的工作：维护多个安装环境、跟踪发布系列，并满足各个项目的版本要求。

对于只安装一个 SDK、也很少切换项目的开发者，这种区别的价值可能有限。而对于维护多个发布系列或定期测试预览版的开发者，它则可能减少反复进行的环境配置工作。

如果团队已有运行稳定的安装脚本，就应权衡管理上的收益与改变现有工作流程的成本。公共预览版的发布提供了一个试用机会，并不意味着必须迁移。

在实际项目中评估的五个步骤#

有价值的试用，应当能够确认 dotnetup 是否让现有工作的结果更可预测。请先从一台即使预览工具出现问题也不会造成影响的开发机器开始。

1. 记录当前环境#

安装任何内容之前，先记录当前可用的 SDK 和运行时。在两个有代表性的仓库中执行 dotnet --version，记下所选的 SDK。

同时确认这些版本是如何安装的：通过操作系统包管理器、Visual Studio、安装脚本，还是其他方式？这些信息有助于在之后选中非预期 SDK 时理解原因。

2. 确认项目要求#

选择两个 SDK 要求不同的仓库。检查各自的 global.json，包括向前滚动配置。

对于没有显式 SDK 配置的仓库，需要判断这是否符合预期。如果团队对开发者应该使用哪个 SDK 的要求仍不明确，增加工具链管理器也无法解决这个问题。

3. 按照 Microsoft 官方说明安装 dotnetup#

遵循适用于所用操作系统的最新预览版文档。在执行安装命令之前，请确认下载来源。

所提供的文章不包含安装命令，因此复制使用猜测出来的命令语法，会增加本可避免的风险。请确认引入该工具后，命令的查找与解析方式会发生什么变化，以及是否需要开启新的终端会话。

4. 在两个仓库中测试 SDK 选择和构建#

按照文档中的 dotnetup 操作步骤，安装所需环境。回到各个仓库，再次确认所选的 SDK。

随后构建项目并运行现有测试。确认添加第二个 SDK 或预览版 SDK 后，第一个仓库的行为没有改变。

这是本次评估的核心验收测试：两个项目都必须能够继续按预期配置使用。

5. 单独评估更新#

确认基本安装和 SDK 选择正常工作后，再试用发布跟踪功能。

检查更新会改变哪些内容、更新后所选的 SDK 是否发生变化，以及如何恢复到之前正常工作的环境。记录结果，以便其他开发者复现相同步骤。

当前预览版尚未验证的范围#

据 Publickey 报道，Microsoft 计划今后推进 Windows 系统级管理、CI/CD 集成和用户体验改进。

这些属于路线图中的项目，不应被视为当前预览版已经完成的功能。

CI 尤其需要注意。在开发者用户目录中搭建的环境，并不会自然成为可复现的构建代理配置。修改流水线之前，请对照实际的预览版文档，确认非交互式安装、版本选择、缓存行为和失败处理方式。

也没有必要一次性替换所有现有安装方式。由 Visual Studio 管理的环境或成熟的构建镜像，可能与开发者个人的命令行环境有不同要求。

从两个仓库开始#

dotnetup 最值得期待的实际价值，在于同一台机器上的多个项目需要不同 .NET 环境时，能够减少手动操作。

如果团队已经在 SDK 安装、预览版测试和发布系列维护上投入了不少时间，那么公共预览版就值得评估。需要确认的事项很明确：能否选中正确的 SDK、构建是否成功，以及更新行为是否清晰可理解。

选择两个要求不同的仓库，记录当前所选的 SDK，然后遵循 Microsoft 的 dotnetup 预览版官方说明。确认两个项目仍能使用预期版本构建后，再扩大使用范围。

来源: https://www.publickey1.jp/blog/26/netdotnetupnet.html

目录