背景與問題
過去要在 macOS 或 Linux 上取得可用的 .NET 開發環境，一直沒有一條統一的路徑。使用者可以選擇系統套件管理員，例如 Debian 系的 apt 或 macOS 的 brew；也可以下載平台專屬的 tarball 壓縮檔手動解壓；或者執行獨立的 shell 腳本 dotnet-install.sh 來安裝。這些方式各有用途，但實際操作時常常碰到幾類共通的麻煩：安裝過程需要管理員權限、檔案散落在系統管理的根目錄裡難以清理，以及要在同一台機器上並存多個執行階段版本時格外彆扭。微軟在 .NET 官方部落格發表了 dotnetup 的公開預覽，由 .NET SDK、MSBuild、範本與安裝腳本團隊的程式經理 Chet Husk 主筆介紹。dotnetup 是新的 .NET 工具鏈管理器，核心定位是把 .NET SDK 與執行階段的安裝、管理與更新，全部放在使用者自己的帳號目錄內完成。
核心設計與安裝流程
熟悉 Rust 生態的 rustup（Rust 官方的工具鏈管理器，負責下載、切換與更新不同版本的編譯器與周邊元件）或 Node 生態的 nvm（Node Version Manager，讓同一台機器並存多個 Node.js 版本並快速切換）的人，對這類專用工具的概念並不陌生。dotnetup 想達到的目標是把建立 .NET 環境所需的概念數量與摩擦大幅降低，具體做法有五項：第一，各平台使用同一套指令與工具，不因為安裝方式不同而有不同的操作體驗；第二，預設非管理員運作，所有檔案放在使用者擁有的資料夾，不需要提權；第三，多個執行階段版本可以並存，包含每月維護版本、預覽通道與每日建置，彼此不會互相覆蓋；第四，追蹤的是使用意圖而不是死板的版本號，使用者鎖定主版本或功能波段（feature band），由工具每月負責更新；第五，尊重專案層級的版本釘選，能與既有的 global.json 配合，讓團隊建置結果保持可預測。
安裝方式是先在終端機執行 bootstrap 腳本，macOS 的 Zsh 使用 curl -fsSL https://aka.ms/dotnetup/get-dotnetup.sh zsh，Linux 的 Bash 把結尾換成 bash，PowerShell 則用 irm 搭配 iex。腳本抓下執行檔之後執行 dotnetup init，這個指令會設定 shell 的設定檔，讓 dotnetup 管理的 dotnet 指令立即在終端機可用，同時抓取最新的穩定版 .NET SDK。之後用 dotnetup list 就能看到 home 資料夾中由它管理的 SDK 與執行階段清單。
版本追蹤與月度更新
.NET 團隊每個月都會發布包含安全性修復與品質改善的維護更新。開發機保持最新，才能針對這些修正建置與測試；對於自我包含（self-contained）的應用程式，還必須用更新後的執行階段重新發佈與部署，因為更新本機環境並不會修補已經上線的應用程式。過去若使用系統層級安裝，是否能及時更新往往不完全由開發者掌控。有了 dotnetup，保持最新只需要一行 dotnetup update：它會重新解析目前追蹤的 SDK 與執行階段通道，安裝符合的最新版本。例如追蹤 10.0 只會在 .NET 10 範圍內更新，追蹤 latest 則跟隨最新的穩定 SDK（包含新主版本）；而明確指定的精確版本會維持釘選，安裝時要求的 10.0.3 不會在更新中被換掉。只想安裝或更新特定執行階段類型時，也可以精準指定，例如 dotnetup runtime install [email protected] 安裝 .NET 10 的 ASP.NET Core 執行階段。更新成功後，dotnetup 會自動移除已經沒有任何需求引用的元件，仍被其他通道或精確版本需求保留的版本則繼續存在；當某個通道不再需要時，用對應的 sdk uninstall 或 runtime uninstall 移除需求，工具會一併清理多餘的安裝。
夜間版與預覽版的測試
除了例行的月度維護更新，許多開發者也希望在正式版發布前就驗證錯誤修正或試用新的執行階段能力。過去測試每日建置（nightly build）的做法，往往是要到 GitHub 尋找原始安裝用 tarball、手動解壓到自訂目錄，再自己修改環境變數，流程繁瑣且容易出錯。dotnetup 把預覽版與每日建置當成正式支援的對象：dotnetup sdk install preview 可以與穩定版並存安裝預覽 SDK；dotnetup runtime install daily 抓取最新的每日執行階段建置，用來確認某個問題是否已修復；dotnetup sdk install daily 則取得整套 SDK 檢視完整工具鏈。這些測試用版本同樣位於使用者帳號內，用完後也容易清理。dotnetup 自身的更新方式是 dotnetup self update。
影響、限制與路線圖
官方在回覆常見疑問時說明了它與既有 dotnet-install 腳本的差異：安裝腳本可以完成大部分安裝動作，但缺少對已安裝 SDK 與執行階段的管理能力、缺少安裝內容的簽章與校驗碼（checksum）驗證、缺少多版本快速安裝的效率，也缺少跨平台一致的單一指令介面。在權限方面，dotnetup 目前完全針對非管理員、使用者本機的運作方式打造，不需要 sudo 或 root，所有 SDK、執行階段與中繼資料都在使用者目錄內；官方也坦言，未來版本才會加入對 Windows 系統層級安裝的管理支援，原因是該作業系統上這類安裝非常普遍。CI 管線則是被明確點名的適用場景，因為它不需要 root 且可以非互動執行，適合容器化或短暫存在的 CI worker 即時準備特定 SDK 或每日執行階段版本。路線圖上除了 Windows 管理員安裝，還包括把 dotnetup 整合進 GitHub Actions 與 Azure DevOps 等 CI/CD 系統，理想情況下取代目前依賴 dotnet-install 腳本的實作部分；另外也會持續依使用者回饋調整體驗，並充實 agent skills，讓自動化助理更自然地預設使用這套工具。在 .NET 部落格的留言區中，官方補充了 dotnetup 為何獨立於 .NET 本身之外：團隊希望提供一個小巧的原生 bootstrapper（引導程式，負責先下載小體積工具、再由它決定要取得哪些元件），讓使用者不必為了起步就下載整份約 200MB 的 SDK 內容，這對嵌入式情境以及 GitHub Actions、Azure DevOps Tasks 這類不適合每次完整下載的場景同樣有用。完整的指令參考、進階設定與深入說明可見 Microsoft Learn 上的 dotnetup 文件，回饋與問題則集中在 GitHub 的 dotnet/sdk discussions。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。