如果你尝试过 Rust，就会知道使用简单的 rustup 命令行工具搭建基本工具链有多么简单。该工具在 Windows、macOS 和 Linux 上均可使用，能构建一致的环境，让你随时打开喜欢的代码编辑器开始工作。

这是一个足够简单的工具，在帮助推广一门新编程语言方面发挥了很大作用。使用 rustup，你清楚自己会得到什么，并且可以在任何地方的任何笔记本电脑上开始工作。

管理 .NET 环境很复杂

.NET 的情况就没那么简单了。是的，它跨平台，可在 Windows、macOS 和 Linux 上运行。然而，它的设置并不容易，通常依赖第三方仓库和安装程序，以及许多安装不同版本及其相关平台的不同脚本。你安装过 ASP.NET Core 吗？你需要 Aspire，还是正在用 MAUI 构建移动应用？所有内容都有自己的自定义安装路径，而且很可能因目标操作系统而异。更麻烦的是，.NET 工具通常需要以所需的最高权限级别运行，要求开发者拥有管理员权限。

这些都对开发者不太友好，也使得很难将 .NET 工具构建到 CI/CD 构建工具和运行器等临时环境中——在这些环境中，你需要为测试和编译填充托管容器，每次启动 GitHub Action 时都要加载新的 .NET CLI 实例，并且必须以远高于自动化流程所需权限的权限来运行工具。当你在同一台开发工作站上维护使用当前 .NET 构建版本的应用程序，同时又要为下一个长期支持版本更新它时，情况会变得更加混乱。

由于存在特定平台的工具链和安装机制，复杂性阻碍了编码，尽管 .NET 具有跨平台特性和成熟度，它却变得不那么优先。显然，是时候采用新的 .NET 安装方式了，使其更易于设置，且不需要用户提升权限（有助于保持系统安全）。

使用 dotnetup 快速上手

这正是 dotnetup 公开预览版发挥作用的地方。顾名思义，dotnetup 相当于 .NET 的 rustup：一条命令即可让你在任何地方开始编码，无论是在 Windows PC、Linux 容器还是 MacBook 上。与 rustup 一样，dotnetup 是一个简单的命令行工具，用于安装 SDK（软件开发工具包） 和运行时以及平台工具。它可配置，因此如果你只需要特定工具，可以只安装它们。dotnetup 支持使用不同版本的 .NET，并使它们彼此隔离，允许你将特定工作区专用于不同的 .NET 版本。它允许你针对特定版本进行开发，而不影响用于在 PC 上运行 .NET 应用程序的全局、机器范围的运行时。

作为命令行工具，dotnetup 无论在哪里运行，外观和行为都相同。安装很简单，在 macOS 和 Linux 上使用 curl 和默认 shell，在 Windows 上使用 PowerShell 工具。安装脚本不会设置 CLI 二进制的路径，因此你需要复制并运行安装完成时输出的两行设置脚本。这会安装当前签名的构建版本，不过如果你想试验新功能，也可以使用另一组脚本安装当前的每夜构建版本。

在任何需要的地方获得相同的 .NET 环境

我在三个不同的系统上安装了 dotnetup：一台 Windows PC、一台 MacBook Neo 和一台运行 Ubuntu 的 PC。三次安装都很顺利，当我运行 dotnetup init 命令时，该工具显示了 SDK 和运行时将安装的位置。需要注意的是，这些位置位于用户自己的个人目录中，SDK 和运行时安装在当前用户上下文中。建议避免使用提升的账户权限。微软正在开发更新版本的 dotnetup，以便在 Windows 上实现这一点。

我发现不同操作系统安装了不同版本的 .NET SDK。Windows 安装了 .NET 9 和 .NET 10 的 SDK，以及熟悉的 .NET 运行时、Windows 桌面运行时和 ASP.NET。macOS 只安装了 .NET 10 SDK，Linux 也是如此。我无法在 Mac 上安装 ASP.NET，即使明确尝试加载也不行。

虽然直接接受默认设置最为简单，但 dotnetup 提供了一种交互模式，可提供管理已安装 .NET 版本及其运行环境、以及清理不需要或过时版本的选项。你可以使用交互模式选择 .NET 通道，例如最新版或长期支持版本，或特定版本。在后一种情况下，你可以选择主要或次要版本，并可选择功能带（例如 10.0.1xx 系列版本）或特定 SDK。

这种方法让你能够将开发环境调整到各种不同的 .NET 安装，当组织为其所有 PC 使用锁定镜像时，这非常有用，可让你构建面向该特定构建的应用程序。

设置 SDK 和运行时

安装了多个 .NET 版本后，你需要能够针对特定 SDK 进行测试。Windows 用户默认运行在“everywhere”模式下，该模式为 PC 设置默认的 PATH 和 DOTNET_ROOT 环境变量。设置 .NET 环境的其他选项包括“none”，此时需要直接从 dotnetup CLI 调用 .NET 运行时，以及“shell”，它将环境变量绑定到当前 shell。后两个选项是 Linux 和 macOS 安装中唯一可用的选项。

dotnetup 工作原理的关键是安装根（installation roots）的概念。每个根是一个目录，具有定义的架构（可能是 x64 或 Arm64），并带有一组定义安装内容的安装通道。默认位于其自己的数据目录中，不过你可以定义自己的特定安装路径，例如为 .NET 9 和 .NET 10 使用单独的根。但是，你不能使用系统级 .NET 目录来将开发环境与桌面使用的环境分开。

一个有用的功能是将现有 .NET 环境迁移到由 dotnetup 管理的环境。如果你一直使用单个 .NET SDK，这将使你能够控制开发环境，并开始将 SDK 和运行时与特定目录和项目关联起来。

在 CI/CD 管道中使用 dotnetup

像 dotnetup 这样的工具真正发挥作用的地方是作为持续集成平台的一部分。dotnetup 设计为完全自动化。它不需要终端，在管道中运行时，它会禁用首次使用引导功能。通过将 dotnetup 构建到脚本中并确保其不以交互方式运行，你可以安装特定 .NET 版本用于构建或测试，定义本地环境。Microsoft 提供了示例 YAML，用于将 dotnetup 构建到 GitHub Action 中，首先安装工具，然后使用它安装 SDK 并构建和运行测试套件。

如果你使用由 dotnetup 管理的运行时，可以在熟悉的 dotnet CLI 旁使用 dotnetup 命令来管理操作，只需在 dotnet 命令字符串前加上 dotnetup 即可。这种方法在 GitHub Actions 等受限环境中效果很好。

良好的第一步，但接下来呢？

作为预览版，dotnetup 是一个有趣的工具，它解决了许多 .NET 开发者的痛点。然而，仍有一些缺失的元素，特别是在对更多 .NET 运行时和扩展的支持方面。能够设置例如 Aspire 环境，或用于开发 .NET WebAssembly 应用程序的环境，那将很不错。随着 .NET 覆盖范围的扩大，管理多个工具链和运行时的需求变得至关重要，dotnetup 需要支持这些——无论是直接支持，还是通过扩展机制，允许你将自己的仓库选择添加到其 global.json 配置文件中。

即便如此，这里仍有很多值得称道之处。工具易于使用，初始功能集足以让你上手。虽然能看到与 Visual Studio Code 等工具的集成，让你能随项目切换 .NET 运行时和 SDK 会更好，但这类功能需要等到首个版本发布之后。希望这一天不会太远！

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：InfoWorld

原创地址：https://www.infoworld.com/article/4241187/simplifying-net-toolchain-installs-with-dotnetup.html