Microsoftが2026年10月15日に公開したdotnetupは、.NETの導入と更新を共通のコマンドで管理するツールです。[2] ただし、更新する版の範囲と、既存プロジェクトやアプリが実際に使う.NETは別に決まります。[18, 25, 26]

dotnetupは現在、公開プレビューです。ツールの機能や動作は一般提供までに変わる可能性があります。[3] 公式の導入判断ページは、本番マシンには.NETのインストーラー、パッケージマネージャー、Visual Studioなどの一般提供済みの導入方法を案内しています。[4]dotnetupで安定版SDKを導入できることと、管理ツール自身の提供段階を分けて判断してください。[14]

既存の.NETを残すときは、参照先を先に決める

dotnetupは、SDK・Runtimeと管理情報をユーザ領域に置きます。環境設定を解除しても導入済みのSDKやRuntimeは削除されないため、ファイルの導入先と、それを使うための設定は別です。[5]

環境設定で使うのは、コマンドの探索先を決める PATH と、アプリの起動用実行ファイルが共有Runtimeを探す場所を示す DOTNET_ROOT です。[7] アクセスモードによって、どこへ設定を書き込むかが変わります。[8]

モード管理対象の.NETを使うための設定
none.NET用の環境変数を変更せず、dotnetup dotnet で明示的に呼び出す
shellシェルのプロファイルを変更し、そこから起動するプロセスで管理対象の.NETを使う
everywhereWindows限定。システムの PATH とユーザ単位の DOTNET_ROOT を設定する

既定はWindowsで everywhere、macOS・Linuxでは対応シェルを検出できれば shell、検出できなければ none です。[8] ここで none が変更しないのは、管理対象の.NETを見つけるための設定です。dotnetup自身を PATH へ追加する設定は別にあり、既定ではアクセスモードを問わず追加されます。[9]

Windowsの everywhere を有効・無効にするときは、システムの PATH を変えるため昇格が必要です。[10]

このモードでは、dotnetup側の.NETが、Visual Studioなどによる Program Files のマシン全体インストールより優先されます。必要なSDKやRuntimeがdotnetup側にないと、既存プロジェクトのビルドや、共有Runtimeを使うアプリの起動に失敗する場合があります。[11] システムの PATH は全ユーザに適用されます。既定では導入ユーザのローカルAppData配下のパスが追加されるため、通常の他ユーザのプロセスではこの.NETを解決しないことが多い一方、別ユーザの昇格プロセスから参照される場合があります。[11]

everywhere を選ぶなら、必要な版をdotnetup側にも用意するか、既存環境から移行する選択肢を確認します。既存のシステム設定を優先して残したい場合は、shell や none との使い分けを検討できます。[12]

追跡する範囲を決め、必要な版だけ更新する

dotnetupは、指定した版の範囲や固定バージョンという「導入要求」と、実際に導入した版を分けて記録します。複数の要求が同じ導入済みバージョンを必要とする場合もあります。[13]

「チャネル」は、更新時に追跡する版の範囲です。例えばSDKの指定は次のように異なります。[14]

指定例追跡する範囲
latest最新の安定版SDK。新しいメジャー版も含む
10.0指定したメジャー・マイナーの範囲内のSDK
10.0.103完全な版番号で固定し、自動更新では進めない

dotnetup update は、追跡中の要求ごとに新しい一致版を調べ、必要なものを導入します。更新が成功した後に削除するのは、残っているどの要求にも必要とされなくなった導入物です。別の要求にも必要な版は残ります。[15]

SDKの追跡要求だけを更新するコマンドは dotnetup sdk update です。Runtimeの追跡要求も含める場合は dotnetup update を使います。[16] 管理ツール本体の更新は dotnetup self update で行い、この操作は管理対象のSDK・Runtimeや環境設定、記録済みの導入要求を変更しません。[17]

global.jsonは、導入要求とSDK選択に別々に使われる

リポジトリで使うSDKの版や許容範囲を指定する設定ファイルが global.json です。.NET CLIはこの設定に基づいて、ビルドに使うSDKを選びます。一方、引数なしの dotnetup sdk install は、現在のディレクトリから親へ最寄りの global.json を探し、その設定から導入要求を作ります。SDKを取得する処理と、導入済みSDKを選ぶ処理を区別してください。[18, 19, 20]

次は、公式資料の指定形式を使った仮定例です。[21]

{
  "sdk": {
    "version": "10.0.103",
    "rollForward": "latestPatch"
  }
}

この設定からdotnetupが作る要求は 10.0.1xx です。これは同じ機能更新単位（feature band）内のSDKを追跡する指定です。dotnetup sdk update を行うと、その範囲の新しいSDKを導入できます。--update-global-json を付けなければ、ファイルの version は 10.0.103 のままです。.NET CLIは latestPatch の条件で、同じ機能更新単位の中で、条件を満たす最新の導入済みSDKを選びます。[21]

完全一致が必要なら、rollForward を disable にします。dotnetup側も固定バージョンの要求として扱い、自動更新では進めません。SDKを進めるときは global.json の設定を意図的に変更し、dotnetup sdk install を再実行します。[22] 手編集した設定を導入要求に反映しないまま更新すると、以前の要求を先に処理する場合があるためです。（リポジトリ設定を変更した後の手順）

既存ファイルを使う際は、読み取り処理の差も確認してください。.NET CLIが扱えるコメント付きの global.json でも、現行のdotnetupでは解析に失敗します。[23]

補足：SDK選択設定の細則

SDKの検索先を指定する sdk.paths について、導入先を別途指定しない場合、dotnetupは先頭の値を導入先として使います。CLIで特別な値として扱う $host$ も、dotnetupはパスとして扱います。（dotnetupの設定解析仕様）

allowPrerelease はdotnetupの追跡チャネル導出には影響しませんが、.NET CLIの実際のSDK選択には作用します。[24] 設定値ごとの導出先は、dotnetupのリポジトリ仕様と.NET CLIのglobal.json仕様で確認できます。

SDKの選択は、アプリがどの.NET向けにビルドされるかという設定とは独立しています。アプリの対象を変えるときは、プロジェクトの TargetFramework を更新します。[25]

配布済みアプリの更新は、配布形式ごとに確認する

開発機だけを更新しても、別の配布先や、すでに配布したアプリ内のRuntimeは変わりません。配布形式によって、更新する場所と作業が異なります。[26, 27]

配布形式Runtimeの更新で確認すること
配布先の共有Runtimeを使う形式（framework-dependent）配布先のRuntimeを更新し、起動時の解決方針で許される互換パッチを使う。開発機だけの更新は別の配布先へ反映されない
Runtimeを同梱する形式（self-contained）更新Runtimeを含めてアプリを再発行し、再配布する。共有Runtimeの更新だけでは配布物内のRuntimeは変わらない

共有Runtimeを使う形式では、許容範囲内のパッチ更新を取り込む目的だけなら、通常はアプリ自体の再発行・再配布は不要です。ただし、どのRuntimeを使うかはアプリの解決方針に従います。[26]

導入・設定変更後は、新しいターミナルを開いて、管理対象の導入状態と選択されたSDKを確認してください。公式手順の dotnetup list は管理対象の導入状態、dotnet --version はその環境・ディレクトリで選ばれたSDKの確認に使います。none で管理対象経由のSDKを確認する例は dotnetup dotnet -- --version です。既存プロジェクトのビルドやアプリの起動も確認してから、適用を判断してください。（公式のセットアップ確認）

補足：この記事の確認範囲

Microsoftの公開文書を照合しています。ここでのコマンドや設定例は公式仕様に基づく説明です。