MENU

dotnet runで「.NET SDK 7.0.400 が見つからない」原因と解決策｜global.json対応と.NET 8への移行手順

C#

Microsoft Learn などの演習で「.NET SDK 7.0.400 が必要」と言われるのに、手元には 8.0.303 しか見えず dotnet run が失敗することがあります。本記事では原因の仕組みをほどきながら、最短で演習を進めるための現実的な対処法をまとめます。

目次

まず結論：演習を進めるなら「.NET 8 に寄せる」のが最短ルート

今回のパターンは、演習（または演習用リポジトリ）が 特定の SDK バージョン（7.0.400）を固定しているのに、環境は .NET 8（8.0.303）を前提に整っているために起きやすい詰まりどころです。

.NET 7 はすでにサポート終了（STS）で、学習コンテンツ側が追従していないケースも珍しくありません。短い利用期限のサンドボックス環境では特に、環境をいじり回すよりも 演習（またはプロジェクト）を .NET 8 前提に更新して進めるほうが成功確率が上がります。

選択肢おすすめ度向いている状況やること（要点）
.NET 8 に合わせる（推奨）高学習を止めたくない／サンドボックス期限が短い／.NET 7 固定が理由なく残っているglobal.json を 8 系に更新（または削除）、必要なら TargetFramework を net8.0 に
.NET 7.0.400 を使い続ける中演習が「7.0.400 固定」で、更新すると手順や採点が崩れるdotnet --list-sdks に 7.0.4xx が出る状態を作る（SDK と PATH とアーキテクチャを整合）

症状の整理：よく出るエラーと意味

以下のようなログが出ている場合、ほぼ確実に「プロジェクトが要求している SDK」と「実際に参照されている dotnet（SDK 一覧）」が噛み合っていません。

Requested SDK version: 7.0.400
A compatible .NET SDK was not found
global.json is requesting 7.0.400
（でも dotnet --list-sdks には 8.0.303 しか出ない）

ここで重要なのは、「7.0.400 を入れたつもり」でも、OS が認識している SDK 一覧に出ていない限り、.NET CLI は使えないという点です。逆に言えば、原因の切り分けは「一覧に出るか」「どの dotnet を叩いているか」を押さえるだけで一気に進みます。

なぜ起きる？原因を理解するための最小知識

global.json が「使う SDK」を固定している

global.json は、リポジトリ（フォルダ）配下で実行する dotnet が「どの SDK バージョンを使うか」を決めるファイルです。演習リポジトリにこれが入っていると、PC に最新 SDK が入っていても 指定バージョンが見つからない限り失敗します。

「SDK を入れた」つもりが、実は runtime だけの可能性

.NET には大きく SDK と Runtime があり、dotnet run やビルドに必要なのは基本的に SDK です。Runtime だけ入れても dotnet --list-sdks には出ません。

複数の dotnet が同居していて、別の dotnet を叩いている

Windows では特に、以下のような複数ルートが混在しがちです。

  • C:\Program Files\dotnet\dotnet.exe（一般的な 64bit 版）
  • C:\Program Files (x86)\dotnet\dotnet.exe（32bit 版）
  • Visual Studio が同梱する dotnet（PATH で優先されると混乱しやすい）
  • WSL（Linux 環境）の dotnet（Windows 側のインストールとは別物）

つまり、7.0.400 を入れた場所と、いま叩いている dotnet が参照している場所がズレると、インストール済みのはずでも見えません。

推奨解決：演習（またはプロジェクト）を .NET 8 に合わせる手順

ここからは「学習を止めずに前へ進む」ことを最優先に、.NET 8 前提へ寄せる具体手順をまとめます。サンドボックス期限が短い場合は特に、このルートが強いです。

手順 1：まず現在の状態を 30 秒で把握する

作業前に、今どの SDK が見えているかを確定させます。

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

ポイントは次の通りです。

  • --list-sdks に 8.0.303 が出ているなら、ひとまずビルド環境はあります。
  • --list-sdks に 7.0.4xx が出ていないなら、global.json が 7.0.400 を要求している限り失敗します。

手順 2：global.json を見直す（更新 or 削除）

演習リポジトリ直下（または親フォルダ）に global.json がある場合、まず中身を確認します。

{
  "sdk": {
    "version": "7.0.400"
  }
}

この場合の現実的な選択肢は 2 つです。

選択肢 A：.NET 8 に更新する（最短）

環境に 8.0.303 が入っているなら、そこに合わせます。

{
  "sdk": {
    "version": "8.0.303"
  }
}

もし演習環境の SDK が 8.0.303 ではなく別の 8.0.3xx だった場合は、dotnet --list-sdks に出ている値に合わせてください。

選択肢 B：固定が不要なら削除する（運用的に強い）

学習演習では、SDK を固定する必然性が薄いケースもあります。削除すると、PC に入っている最新の互換 SDK が選ばれやすくなります。ただし演習の採点や手順が厳密に 7 前提の場合、挙動差が出る可能性はあります。

手順 3：プロジェクトのターゲットを net8.0 に揃える（必要な場合）

演習のソースが net7.0 をターゲットにしている場合、.NET 8 側でビルドできるように更新します。対象は通常 *.csproj です。

<PropertyGroup>
  <TargetFramework>net7.0</TargetFramework>
</PropertyGroup>

これを次のように変更します。

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
</PropertyGroup>

複数ターゲット（例：net7.0;net8.0）の演習もあります。その場合は net8.0 を追加して様子を見るのも手です。

手順 4：依存パッケージの整合を取る

ターゲットを上げたときにコケやすいのは、古いパッケージやテンプレート差分です。まずは現状確認します。

dotnet list package --outdated

更新が必要なものがあれば、演習の要件に影響しない範囲で上げます（演習で指定がある場合はそれに従う）。よくあるのは Microsoft.Extensions.* 系や、AspNetCore 系のバージョン整合です。

手順 5：実行前に「どの SDK で動いているか」を確認してから run

dotnet --version
dotnet build
dotnet run

dotnet --version が 8.0.3xx を返していれば、SDK 選択はできています。ここでまだ 7.0.400 エラーが出る場合、別の場所にある global.json を拾っている可能性が高いです（親ディレクトリにあるケースが多い）。

.NET 8 へ寄せたときに出がちな差分と対処

.NET 7 → 8 の移行で詰まりやすいポイントを、よくある順にまとめます。

症状原因になりやすいこと対処の方向性
ビルドは通るが演習の手順通りの出力にならないテンプレート差分／既定値の変更演習が想定している設定（ログ、JSON、ミドルウェア）を明示的に指定する
NuGet の警告や依存関係の競合が出るパッケージのメジャー差分dotnet list package --outdated で更新候補を洗い出し、最小限の更新で揃える
SDK 8 があるのに 7.0.400 を要求され続ける別階層の global.json を拾っている作業ディレクトリの親まで確認し、不要な固定を外す／更新する

どうしても 7.0.400 が必要な場合：SDK が「見えない」原因を潰す

演習が採点込みで「7.0.400 固定」で、更新すると進めない場合は、.NET 7 を並行インストールして使い分ける方針になります。ここでのゴールはシンプルで、dotnet --list-sdks に 7.0.4xx が出る状態にすることです。

チェック 1：入れたのは SDK？Runtime？

まずここを間違えると永遠に解決しません。以下で判断できます。

  • dotnet --list-sdks に 7.0.4xx が出ない → SDK が入っていない（または別の dotnet を叩いている）
  • dotnet --list-runtimes に 7.0.x が出る → Runtime だけ入っている可能性がある

チェック 2：いま叩いている dotnet はどれ？（PATH の確認）

同じ dotnet コマンドでも、実体が違うと SDK の見え方が変わります。OS 別に確認します。

Windows（PowerShell / コマンドプロンプト）

where dotnet
# PowerShell の場合
Get-Command dotnet

複数行出てきたら「上に出てくるもの」が優先されます。意図した場所（通常は C:\Program Files\dotnet\dotnet.exe）になっているか確認してください。

macOS / Linux

which dotnet
ls -l $(which dotnet)

VS Code を使っている場合の注意

VS Code の統合ターミナルは「起動時点の環境変数」を引き継ぐため、インストール直後にターミナルを開きっぱなしだと古い PATH のままのことがあります。ターミナルを一度閉じて開き直す、もしくは VS Code 自体を再起動すると反映されやすいです。

チェック 3：DOTNET_ROOT / DOTNET_ROOT(x86) がズレていないか

企業端末や特殊な環境では、環境変数で dotnet の参照先が固定されていることがあります。

Windows（PowerShell）

$env:DOTNET_ROOT
$env:DOTNET_ROOT_X64
$env:DOTNET_ROOT_X86

Windows（コマンドプロンプト）

echo %DOTNET_ROOT%

ここが空なら問題ないことも多いですが、値が入っていて想定外の場所を指している場合は、そちらの dotnet を見に行ってしまいます。演習環境で変更できない場合は、その環境が前提としている SDK バージョンに寄せるほうが速いこともあります。

チェック 4：x64 と x86（32bit/64bit）のねじれ

Windows でありがちなのが「7.0 SDK を x64 で入れたのに、実行している dotnet は x86」というパターンです。この場合、互いの SDK フォルダを参照しないため、入っていても見えません。

dotnet --info の出力にはインストール場所が出るため、SDK のベースパスがどこかを確認してください。例として、64bit なら通常 C:\Program Files\dotnet 配下です。

チェック 5：WSL やコンテナを使っていないか

WSL（Ubuntu など）のターミナルで dotnet を叩いている場合、Windows に入れた SDK は見えません。WSL 内に SDK を入れる必要があります（ただし演習の環境制約次第では難しい）。

同様に、Docker/Dev Container 内で動かしているなら、コンテナイメージ側に 7.0 SDK が入っている必要があります。

global.json を「現実的に動く形」にする小技

演習が 7.0.400 と書いていても、環境には 7.0.4xx の別パッチが入っている、ということがあります。まずは dotnet --list-sdks に出ている 7.0.4xx に合わせて global.json を更新するのが堅いです。

どうしても「指定と完全一致」に縛られて困る場合は、global.json 側でロールフォワード設定を使えるケースもあります（演習の要件に反しない範囲で）。

{
  "sdk": {
    "version": "7.0.400",
    "rollForward": "latestPatch",
    "allowPrerelease": false
  }
}

注意：ロールフォワードの挙動は SDK の世代や設定により差が出ます。演習が「7.0.400 固定であること」自体を前提にしている場合は、素直に 7.0.4xx を見える状態にする（PATH/インストール/アーキテクチャの整合）ほうがトラブルが少ないです。

トラブルシュート早見表：原因の当たりを一発で付ける

状況原因の可能性確認コマンド対処
dotnet --list-sdks に 7.0 が出ないSDK 未導入／Runtime のみdotnet --list-sdks / dotnet --list-runtimes「SDK」を導入（Runtime ではない）
7.0 を入れたのに一覧に出ない別の dotnet を叩いているWindows: where dotnet / mac: which dotnetPATH の優先順位を修正、VS Code を再起動
Windows で x86 と x64 が混在アーキテクチャねじれdotnet --infox64 dotnet を使う／SDK も同じビット数で揃える
global.json が 7.0.400 を要求し続ける固定が残っている／親階層にもあるファイル検索（リポジトリ親まで）global.json 更新 or 削除
サンドボックスでインストールが反映されない権限・制約／環境が初期化されるdotnet --list-sdks の変化を確認.NET 8 前提に寄せる／別環境（ローカル、Codespaces 等）を使う

サンドボックスや期限付き環境で詰まらないための現場的コツ

演習環境が短時間で消える、権限が制限されている、という前提だと「正論としての解決」より「時間内に終わる解決」が重要になります。経験上、次の順で判断すると失敗しにくいです。

最初に必ず実行する 3 コマンド

dotnet --info
dotnet --list-sdks
dotnet --version

この時点で 7.0.4xx が見えないなら、演習を .NET 8 に寄せる判断が最もコスパが良いことが多いです。

「演習が古い」可能性も前提に置く

Microsoft の学習コンテンツでも、モジュールは更新される一方で、ハンズオン用のリポジトリが過去の固定バージョン（global.json）のまま残ることがあります。結果として「最新環境（.NET 8）を用意したのに、古い SDK を要求される」ねじれが起きます。

このときは、演習の目的（API を作る、DI を理解する、Azure へデプロイする等）を優先し、実行できる SDK で先へ進むほうが学習効果が高いです。

環境を固定したいなら「コンテナで SDK を固定」も選択肢

ローカル環境や自分のリポジトリで学習する場合は、PC に SDK を増やし続けるより、Docker/Dev Container で SDK を固定するほうが管理が楽です。演習が 7.0 固定なら、コンテナ側を 7.0 SDK にしてしまう、という整理もできます（ただし演習プラットフォームがコンテナ利用を許可しているかは要確認です）。

まとめ：この手のエラーで迷わないための指針

  • global.json がある限り、指定 SDK が見えないと dotnet run は失敗する
  • 「入れたのに見えない」は、だいたい SDK ではなく Runtime、または 別の dotnet を叩いているのどちらか
  • 期限付きの演習環境では、最短で進めるなら .NET 8 前提に寄せる（global.json 更新/削除、必要なら net8.0 へ）

まずは dotnet --list-sdks の出力を“事実”として起点にし、そこから global.json と PATH（どの dotnet を叩いているか）を合わせにいくと、無駄なく解決に近づけます。

C#
Microsoft Learn .NET 8 global.json .NET SDK dotnet run

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次