目次

本番環境のバグを修正するため、古い.NETプロジェクトを開きます。別のプロジェクトには新しいSDKが必要で、さらに別のプロジェクトではプレビューリリースを試しています。コードを変更する前に、各プロジェクトでどのSDKが使われるのか、別のバージョンをインストールすると既存の環境に影響するのかを確認しなければなりません。

提示されたPublickeyの2026年10月19日付の報道によると、Microsoftはこの問題に対処するため、.NETツールチェーンマネージャーのdotnetupをパブリックプレビューとして公開しました。

dotnetupは、1台のマシンに複数の.NETツールチェーンをインストールし、管理するためのツールです。Windows、macOS、Linuxで一貫したコマンドライン操作を提供します。管理者権限を必要とせず、ユーザーディレクトリにインストールでき、SDKの選択を制御する既存のglobal.json設定にも対応しています。

要件の異なる複数のプロジェクトを扱う開発者にとって、有用な変化は継続的な管理にあります。必要な環境を維持し、適切なSDKを選択し、意図したリリース系列内で更新できることです。

1台のマシンで、要件の異なる複数のプロジェクトを扱う#

4つのリポジトリを扱う開発者を考えてみましょう。

  • 承認済みのSDKを使い続ける必要がある本番アプリケーション。
  • 選択したリリース系列内での更新を受け入れられるサービス。
  • 複数の.NET環境でテストする共有ライブラリ。
  • プレビュービルドを使う実験的なアプリケーション。

最新のSDKをインストールするだけでは、この4つの要件すべてを満たせません。本番アプリケーションには予測可能なビルドが必要です。サービスには保守更新が必要です。ライブラリには互換性テストが必要で、実験用アプリケーションには、ほかのプロジェクトが誤って採用しない形で開発中のソフトウェアを利用できる環境が必要です。

.NETはすでに、複数のSDKを共存させるインストールに対応しています。問題は、開発者がそれらをどれだけ手軽に維持し、プロジェクトでどのSDKが使われるかを把握できるかです。

Microsoftは今回のプレビューで、dotnetupをこうした作業に特化した管理ツールとして位置付けています。Publickeyは、その役割をRustのrustupやNode.jsのバージョン管理ツールnvmになぞらえています。これらは、インストールを一度きりの固定的な選択とするのではなく、複数のバージョンを維持できるようにするツールです。

この比較は目的を説明するものです。dotnetupのコマンド、選択ルール、機能が、それらと同一であることを示すものではありません。

dotnetupのプレビューで提供される機能#

提示された記事では、日々の.NET環境管理を容易にし得る機能がいくつか紹介されています。

OSを問わず同じ方法で操作#

dotnetupは、Windows、macOS、Linuxで同じコマンドとツールを提供することを目指しています。

異なるOSを使うチームでは、OSごとに用意するセットアップ手順を減らせる可能性があります。基本的なインストールと管理の流れが共通であれば、共通の開発ガイドも使いやすくなります。

ただし、これには限界があります。コマンドラインインターフェースが共通でも、OSを自由に置き換えられるわけではありません。ネイティブ依存関係、プラットフォーム固有のワークロード、アプリケーションの動作は、引き続き個別に確認する必要があります。

管理者権限なしでインストール#

記事によると、dotnetupは管理対象の環境をシステムフォルダーではなく、ユーザーのディレクトリに保存します。そのため、インストール時に管理者権限への昇格は必要ありません。

これは、開発者がシステムソフトウェアを自由に変更できない、組織管理下の端末で役立ちます。また、インストールのたびにマシン全体を変更することなく、自分用のツールチェーンを維持できます。

ただし、社内ポリシーは引き続き適用されます。管理者権限が不要なインストールでも、組織によっては実行ファイルのダウンロードを制限したり、承認済みの配布元を使うよう求めたりする場合があります。

プレビューを含む複数バージョンに対応#

今回のプレビューでは、プレビューリリースを含む複数のバージョンやビルドを、共存させてインストール・管理できます。

これにより、既存のプロジェクトに必要なSDKを残しながら、次期リリースを評価しやすくなります。確認すべき重要な点は、別のバージョンをインストールした後も、各リポジトリで意図したSDKが選択され続けるかどうかです。

インストール自体は問題なく共存できても、想定外のバージョンが選択されることはあり得ます。バージョンの選択には、インストールと同じくらい注意を払う必要があります。

選択したリリース系列内での更新#

記事では、メジャーバージョンやリリースチャネルを追跡し、その選択に沿って更新する機能も紹介されています。

これは、意図せず別のメジャーリリースへ移行することなく、バグ修正やセキュリティ更新を取り込みたいという、チームが繰り返し直面する保守上の課題に応えるものです。

ただし、これは更新管理の機能として捉えるべきであり、無人でパッチが適用されることを示すものではありません。提示された資料からは、更新が自動的に行われるのか、何を契機に実行されるのか、追跡設定とプロジェクト設定が具体的にどう関係するのかは確認できません。

チームがこの機能を前提に保守方針を策定する前に、プレビューのドキュメントで詳細を確認する必要があります。

global.jsonへの対応が重要な理由#

既存のチームにとって、dotnetupのglobal.json対応は、互換性の面で最も有用な機能かもしれません。

.NETプロジェクトでは、global.jsonでバージョンやロールフォワードの動作など、SDK選択の要件を指定できます。この設定をリポジトリで管理すれば、コードに携わる全員が、想定される開発環境を確認できます。

ここでは、SDKとランタイムの違いが重要です。global.jsonが制御するのはSDKの選択であり、それだけでデプロイするアプリケーションのランタイム要件すべてが定義されるわけではありません。

そのため、dotnetupを評価するチームは、次の2点を分けて確認する必要があります。

1. 開発者が.NETコマンドを実行したとき、リポジトリで想定どおりのSDKが選択されるか。 2. ビルドしたアプリケーションが、想定するデプロイ環境で正しく動作するか。

1つ目を満たしても、2つ目を満たすとは限りません。

既存のglobal.jsonに対応しているため、新しいインストール管理ツールを試すだけのために、リポジトリの設定を捨てる必要もないはずです。それでも、互換性は実際のプロジェクトで確認すべきです。特に、ロールフォワード設定によって、インストール済みの複数のSDKが選択候補になり得る場合は注意が必要です。

dotnet-installとの違い#

Microsoftはすでにdotnet-installを提供しているため、新たなインストールツールには明確な目的が必要です。

Publickeyは、dotnetupを既存のツールに似ているものの、複数バージョンの継続的な管理により重点を置いたツールとして説明しています。ここが実用上の違いです。dotnetup以前には複数の.NETを共存させられなかったかのように説明するのは、誤解を招きます。

インストールスクリプトは、SDKやランタイムを指定した場所に配置するのに役立ちます。ツールチェーンマネージャーが目指すのは、その後も続く作業を容易にすることです。複数のインストール環境を維持し、リリース系列を追跡し、プロジェクトごとのバージョン要件に対応します。

SDKを1つだけインストールし、プロジェクトを切り替えることもほとんどない開発者にとって、この違いの価値は限られるかもしれません。一方、複数のリリース系列を保守したり、定期的にプレビューをテストしたりする開発者なら、繰り返し発生するセットアップ作業を減らせる可能性があります。

安定して運用できているインストールスクリプトがあるチームは、管理上の利点と、現在のワークフローを変更するコストを比較すべきです。パブリックプレビューの公開は、試すきっかけであって、移行を義務付けるものではありません。

実際のプロジェクトで評価する5つの手順#

有用な試用とは、dotnetupによって既存の作業の予測可能性が高まるかを確認できるものです。プレビューツールで問題が起きても支障のない開発マシンから始めましょう。

1. 現在の環境を記録する#

何かをインストールする前に、すでに利用可能なSDKとランタイムを記録します。代表的な2つのリポジトリでdotnet --versionを実行し、選択されたSDKを控えておきます。

それらがどのようにインストールされたかも確認します。OSのパッケージマネージャー、Visual Studio、インストールスクリプト、それ以外の方法のいずれでしょうか。この情報は、後で想定外のSDKが選択された際に、原因を理解する手掛かりになります。

2. プロジェクトの要件を確認する#

SDKの要件が異なる2つのリポジトリを選びます。ロールフォワード設定も含め、それぞれのglobal.jsonを確認します。

SDKの明示的な設定がないリポジトリでは、それが意図した状態かどうかを判断します。開発者がどのSDKを使うべきかというチームの方針が曖昧なままでは、ツールチェーンマネージャーを追加しても解決にはなりません。

3. Microsoftの公式手順に従ってdotnetupをインストールする#

使用するOS向けの最新のプレビュードキュメントに従います。インストールコマンドを実行する前に、ダウンロード元を確認してください。

提示された記事にはインストールコマンドが含まれていないため、推測した構文をコピーして使うと、避けられるリスクを増やすことになります。ツールの導入によってコマンドの検索・解決方法がどう変わるのか、新しいターミナルセッションが必要かどうかを確認します。

4. 両方のリポジトリでSDKの選択とビルドをテストする#

ドキュメントに記載されたdotnetupの手順で、必要な環境をインストールします。それぞれのリポジトリに戻り、選択されるSDKをもう一度確認します。

続いて、プロジェクトをビルドし、既存のテストを実行します。2つ目のSDKやプレビューSDKを追加しても、最初のリポジトリの動作が変わっていないことを確認します。

これが評価の中心となる受け入れテストです。両方のプロジェクトが、意図した設定で引き続き利用できなければなりません。

5. 更新は別途評価する#

リリース追跡機能を試すのは、基本的なインストールとSDKの選択が機能することを確認してからにします。

更新によって何が変わるのか、更新後に選択されるSDKが変わるのか、以前の正常な環境にどう戻せるのかを確認します。ほかの開発者が同じ手順を再現できるよう、結果を記録します。

現在のプレビューで実証されていない範囲#

Publickeyによると、Microsoftは今後、Windowsのシステムレベルでの管理、CI/CDとの統合、ユーザー体験の改善に取り組む予定です。

これらはロードマップ上の項目です。現在のプレビューですでに完成している機能として扱うべきではありません。

CIには特に注意が必要です。開発者のユーザーディレクトリ内に構築した環境が、そのまま再現可能なビルドエージェントの構成になるわけではありません。パイプラインを変更する前に、非対話型インストール、バージョン選択、キャッシュの動作、失敗時の処理を、実際のプレビュードキュメントに照らして確認してください。

既存のインストール方法をすべて一度に置き換える必要もありません。Visual Studioで管理する環境や、確立されたビルドイメージには、開発者個人のコマンドライン環境とは異なる要件がある場合があります。

2つのリポジトリから始める#

dotnetupに最も期待できるのは、同じマシン上で複数のプロジェクトが異なる.NET環境を必要とするときに、手作業を減らせるという実用的な利点です。

SDKのインストール、プレビューのテスト、リリース系列の保守にすでにチームの時間が費やされているなら、パブリックプレビューを評価する価値があります。確認すべき点は明快です。正しいSDKが選択されること、ビルドが成功すること、更新の動作を理解できることです。

要件の異なる2つのリポジトリを選び、現在選択されるSDKを記録し、Microsoftのdotnetupプレビューの公式手順に従ってください。両方のプロジェクトが意図したバージョンで引き続きビルドできることを確認してから、導入範囲を広げましょう。

出典: https://www.publickey1.jp/blog/26/netdotnetupnet.html

目次