Visual Studio 2022で「.NET 9.0」がターゲットに出ない時の原因と解決策（17.12以降対応の完全ガイド）

「.NET 9.0 の SDK は確かに入っているのに、Visual Studio 2022 の新規プロジェクトやプロジェクトのプロパティに “.NET 9.0” が出てこない」。本稿は、このよくある詰まりポイントを最短で解消するための実践ガイドです。更新が必要な最小バージョン、SDK の確認方法、global.json の落とし穴、PATH とビット数の注意点、プロジェクト種別ごとの TFM 設定まで、再現性の高い手順でまとめます。

症状の整理（どれか一つでも当てはまるなら本記事の対象）

Visual Studio 2022 の「新しいプロジェクトの作成」や「プロジェクトのプロパティ > ターゲットフレームワーク」で .NET 9.0 が候補に現れない。
dotnet --list-sdks では 9.0.x が見えているのに、IDE では選べない。
global.json の有無や内容が不明で、SDK の固定状況が掴めていない。
MAUI / Windows デスクトップ（WPF/WinForms）/ ASP.NET Core など、プロジェクト種別により挙動がばらつく。

結論（最短ルートのチェックリスト）

まずは次のチェックを上から順に。上段ほど効果が高く、複数要因が重なっているケースも多いです。

対処	具体的な手順・ポイント	確認コマンド／場所
Visual Studio を 17.12 以降へ更新	.NET 9.0 を IDE が認識する最小バージョンは 17.12。 VS 2022 の `ヘルプ` → `更新プログラムの確認` か、Visual Studio インストーラーから 17.12.x 以上へアップデート。	VS の `ヘルプ` → `Microsoft Visual Studio のバージョン情報`
SDK / ランタイムを確認	PowerShell／コマンドプロンプトで 9.0.x が見えるか確認。見えなければ SDK を再インストール。	`dotnet --list-sdks dotnet --list-runtimes dotnet --info`
SDK のビット数と PATH を整える	VS 2022 は 64 ビットアプリ。x64 SDK が必須。 PATH の並びで `C:\Program Files\dotnet`（x64）が `C:\Program Files (x86)\dotnet` より上にあること。	`where dotnet`環境変数「Path」の順序
global.json の固定を解除／更新	古い SDK を固定していると .NET 9.0 が出ない。不要なら削除、必要なら 9.0 系に書き換え。	`type .\global.json`
ワークロード／個別コンポーネント	インストーラー > `変更` > `個別のコンポーネント`で「.NET 9 SDK」「.NET 9 対応ワークロード」にチェック。 MAUI/デスクトップ/ASP.NET など用途に応じて該当ワークロードを有効化。	Visual Studio インストーラー
キャッシュ類のクリア	IDE のキャッシュ破損で候補が更新されないことがある。 `%LOCALAPPDATA%\Microsoft\VisualStudio\17.*\ComponentModelCache` を削除。ソリューション直下の `.vs` フォルダも一時退避。	エクスプローラーで対象フォルダ削除後、VS を再起動
修復インストール	上記で改善しない場合は Visual Studio インストーラーの `修復` を実施。	Visual Studio インストーラー

なぜ「.NET 9.0」が表示されないのか ― 仕組みと落とし穴

Visual Studio がターゲットフレームワークの候補を生成する際、以下が揃っている必要があります。

IDE が .NET 9 に対応していること（最小 17.12）。
ローカルに .NET 9 SDK が正しくインストールされ、VS が参照できること（x64）。
プロジェクト種別に対応するワークロードが IDE に入っていること（例：MAUI、デスクトップ、Web）。
global.json などによる SDK の“固定”により、9.0 が拒まれていないこと。

どれか一つでも欠けていると、候補に .NET 9.0 が現れません。特に多いのは 「SDK は入っているが、x86 版のみ」や 「PATH の順序が x86 優先」、そして 「global.json で古い SDK を固定」しているケースです。

手順詳細

Visual Studio 2022 を 17.12 以降へ更新

IDE が .NET 9 の TFM を理解できなければ、SDK が入っていても候補は増えません。更新手順は次の通りです。

Visual Studio 2022 を起動し、ヘルプ → 更新プログラムの確認 をクリック。
または Visual Studio インストーラー（スタートメニューから起動）で、対象の「Visual Studio 2022」を選び、更新を実行。
更新後、ヘルプ → Microsoft Visual Studio のバージョン情報 で 17.12.x 以上を確認。

企業配布のオフラインレイアウトや管理テンプレートを利用している場合、管理者側のレイアウトを 17.12 以上に刷新してもらう必要があります。

.NET 9 SDK／ランタイムが正しく入っているか確認

次のコマンドで 9.0 系の SDK／ランタイムが表示されるかを確認します。

dotnet --list-sdks
dotnet --list-runtimes
dotnet --info

例として、9.0.100 や Microsoft.NETCore.App 9.0.0 が見えれば OK です。表示されない／一部しか見えない場合は、SDK を再インストールしてください。

SDK のビット数（x64）と PATH の順序を確認

Visual Studio 2022 は 64 ビットアプリです。x64 版の .NET SDK が必要です。x86（32 ビット）SDK のみを入れていると、IDE からは認識されないことがあります。CLI が x86 を見ている場合、VS と CLI の結果が食い違います。

where dotnet を実行し、最初に見つかるパスが C:\Program Files\dotnet\dotnet.exe（x64）であることを確認。
環境変数 Path で、C:\Program Files\dotnet が C:\Program Files (x86)\dotnet より上位に並んでいるか確認。
x64 SDK が未導入なら、x64 版インストーラーで追加インストール。

目的	正しいパス例	誤りやすいパス例
x64 SDK/ランタイム	`C:\Program Files\dotnet\`	`C:\Program Files (x86)\dotnet\`（x86）
SDK 実体	`...dotnet\sdk\9.0.100\`	`...dotnet\sdk\8.0.*` のみ

global.json の固定 SDK を解除／更新

ソリューション／プロジェクトルートに global.json があると、そのディレクトリ以下では SDK バージョンが固定されます。古いバージョンが指定されていると、.NET 9 は候補に現れません。

確認：

type .\global.json

更新例（9.0 系に固定）：

{
  "sdk": {
    "version": "9.0.100",
    "rollForward": "latestMinor"
  }
}

固定が不要なら global.json を削除します。CLI で作り直す場合は次を使用します。

dotnet new globaljson --sdk-version 9.0.100

プレビュー SDK を使っていた時期に生成した global.json で "allowPrerelease": true のような指定が残っていると、GA 版との食い違いを招くことがあります。不要な項目は削除しましょう。

ワークロード／個別コンポーネントの見直し

SDK が入っていても、プロジェクト種別に必要なワークロードが IDE に入っていないと、テンプレートや TFM がグレーアウト／非表示になります。Visual Studio インストーラーの 変更 > ワークロード／個別のコンポーネントで次を確認してください。

ASP.NET and web development（Web）
.NET desktop development（WPF/Windows Forms）
Mobile development with .NET（.NET MAUI）
ユニバーサル Windows プラットフォームや C++/C# と併用している場合は該当項目
個別コンポーネントの .NET 9 SDK / .NET 9 Targeting Pack

プロジェクト種別ごとの TFM（Target Framework Moniker）設定

TFM を正しく指定しないと、ビルド時に「対応するターゲットが見つからない」等の MSBuild エラーになります。代表的な TFM を以下に示します。

用途	TFM 例	メモ
コンソール／ライブラリ	`net9.0`	最も基本的な指定。クロスプラットフォーム。
Windows デスクトップ（WPF/WinForms）	`net9.0-windows`	Windows 専用。必要に応じて最小 OS バージョンを明示可能。
ASP.NET Core	`net9.0`	Web ワークロードが必要。
.NET MAUI（Android/iOS/Mac Catalyst）	`net9.0-android` / `net9.0-ios` / `net9.0-maccatalyst`	MAUI ワークロード必須。OS ごとに TFM を分ける。
複数ターゲット	`net9.0;net8.0`	`<TargetFrameworks>` を使用。

csproj 例：

&lt;Project Sdk="Microsoft.NET.Sdk"&gt;
  &lt;PropertyGroup&gt;
    &lt;TargetFramework&gt;net9.0&lt;/TargetFramework&gt;
    &lt;Nullable&gt;enable&lt;/Nullable&gt;
    &lt;ImplicitUsings&gt;enable&lt;/ImplicitUsings&gt;
  &lt;/PropertyGroup&gt;
&lt;/Project&gt;

CLI では 9.0 が使えるのに VS で出ないときの追加確認

MSBuild と dotnet CLI の視点の違い：VS は同梱 MSBuild から SDK を解決します。CLI は PATH 先頭の dotnet を見ます。双方で x64 の 9.0 SDK が見えているかを確認。
プレビュー SDK の設定：プレビュー時期の設定が残っていると GA で不整合を起こします。ツール → オプション → 環境 → プレビュー機能 の「.NET SDK のプレビューを使用する」は、GA 版に移行したら通常オフで問題ありません。
NuGet パッケージのターゲット：一部パッケージが net9.0 未対応のままなら、ビルドは通ってもランタイムで落ちる可能性があります。早めに互換版へ更新を。

キャッシュ／設定のクリア手順

IDE のキャッシュ破損により、ターゲットフレームワーク候補が更新されないケースが存在します。以下を実施してから VS を再起動してください。

ソリューションフォルダ内の .vs フォルダを削除（または退避）。
%LOCALAPPDATA%\Microsoft\VisualStudio\17.*\ComponentModelCache を削除。
必要に応じて Visual Studio Developer Command Prompt で次を実行：
devenv /safemode devenv /resetsettings ※業務環境では設定初期化の影響に注意。

修復インストール

ここまでで改善しない場合、Visual Studio インストーラーから その他 → 修復 を実施してください。インプレース修復により、破損した MSBuild 付属の targeting pack、個別コンポーネント、関連レジストリが復元されます。

プロジェクト作成・既存移行の実践ステップ

新規プロジェクトで .NET 9.0 を選ぶ

Visual Studio を起動 → 新しいプロジェクトの作成。
テンプレート（例：コンソールアプリ）を選ぶ。
構成画面の フレームワーク プルダウンで .NET 9.0 を選択。

既存プロジェクトを 9.0 へ上げる

ソリューションエクスプローラーでプロジェクトを右クリック → プロパティ。
「ターゲットフレームワーク」で .NET 9.0 を選択（出てこない場合は本記事のチェックリストを再確認）。
NuGet パッケージを最新安定版へ更新。互換性警告に注意。

手動で csproj を編集する例：

<TargetFramework>net9.0</TargetFramework>

Windows デスクトップなら：

<TargetFramework>net9.0-windows</TargetFramework>
<UseWPF>true</UseWPF>    <!-- WPF の場合 -->
<UseWindowsForms>true</UseWindowsForms>  <!-- WinForms の場合 -->

マルチターゲットで段階移行

.NET 8 と併用して検証するならマルチターゲットが便利です。

<TargetFrameworks>net9.0;net8.0</TargetFrameworks>

この場合、ビルド時は TFM ごとに成果物が生成されます。条件付き参照には TargetFramework プロパティを用いましょう。

トラブルシューティングの深掘り

代表的なエラーと対処

メッセージ／現象	原因の典型	対処
“The target framework ‘net9.0’ was not found”	Targeting Pack が無い／SDK ビット違い／VS が古い	VS を 17.12+ に更新、x64 SDK を導入、個別コンポーネントで .NET 9 Targeting Pack を選択
CLI ではビルド可、VS では TFM 未表示	PATH 先頭が x86 dotnet／global.json 固定／キャッシュ破損	PATH 順序修正、global.json 見直し、ComponentModelCache を削除
MAUI だけ 9.0 が選べない	MAUI ワークロード未インストール／古い Android/iOS ツールチェーン	「Mobile development with .NET」を有効化、個別コンポーネントで関連ツール更新
WPF/WinForms で 9.0 が無い	.NET デスクトップ開発ワークロード不足	ワークロードの再有効化、.NET 9 Targeting Pack の導入

MSBuild 視点で SDK 解決を確認

VS 付属の MSBuild がどの SDK を見ているか、Developer Command Prompt で確認できます。

msbuild -version
dotnet --info

両者が同じ 9.0 系 SDK を参照していることを確認してください。もし MSBuildSdksPath などの環境変数を独自設定している場合、SDK 解決を阻害することがあります（ビルド環境での一時的設定が残っていないか確認）。

オフライン／プロキシ環境の注意

企業内オフラインレイアウトは、.NET 9 の Targeting Pack と関連ワークロードが含まれるよう再作成が必要です。
プロキシ環境でのインストーラー実行時、失敗しても静かに続行されることがあります。ログを確認し、必要コンポーネントが導入済みか再点検してください。

確認のベストプラクティス（作業後に必ず実施）

新規テンプレート確認：コンソール／ASP.NET／WPF の新規作成画面で .NET 9.0 が選べるか。
既存プロジェクトのプロパティ確認：ターゲットフレームワークのプルダウンに 9.0 が現れるか。
ビルド／実行：dotnet --info の出力と、ビルドログの Using .NET SDK version 9.0.xxx が一致しているか。
CI/CD：ビルドエージェントにも 9.0 SDK（x64）と必要ワークロードが入っているか。global.json をリポジトリに同梱し、バージョン差異を避ける。

付録：よくある質問（FAQ）

Q. Visual Studio 2022 は 32 ビット版と 64 ビット版で挙動が違いますか？

A. VS 2022 自体は 64 ビットアプリです。従って x64 用の .NET SDK が必須です。x86 SDK しか無い場合、CLI 側で 9.0 が見えても VS では候補が出ないことがあります。

Q. Use previews of the .NET SDK（プレビュー SDK を使用）をオンにすべき？

A. 安定版（GA）の .NET 9 を使う限り不要です。プレビュー時期のみ必要でした。オンのままだと意図せずプレビュー SDK を拾うことがあるため、GA 運用ではオフを推奨します。

Q. csproj を直接 `net9.0` に書き換えても候補に出ません。

A. SDK／Targeting Pack／ワークロードのいずれかが不足している可能性があります。ビルド時に MSBuild が該当 TFM を解決できないとエラーになります。チェックリストの上から再点検してください。

Q. CLI と VS のビルド結果が違うのはなぜ？

A. CLI は PATH 上の dotnet（しばしば x86 側）を、VS は同梱 MSBuild から SDK を解決します。where dotnet と dotnet --info、msbuild -version を見比べ、同じ x64 の 9.0 SDK に寄っているかを確認しましょう。

Q. それでも解決しないときは？

A. キャッシュ削除（.vs と ComponentModelCache）→ 17.12+ への再更新 → 個別コンポーネントの .NET 9 再選択 → インストーラーの修復の順に実施してください。最終手段として VS のクリーン再インストールを検討します。

まとめ（再掲）

Visual Studio 2022 を 17.12 以上へ更新。
x64 の .NET 9 SDK／ランタイムが入っていることを確認。（dotnet --list-sdks／--list-runtimes）
PATH で x64 を優先。（C:\Program Files\dotnet を先頭に）
global.json の固定を解除／9.0 に更新。
ワークロード／個別コンポーネントで .NET 9 を有効化。
キャッシュ削除／修復で IDE の認識をリフレッシュ。

上記を満たせば、フレームワーク選択リストに .NET 9.0 が現れ、新規／既存プロジェクトの双方で利用できるようになります。

参考用コマンド集（コピー＆ペースト可）

:: SDK / ランタイム状況確認
dotnet --info
dotnet --list-sdks
dotnet --list-runtimes
where dotnet

:: global.json を 9.0.100 に固定
dotnet new globaljson --sdk-version 9.0.100

:: Visual Studio のキャッシュリフレッシュ（必要に応じて）
devenv /safemode
devenv /resetsettings

チェック項目の早見表（印刷用）

項目	合格条件
IDE バージョン	Visual Studio 2022 ≥ 17.12
SDK / ランタイム	`dotnet --list-sdks` に 9.0.x、`--list-runtimes` に 9.0.x が表示
ビット数	x64 SDK が導入済み、PATH の先頭が `C:\Program Files\dotnet`
global.json	未配置、または `9.0.100` など 9.0 系を指定
ワークロード	用途に応じたワークロードが有効（Web／デスクトップ／MAUI 等）
キャッシュ	`.vs` と `ComponentModelCache` をクリア済み

背景知識：SDK の選択ロジックを理解する

最後に、なぜバージョンやビット数の食い違いで混乱が起きるのかを簡単に整理します。

SDK は SxS（Side-by-Side）で共存：…\dotnet\sdk\8.0.* と 9.0.* は併存可能。global.json の有無や rollForward 設定で、どの SDK を使うかが決まる。
CLI と VS の分離：CLI は PATH の dotnet.exe を参照。VS は MSBuild 側の SDK 解決を行うため、PATH だけ揃えても足りないことがある（VS 側ターゲティングパック必須）。
x64 優先の原則：VS 2022 は 64 ビット。x86 SDK のみ導入だと IDE は認識できないことがある。常に x64 を基準にそろえる。

この仕組みを理解しておくと、次回以降も最短で問題切り分けが可能になります。

おわりに

.NET 9 時代の開発環境は、IDE・SDK・ワークロード・プロジェクト設定が正しくかみ合った瞬間に安定します。本記事のチェックリストをテンプレート化し、チームの新環境構築や CI/CD エージェントへの適用に活用してください。環境差による「動く／動かない」の議論を減らし、実装に集中できる時間を取り戻しましょう。

この記事を書いた人

佐藤健司

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

Visual Studio 2022で「.NET 9.0」がターゲットに出ない時の原因と解決策（17.12以降対応の完全ガイド）

症状の整理（どれか一つでも当てはまるなら本記事の対象）

結論（最短ルートのチェックリスト）

なぜ「.NET 9.0」が表示されないのか ― 仕組みと落とし穴

手順詳細

Visual Studio 2022 を 17.12 以降へ更新

.NET 9 SDK／ランタイムが正しく入っているか確認

SDK のビット数（x64）と PATH の順序を確認

global.json の固定 SDK を解除／更新

ワークロード／個別コンポーネントの見直し

プロジェクト種別ごとの TFM（Target Framework Moniker）設定

CLI では 9.0 が使えるのに VS で出ないときの追加確認

キャッシュ／設定のクリア手順

修復インストール

プロジェクト作成・既存移行の実践ステップ

新規プロジェクトで .NET 9.0 を選ぶ

既存プロジェクトを 9.0 へ上げる

マルチターゲットで段階移行

トラブルシューティングの深掘り

代表的なエラーと対処

MSBuild 視点で SDK 解決を確認

オフライン／プロキシ環境の注意

確認のベストプラクティス（作業後に必ず実施）

付録：よくある質問（FAQ）

Q. Visual Studio 2022 は 32 ビット版と 64 ビット版で挙動が違いますか？

Q. Use previews of the .NET SDK（プレビュー SDK を使用）をオンにすべき？

Q. csproj を直接 `net9.0` に書き換えても候補に出ません。

Q. CLI と VS のビルド結果が違うのはなぜ？

Q. それでも解決しないときは？

まとめ（再掲）

参考用コマンド集（コピー＆ペースト可）

チェック項目の早見表（印刷用）

背景知識：SDK の選択ロジックを理解する

おわりに

この記事を書いた人

コメント

コメントするコメントをキャンセル

Visual Studio 2022で「.NET 9.0」がターゲットに出ない時の原因と解決策（17.12以降対応の完全ガイド）

症状の整理（どれか一つでも当てはまるなら本記事の対象）

結論（最短ルートのチェックリスト）

なぜ「.NET 9.0」が表示されないのか ― 仕組みと落とし穴

手順詳細

Visual Studio 2022 を 17.12 以降へ更新

.NET 9 SDK／ランタイムが正しく入っているか確認

SDK のビット数（x64）と PATH の順序を確認

global.json の固定 SDK を解除／更新

ワークロード／個別コンポーネントの見直し

プロジェクト種別ごとの TFM（Target Framework Moniker）設定

CLI では 9.0 が使えるのに VS で出ないときの追加確認

キャッシュ／設定のクリア手順

修復インストール

プロジェクト作成・既存移行の実践ステップ

新規プロジェクトで .NET 9.0 を選ぶ

既存プロジェクトを 9.0 へ上げる

マルチターゲットで段階移行

トラブルシューティングの深掘り

代表的なエラーと対処

MSBuild 視点で SDK 解決を確認

オフライン／プロキシ環境の注意

確認のベストプラクティス（作業後に必ず実施）

付録：よくある質問（FAQ）

Q. Visual Studio 2022 は 32 ビット版と 64 ビット版で挙動が違いますか？

Q. Use previews of the .NET SDK（プレビュー SDK を使用）をオンにすべき？

Q. csproj を直接 net9.0 に書き換えても候補に出ません。

Q. CLI と VS のビルド結果が違うのはなぜ？

Q. それでも解決しないときは？

まとめ（再掲）

参考用コマンド集（コピー＆ペースト可）

チェック項目の早見表（印刷用）

背景知識：SDK の選択ロジックを理解する

おわりに

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

Q. csproj を直接 `net9.0` に書き換えても候補に出ません。

コメントするコメントをキャンセル