.NET 開發環境長期存在一個結構性的不便：SDK 與執行階段通常安裝在系統層級的共用目錄，例如 Windows 的 Program Files\dotnet 或 Linux 的 /usr/share/dotnet。對只維護單一版本、單一專案的人來說，這樣的安排問題不大；但當開發者同時處理多個專案、需要並存多個 .NET 版本，或是在沒有系統管理權限的機器上工作時，版本切換、清理與隔離就變得相當棘手。根據 InfoQ 報導，微軟在 2026 年 10 月 15 日由 .NET SDK 專案經理 Chet Husk 於 .NET Blog 宣布 dotnetup 公開預覽版，正是針對這個痛點提出的跨平台工具鏈管理器。它的定位參考了 Rust 生態的 rustup 與 Node.js 的 nvm，但關鍵差異在於把 SDK 與執行階段安裝在使用者帳戶之下，而不是交由系統統一管理。
背景：SDK 安裝位置的長期痛點
傳統上，.NET 的安裝程式與套件管理器會把檔案寫入全機器共用的位置，所有使用者看到的都是同一份 SDK。這樣做的好處是管理單純，缺點則是版本衝突難以避免：某個專案需要舊版 SDK，另一個專案需要新版，開發者往往只能手動調整 PATH，或是在機器上堆疊多份安裝。dotnetup 選擇把檔案放在使用者本地資料目錄，Windows、macOS 與 Linux 皆然，並且明確承諾不會寫入 Program Files\dotnet 或 /usr/share/dotnet。這種「使用者範圍」的設計，讓不同開發者能在同一台機器上擁有各自的工具鏈，也讓清理與升級不再牽動整個系統。
核心設計：追蹤意圖而非版本
dotnetup 最關鍵的概念，是讓開發者表達「想要什麼」而不是「指定哪一版」。使用者可以提出一個 channel，例如 latest、lts、preview、daily，或是指定主版本如 10、次版本如 10.0，甚至是 feature band 如 10.0.1xx。dotnetup 會把這些意圖解析成實際可安裝的發行版。這樣做的好處是，當開發者表達「我要最新的 LTS」時，後續更新就能自動選擇符合條件的新版本；相對地，若指定的是確切版本，更新時就會維持鎖定。多個需求可以共用同一個受管理的安裝，工具也會讀取最近的 global.json，讓團隊建置維持確定性，不至於因為個人環境差異而產生不同結果。
運作方式：安裝、存取模式與更新
安裝流程透過從 aka.ms 取得的 bootstrap script 進行，使用 curl 或 irm 下載，先驗證 SHA-512 checksum，再把執行檔放到使用者家目錄下的 ~/.dotnetup；接著以 dotnetup init 安裝最新穩定版 SDK 並設定 shell。存取模式分為三種。none 模式讓 .NET 只透過 dotnetup dotnet 執行，完全不改動環境；shell 模式會編輯 shell profile；everywhere 模式是 Windows 上的預設值，會修改系統 PATH，因此需要提權。文件中特別提醒，everywhere 模式會優先於機器全域的副本，包括 Visual Studio 所安裝的那一份，這意味著如果某個專案需要的 SDK 沒有被 dotnetup 安裝，建置就會失敗。為了降低這類衝突，設定過程據稱會提供遷移既有機器全域安裝的選項。
在日常維護上，每月服務更新可以簡化為一次 dotnetup update，它會重新解析所有追蹤中的 channel，安裝最新的匹配版本。更新完成後，dotnetup 會移除不再被任何需求引用的元件，sdk uninstall 與 runtime uninstall 也會觸發同樣的清理。開發者也能針對個別執行階段操作，例如 dotnetup runtime install [email protected]；支援的元件包括 SDK、.NET runtime、ASP.NET Core runtime 與 Windows Desktop runtime。預覽版與 daily 版本可以並存安裝，指令分別是 dotnetup sdk install preview 與 dotnetup runtime install daily，不過文件註明 daily 版本沒有程式碼簽章。工具本身則由 dotnetup self update 更新。
技術脈絡：與既有工具的差異
與既有的 dotnet-install 腳本相比，微軟在公告中強調幾個改進：追蹤已安裝元件、簽章與 checksum 驗證、更快的多版本安裝，以及每個平台一致的 CLI 介面。這些特性讓 dotnetup 更接近一個完整的套件管理器，而不只是一次性的安裝腳本。路線圖還列出三項後續工作：Windows 上的管理員層級安裝、取代 GitHub Actions 與 Azure DevOps 任務中以腳本實作的部分，以及讓 AI 助理預設採用此工具的 agent skills。這顯示微軟不只把它當成開發者本機的輔助工具，也打算納入 CI 與自動化流程。
影響與限制：預覽階段的現實
dotnetup 目前仍是預覽版，文件明確指出各預覽版本之間指令與行為可能改變，生產機器應繼續使用安裝程式、套件管理器或 Visual Studio。社群反應也呈現兩面。在 r/dotnet 上，有使用數個月的開發者肯定它在 Linux 上的設定比以往簡單；但熱門留言質疑，既然已有 mise 這類工具，為何還要選 dotnetup。其他批評集中在以 curl 管線執行 shell 的 bootstrap 方式，有人要求提供 winget、apt 或 Homebrew 套件，也有人指出 Visual Studio 看不到 dotnetup 的安裝，並希望 dotnet-ef 等 CLI 工具也能納入管理。Husk 在部落格回覆表示，套件形式會在使用者驗證之後規劃推出。
對長期受版本切換所苦的 .NET 團隊而言，dotnetup 提供了一個以意圖為中心的新選項，把「我要哪個版本」轉化為「我要哪種版本條件」，再由工具負責解析與清理。不過，它與 Visual Studio、系統層級安裝及既有套件生態的整合程度，仍是預覽階段最需要觀察的限制。完整文件、命令參考與 telemetry 細節公布在 Microsoft Learn，回饋管道則是 dotnet/sdk GitHub discussions 的 dotnetup 分類。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。