Visual Studio 2022で.NET 9が出ない原因と対処|SDK・global.json・.NET 10との違い

Visual Studio 2022で.NET 9.0が選べない場合は、IDEの対応バージョン、使用中のSDK、プロジェクト形式を順に確認します。net9.0を対象とする公式条件はVisual Studio 17.12以降です。SDKの9.0.xが表示されても、古いIDEやSDK固定設定のままなら同じ結果にはなりません。

目次

.NET 9が出ないときの最初の確認

SDKをインストールできることと、Visual Studioでその.NETをターゲットとして正式に使えることは別です。

状態確認する場所・対応
Visual Studio 2022が17.12より古いIDEを対応版へ更新。組織配布では更新チャネルと配布レイアウトを管理者に確認する。
dotnet –list-sdksに対応SDKがないランタイムだけでなく開発用SDKを導入する。Visual Studioの必要ワークロードも確認する。
SDKはあるがこのソリューションだけ失敗ソリューションと上位フォルダーのglobal.json、プロジェクトのTargetFrameworkを確認する。
.NET Framework用テンプレートで探している.NET 9と.NET Frameworkは別。プロジェクト形式と移行が必要か確認する。
「.NET 10.0をサポートしていません」と表示net10.0はVisual Studio 18.0以降が対象。VS 2022にSDKだけを足して解決と扱わない。

Visual StudioとSDKの対応を確認する

Microsoftの公式対応表は、net9.0を17.12以降、net10.0を18.0以降で正式にサポートすると説明しています。SDKのfeature bandによって、IDEの同梱版や読み込み可能な最低版も異なります。

代表的なSDK同梱されるVisual StudioSDKが読み込める最低IDEと対象の注意
9.0.10017.1217.11でも読み込み可能だが、その最低IDEの最大TFMはnet8.0。net9.0開発の条件と違う。
9.0.200 / 9.0.30017.13 / 17.14最低17.12、最大TFMはnet9.0。
10.0.10018.017.14でも読み込み可能だが、その最低IDEの最大TFMはnet9.0。

バージョン番号は「ヘルプ → Microsoft Visual Studioのバージョン情報」で控えます。更新はVisual Studio Installerから行い、特定の古い17.12ビルドへの固定を解決策にしません。基本は使用するIDEに同梱されるSDKと、現在サポートされる更新を組み合わせます。

SDK・ランタイム・選択中のSDKを分ける

ソリューションのフォルダーへ移動して、次を確認します。コマンドは環境の確認用です。PowerShellではwhereという別名との混同を避け、where.exeを使います。

where.exe dotnet
dotnet --info
dotnet --list-sdks
dotnet --list-runtimes
dotnet --version
コマンド分かること
–list-sdksそのdotnetホストから見えるインストール済みSDKの一覧。
–list-runtimesアプリ実行用ランタイムの一覧。SDKの導入確認とは別。
–version現在の作業フォルダーの設定で選択されるSDK。
–info / where.exe dotnetアーキテクチャ、環境情報、解決される実行ファイルのパス。

古い9.0.100や9.0.0を表示できることだけで「現在の更新が完了」と判断しません。必要なSDKが一覧にあっても–versionが別の値になる場合は、固定設定と探索起点を先に確認します。

global.jsonは上位フォルダーまで確認する

global.jsonはSDKの選択を制御し、プロジェクトが対象とするランタイムの指定とは別です。CLIは作業フォルダー、MSBuildのSDK resolverはソリューションやプロジェクトの場所を起点として親フォルダーへ探索するため、両者の起点もそろえてください。

ファイルを見つけたら、現在の指定を保管し、CIやチームの固定意図を確認してから変更します。versionは完全な番号が必要で、9.0.xというワイルドカードは使えません。次は9.0.300以上の9.0内のfeature band・patchを許し、プレビューを使わない例です。必要なSDKを別途導入したうえで使います。

{
  "sdk": {
    "version": "9.0.300",
    "rollForward": "latestFeature",
    "allowPrerelease": false
  }
}

latestFeatureは同じmajor/minor内、latestMinorは同じmajor内の許容です。変更後は同じフォルダーでdotnet –versionを確認します。allowPrereleaseをtrueにしただけでGA版を拒否する設定にはならないため、元の指定を「不要」と決めつけて削除しません。プレビューを含めない方針ならfalseを明示します。

PATHとアーキテクチャの確認

Windowsへの.NET導入資料に従い、実行中のdotnetのアーキテクチャとSDKを照合します。x64のPCでx86のdotnetが先に解決されている場合は、適切なx64の実行ファイルが優先されるようPATHを確認します。SDK内の特定バージョンのフォルダーをPATHへ追加する方法は避けます。

Arm64 WindowsではArm64版がC:\Program Files\dotnet、x64版がC:\Program Files\dotnet\x64に配置されます。全端末を「x64必須」と一律に扱わず、使用しているIDE・実行ホストに合う構成で確認してください。設定を変えたらターミナルとIDEを開き直して比較します。

プロジェクト形式とTFMの確認

TFMの公式資料では、.NET 9はnet9.0、Windows APIを使う対象はnet9.0-windows等を指定します。.NET Frameworkのnet48/net481とは別のターゲットです。新規作成で「.NET Framework」用テンプレートを選んでいないか確認します。

用途代表的なTFM
コンソール・ライブラリ・ASP.NET Corenet9.0
WPF / Windows Formsnet9.0-windows
MAUIのプラットフォーム対象net9.0-android / net9.0-ios / net9.0-maccatalyst等。ワークロードとそのサポート期限も別途確認。

SDK形式のコンソールプロジェクトの最小例です。実際の移行では既存プロジェクトの参照、パッケージ、プロパティを残して比較します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
</Project>

WPFならnet9.0-windowsとUseWPF、Windows Formsならnet9.0-windowsとUseWindowsFormsを使い、用途に応じた.NETデスクトップ開発等のワークロードをInstallerで確認します。両者を全プロジェクトへ一括で追加する手順ではありません。

.NET Frameworkからの移行では、アプリモデル、プロジェクト形式、利用APIの違いと依存関係の確認が必要です。「ソリューションの再ターゲット」を選ぶだけで全.NET Frameworkアプリを.NET 9へ移せるとは案内しません。移行用コピーやブランチでビルド・動作を検証します。

2026年10月の.NET 9・MAUI 9のサポート状況

2026年9月8日更新の.NETサポート表では、.NET 9の終了日は2026年11月10日です。.NET 10 LTSは2028年11月14日までとされています。新規・長期運用では、対応するIDEと依存関係を確認し、移行先も合わせて選びます。

MAUIのサポート表では、MAUI 9は2026年5月12日に終了済みです。.NET 9本体の期限と混同しないでください。MAUI 10は2027年5月11日までとされ、Android/iOSのSDK等も含めた対応を確認します。MAUI 9を候補に表示させることだけで、現行サポート下へ戻せるわけではありません。

候補が出ない・ビルドエラーが残るとき

  1. 新しいSDK形式のコンソールプロジェクトと既存ソリューションを比較し、全環境か特定プロジェクトかを分ける。
  2. NETSDK1045ならSDK一覧・対象TFM・PATH・アーキテクチャ・global.jsonを確認する。
  3. Directory.Build.props等の共通設定でTargetFrameworkが上書きされていないか確認する。
  4. IDE名とバージョン、選択SDK、エラー全文、発生プロジェクトを記録する。
  5. 管理されたPCでは更新チャネルとInstallerのコンポーネント・ログを担当者に確認する。

NETSDK1045の公式説明にある確認項目を利用し、候補がないことだけでキャッシュ破損と判断しません。ビルドを行う場合は、IDEと同じソリューションの場所でdotnet buildを比較し、ログのSDK解決とエラーを確認します。msbuild -versionはMSBuildの番号であり、選択された.NET SDKの番号そのものではありません。

修復は導入・更新の破損が疑われ、前の確認で解決しない場合に検討します。公式修復手順はInstallerの対象インスタンスで「その他 → 修復」を選びます。修復はユーザー設定や一部の拡張・プロファイルを初期化するため、必要な設定を保存してから行います。未確認のキャッシュフォルダーを一括削除する手順やresetsettingsを初手として使いません。

よくある質問

.NET 10のSDKが入っているのにVS 2022でnet10.0が出ない

SDKを読み込める条件とnet10.0を正式に対象にできる条件は違います。net10.0は18.0以降を使い、VS 2022を継続する場合は対応する対象フレームワークとSDKの組み合わせを選びます。

global.jsonを削除すれば解決する?

固定設定が原因か確認してから判断します。CIや他の開発者と共通の意図があるファイルは、削除で結果が変わることだけを理由に消しません。必要SDKの導入や許容するrollForwardを検討します。

ランタイムがあるのに開発できない

実行用ランタイムと開発用SDKは別です。–list-sdksと選択される–version、プロジェクトのTFMを照合してください。

確認したMicrosoft公式資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次