Visual Studio 2022 で「The .NET runtime 9.0.5 or newer could not be found」エラーが出るときの Mac ビルドホスト解決手順

Visual Studio 2022 から iOS アプリをビルド／デバッグしようとしたとき、リモート Mac 側で「.NET 9.0.5 以降のランタイムが見つからない」というエラーが出て先に進めない――そんな状況を、Apple M3・macOS Sequoia・iPadOS 18 といった最新環境でもう一度きちんと整理し、.NET 9 Arm64 SDK の入れ方からペアリングのやり直しまで、実運用を想定した具体的な手順としてまとめます。

エラー「The .NET runtime 9.0.5 or newer could not be found」とは

Windows 版 Visual Studio 2022 から iOS アプリ（.NET MAUI / Xamarin / 旧 iOS プロジェクト問わず）をリモート Mac へ送ってビルドするとき、Mac 側に適切な .NET ランタイムが存在しないと、次のようなエラーが表示されます。

The .NET runtime 9.0.5 or newer could not be found in the remote host under '/usr/local/share/dotnet/dotnet'.

典型的には、次のような条件が重なったときに発生します。

Mac 側に .NET 9 の SDK／ランタイムが入っていない、または古い
Intel Mac 用の x64 版 SDK だけを入れていて、Apple M シリーズ (Arm64) 版が入っていない
複数バージョンの .NET SDK が混在し、Visual Studio が期待する 9.0.5 以降を選べていない
/usr/local/share/dotnet/ 以下の構成が壊れている、もしくはカスタムパスに変更している

今回の想定環境を表にまとめると、次のようになります。

項目	内容
Windows 側 IDE	Visual Studio 2022（最新アップデート）
Mac 側 OS	macOS Sequoia 15.5（Apple M3 チップ）
ターゲット OS	iOS / iPadOS 18.5
Mac の用途	ビルド専用（GUI の Visual Studio for Mac は未使用）
要求される .NET	.NET 9.0.5 以降のランタイム
ランタイム検出パス	/usr/local/share/dotnet/dotnet

重要なのは、「Mac 側の .NET 環境は基本的に Command Line（CLI）だけでよい」という点です。Visual Studio for Mac をインストールする必要はなく、.NET SDK と Xcode コマンドラインツールさえあれば、Windows からのリモートビルドは成立します。

なぜ Mac 側に .NET 9 ランタイムが必須なのか

Visual Studio 2022 から iOS プロジェクトをビルドするとき、Windows 側では MSBuild がプロジェクトファイルを解釈し、最終的なコンパイル・リンク・署名などの処理はペアリングされた Mac 側で実行されます。このとき、Mac 側では次のような要素が使われます。

.NET CLI（dotnet コマンド）
.NET SDK／ランタイム（ターゲットとなる .NET のバージョン）
Xcode / Xcode Command Line Tools（iOS シミュレータ・実機ビルド・署名）

プロジェクト側で TargetFramework に net9.0-ios のような指定をしている場合、Mac 側にも .NET 9 の SDK／ランタイム が存在しないと、ビルド中に MSBuild が「必要なランタイムが見つからない」と判断し、今回のようなエラーメッセージを出します。

このとき、Visual Studio は Mac に対して主に次のパスを前提にアクセスします。

/usr/local/share/dotnet/dotnet

そのため、例え自分で別の場所に .NET を配置していても、特別な設定をしていなければ Visual Studio からは見つけられません。

Apple M3 / Arm64 環境で「Arm64 版 .NET SDK」が必須の理由

Apple M シリーズ（M1/M2/M3…）は Arm64 アーキテクチャです。ここに Intel 向けの x64 .NET SDK を入れると、Rosetta 2 を介して動作することになり、次のような問題が起きがちです。

ビルドが全体的に遅くなる
一部のネイティブ依存コンポーネントが期待通りに動かない
Arm64 と x64 の SDK が混在し、パス解決がややこしくなる

そのため、必ず「macOS Arm64」向けの .NET 9 SDK インストーラ を選ぶことが重要です。表にすると次のようなイメージです。

Mac のチップ	入れるべき .NET SDK	結果
Apple M3 (Arm64)	macOS Arm64 版 .NET 9 SDK	ネイティブの Arm64 として高速＆安定
Apple M3 (Arm64)	macOS x64 版 .NET 9 SDK	Rosetta 経由で動作し遅い。場合により Visual Studio から認識されないことも

特にビルド専用 Mac を複数人で共有している場合、誰かがうっかり x64 版を先に入れてしまうと、後から入れた Arm64 版と衝突し、今回のような「ランタイムが見つからない」系の問題が発生しやすくなります。

解決への全体像：クリーンインストール＋ペアリングやり直し

今回のエラーを確実に解決するためには、Mac 側の .NET 環境を一度整理し、.NET 9 Arm64 SDK をクリーンに入れ直したうえで Visual Studio とのペアリングをやり直すのが近道です。全体の流れを一覧にすると次のようになります。

ステップ	内容	目的
1	既存 .NET SDK の削除	バージョン／アーキテクチャが混在している状態をリセット
2	.NET 9 Arm64 SDK のインストール	Visual Studio が要求する .NET 9 ランタイムを Mac に用意
3	インストール確認	dotnet コマンドから 9.0.x が見えているか確認
4	Mac を再起動	PATH／Xcode Toolchain／デーモン等の再読み込み
5	Visual Studio からペアリングをやり直し	古い接続情報やキャッシュを破棄して再検出させる
6	プロジェクトのクリーン＆リビルド	古い bin/obj を捨て、新しいランタイムで完全ビルド

次の章から、それぞれのステップを実際のコマンドや注意点とともに詳しく見ていきます。

ステップ1：既存の .NET SDK をすべて削除する

まずは、Mac 側に中途半端に残っている .NET SDK を一掃します。標準のインストール先は次のディレクトリです。

/usr/local/share/dotnet/

この配下には、概ね次のような構造でファイルが配置されています。

ディレクトリ	役割
dotnet	.NET CLI の本体（実行ファイル）
sdk/	各バージョンの .NET SDK 本体（MSBuild などを含む）
shared/	共通ランタイム（ASP.NET Core、.NET runtime など）
host/	ランチャーなどの共通コンポーネント

今回の問題をシンプルに解決するため、まずは SDK ディレクトリを空にして、ランタイムの取り違えを防ぎます。Mac のターミナルで次のコマンドを実行します。

sudo rm -rf /usr/local/share/dotnet/sdk/*

このコマンドは SDK だけ を削除し、ランタイム本体（shared ディレクトリ以下）は残す形です。とはいえ、環境を完全に作り直したい場合は、次のようにディレクトリごと退避してしまうのも一手です。

sudo mv /usr/local/share/dotnet /usr/local/share/dotnet_backup_$(date +%Y%m%d)

その上で、新規に .NET 9 SDK をインストールすると「純粋な .NET 9 環境」として作り直せるため、トラブルシューティングしやすくなります。

ステップ2：最新の .NET 9 SDK（Arm64）をインストールする

次に、macOS (Arm64) 向けの .NET 9 SDK をインストールします。ポイントは次の 3 つです。

必ず「macOS Arm64」版を選ぶ（Intel 用 x64 版は選ばない）
SDK にランタイムも含まれるため、基本的には SDK インストールだけでよい
バージョンは 9.0.5 以降（推奨は 9.0.30x などの最新安定版）

ダウンロードしたインストーラ（.pkg）をダブルクリックして実行し、ウィザードに従って進めるだけで、通常は /usr/local/share/dotnet 以下に CLI や SDK が展開されます。

インストール後に、念のため次の点だけ確認しておくと安心です。

/usr/local/share/dotnet/dotnet が存在するか
/usr/local/share/dotnet/sdk/9.0.xxx/ が作られているか
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/9.0.xxx/ などが存在するか

ターミナルで確認する場合は、例えば次のようなコマンドが使えます。

ls -R /usr/local/share/dotnet | head

ステップ3：dotnet コマンドで SDK／ランタイムを確認する

インストールが終わったら、Mac のターミナルで次のコマンドを実行し、.NET 9 SDK が正しく認識されているか確認します。

dotnet --list-sdks

ここで、少なくとも 1 行は次のような表示が出ているはずです。

9.0.302 [/usr/local/share/dotnet/sdk]

さらに詳細を確認するには、次のコマンドも有効です。

dotnet --list-runtimes
dotnet --info
which dotnet

which dotnet の結果が /usr/local/share/dotnet/dotnet になっていることも重要です。もし別のパス（例：/usr/local/bin/dotnet）が表示される場合は、シンボリックリンクを張り直すか、古いバージョンが PATH の先頭に来ている可能性があります。

PATH の確認には次のコマンドが便利です。

echo $PATH

通常は /usr/local/share/dotnet か、そこへのシンボリックリンクが PATH 上に含まれていれば問題ありません。

ステップ4：Mac を再起動して環境を確定させる

.NET SDK のインストール後、そのままでも動作することが多いですが、特に以下のようなケースでは 一度 Mac を再起動 しておくのが無難です。

システムレベルの PATH を変更した
/usr/local/share/dotnet をまるごと作り直した
古い Xcode や Command Line Tools から新しいバージョンに切り替えた

Visual Studio の Pair to Mac 機能は、バックグラウンドでいくつかのエージェントプロセスを起動します。再起動しておけば、古いプロセスやキャッシュが残ったままになるリスクを減らせます。

ステップ5：Windows 側から Mac とのペアリングをやり直す

Mac の準備が整ったら、Windows の Visual Studio 2022 からペアリングをし直します。大まかな流れは次の通りです。

Visual Studio で任意の iOS プロジェクトを開く
メニューの「Tools」から「iOS」→「Pair to Mac…」を選択
表示された Mac の一覧から、該当の Mac を選んで接続
以前に接続したことがある場合は、一度「切断」してから再接続する

ペアリングやり直しの意味は、単に接続を復旧させるだけでなく、Visual Studio に「Mac 側の .NET SDK 情報を再スキャンさせる」ことにあります。古い SDK 構成のキャッシュが残っていると、新しい .NET 9 を入れても認識に失敗する場合があるためです。

ペアリングに成功すると、Visual Studio の右下ステータスバー付近に「接続済み」状態が表示され、ターゲットプラットフォームの一覧にも iOS シミュレータやデバイスが再度現れるはずです。

ステップ6：プロジェクトをクリーン／リビルドして実行する

最後に、プロジェクト側の古いビルド成果物を全て捨てて、新しい .NET 9 環境で完全にビルドし直します。

Visual Studio のメニューから「Build」→「Clean Solution」を実行
念のため、プロジェクトフォルダ内の bin と obj フォルダを手動で削除
「Build」→「Rebuild Solution」を実行
ターゲットとして iOS シミュレータ／実機を選び、「Debug」開始

ここまで実施すると、これまで出ていた

The .NET runtime 9.0.5 or newer could not be found in the remote host under '/usr/local/share/dotnet/dotnet'.

といったエラーは解消され、Mac 側で .NET 9 を使ったビルドが正常に走るようになります。

MSBuild プロパティ「DotNetRuntimePath」でカスタムパスを指定する

もし何らかの理由で、.NET ランタイムを標準パス以外（例：/opt/dotnet など）に置いている場合は、MSBuild のプロパティ DotNetRuntimePath を使って、Visual Studio にその場所を教えることができます。

プロジェクトファイル（.csproj）またはソリューション共通の Directory.Build.props に、次のような記述を追加します。

&lt;Project&gt;
  &lt;PropertyGroup&gt;
    &lt;DotNetRuntimePath&gt;/カスタム/パス/dotnet&lt;/DotNetRuntimePath&gt;
  &lt;/PropertyGroup&gt;
&lt;/Project&gt;

複数プロジェクトで共通の設定としたい場合は、ソリューションのルートに Directory.Build.props を置き、そこに上記の PropertyGroup を記述しておくと管理が楽になります。

カスタムパスを指定するメリットと注意点は次の通りです。

項目	ポイント
メリット	標準パスとは別に、検証用の .NET 環境を分けて配置できる
メリット	複数バージョンの .NET を共存させつつ、特定プロジェクトだけ別パスを使うことが可能
注意点	ビルド専用 Mac を複数人で共用する場合、誰かがパスを変えると影響範囲が読みにくくなる
注意点	パスの typo（スペルミス）をすると、今回と同じ「ランタイムが見つからない」エラーにつながる

特別な理由がない限り、まずは標準パス（/usr/local/share/dotnet）で運用し、どうしても環境を分離したいときにのみ DotNetRuntimePath を使うのがおすすめです。

複数バージョンの .NET SDK を共存させる場合の考え方

.NET では、複数バージョンの SDK／ランタイムを同じマシンに共存させることができます。ビルド専用 Mac でも、複数プロジェクトが混在する場合は、.NET 8 と 9 を同時に使いたいことがあるでしょう。

このときの基本的なポイントは次の通りです。

/usr/local/share/dotnet/sdk の配下に、バージョンごとのディレクトリが並ぶ形で共存させる
global.json を使うと、プロジェクトごとに使う SDK バージョンを固定できる
Visual Studio からのリモートビルドも、基本的にはこのルールに従う

例えば、.NET 8 と 9 の SDK を同居させたい場合は、次のような構成になります。

/usr/local/share/dotnet/sdk/
  ├─ 8.0.404/
  └─ 9.0.302/

そして、特定のプロジェクトで .NET 9 SDK を必ず使いたい場合は、ソリューションのルートに global.json を置きます。

{
  "sdk": {
    "version": "9.0.302",
    "rollForward": "latestFeature"
  }
}

これにより、Mac 側で dotnet コマンドが呼び出されたときも、Visual Studio からのビルド時も、基本的には 9.0.302 の SDK が選ばれるようになります。

今回の「ランタイムが見つからない」問題が解消した後に、徐々に旧バージョンを戻していく形でも構いません。その際は、毎回 dotnet --list-sdks と global.json を確認し、「どのプロジェクトがどの SDK を見ているか」を意識して運用すると安全です。

iOS 17 以降と .NET 9 の組み合わせで注意したい点

iOS 17 以降、コード署名やビルドに関する仕様変更がいくつか行われており、古い .NET 9 の SDK（9.0.300 以前など）では、まれに署名周りの不具合やビルドエラーが報告されています。

そのため、次のような方針でバージョンを選ぶとトラブルを減らせます。

iOS / iPadOS 17 以降をターゲットにする場合は、.NET 9.0.302 以降の SDK を選ぶ
Visual Studio 2022 側も、可能な限り最新のアップデートを適用しておく
macOS Sequoia など、比較的新しい OS バージョンとの組み合わせほど、最新の .NET / Xcode を使う

今回のように「ランタイムが見つからない」というエラーが解消できたとしても、その後にコード署名やデプロイで別のエラーが出る可能性があるため、.NET / Xcode / iOS のバージョンをそろえておくことは非常に重要です。

ビルド専用 Mac に Visual Studio for Mac は不要

最後によくある疑問として、「ビルド専用 Mac にも Visual Studio for Mac をインストールしておくべきか？」という点があります。結論から言うと、ビルド専用ならインストールする必要はありません。

リモートビルドに必須となるのは、主に次のコンポーネントです。

.NET SDK／ランタイム（今回の例では .NET 9 Arm64）
Xcode 本体（App Store からインストール）
Xcode Command Line Tools

Windows 側の Visual Studio 2022 が、これらを前提に Mac へ接続し、必要な MSBuild タスクや dotnet コマンドをリモート実行します。GUI の Visual Studio for Mac は開発者自身が Mac 上でコードを書くときにのみ必要であり、ビルド専用マシンでは基本的に不要です。

むしろ、Visual Studio for Mac 由来の古い SDK やモバイルワークロードが中途半端に残っていると、今回のようなランタイム検出の問題を引き起こすケースもあります。ビルド専用 Mac はできるだけ「シンプルな構成」を維持するのがおすすめです。

トラブルシューティングのチェックリスト

ここまでの内容を、すぐに使えるチェックリストとして整理すると次のようになります。エラーが再発したときの確認用として、控えておくと便利です。

チェック項目	確認方法	OK の状態
.NET CLI が入っているか	`dotnet --info`	エラーにならず、バージョン情報が表示される
.NET 9 SDK が存在するか	`dotnet --list-sdks`	`9.0.xxx` の行が少なくとも 1 つある
パスが正しいか	`which dotnet`	`/usr/local/share/dotnet/dotnet` が表示される
SDK が混在しすぎていないか	`ls /usr/local/share/dotnet/sdk`	必要なバージョンだけが並んでいる（不要なものは削除済み）
global.json の指定が間違っていないか	プロジェクトルートの global.json を確認	存在する場合、そのバージョンが実際にインストールされている
Visual Studio のペアリング状態	「Pair to Mac」で状態を確認	接続済み（Connected）になっている
ビルドキャッシュのリセット	bin / obj フォルダの削除	クリーン後のリビルドでエラーが再現しない

まとめ：.NET 9 Arm64 SDK をクリーンインストールし、ペアリングを再構成する

今回取り上げたエラー

The .NET runtime 9.0.5 or newer could not be found in the remote host under '/usr/local/share/dotnet/dotnet'.

は、一見すると複雑そうに見えますが、実際には「Mac 側に .NET 9 ランタイムが正しく入っていない」「あるいは Visual Studio から認識できていない」という、比較的シンプルな問題に集約されます。

解決のポイントを改めて整理すると次の通りです。

Mac 側の /usr/local/share/dotnet/sdk から古い SDK を削除し、環境を整理する
Apple M3 などの Apple Silicon では、必ず macOS Arm64 版 .NET 9 SDK をインストールする
dotnet --list-sdks で 9.0.xx が見えていることを確認する
Mac を再起動し、Visual Studio から Pair to Mac をやり直す
プロジェクトをクリーン／リビルドし、新しいランタイムで完全ビルドさせる
標準パス以外を使う場合は DotNetRuntimePath でランタイムパスを明示できる

これらを順番に実施すれば、ビルド専用 Mac に GUI の Visual Studio を入れなくても、.NET 9 ベースの iOS アプリ開発・デバッグ環境を安定して運用できます。特に、チームで Mac ビルドホストを共有している場合は、「Arm64 版 SDK だけを入れる」「不要な SDK を溜め込まない」「ペアリングをこまめにやり直す」といった運用ルールを決めておくと、同種のトラブルを未然に防ぎやすくなります。

この記事を書いた人

佐藤健司

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

Visual Studio 2022 で「The .NET runtime 9.0.5 or newer could not be found」エラーが出るときの Mac ビルドホスト解決手順

エラー「The .NET runtime 9.0.5 or newer could not be found」とは

なぜ Mac 側に .NET 9 ランタイムが必須なのか

Apple M3 / Arm64 環境で「Arm64 版 .NET SDK」が必須の理由

解決への全体像：クリーンインストール＋ペアリングやり直し

ステップ1：既存の .NET SDK をすべて削除する

ステップ2：最新の .NET 9 SDK（Arm64）をインストールする

ステップ3：dotnet コマンドで SDK／ランタイムを確認する

ステップ4：Mac を再起動して環境を確定させる

ステップ5：Windows 側から Mac とのペアリングをやり直す

ステップ6：プロジェクトをクリーン／リビルドして実行する

MSBuild プロパティ「DotNetRuntimePath」でカスタムパスを指定する

複数バージョンの .NET SDK を共存させる場合の考え方

iOS 17 以降と .NET 9 の組み合わせで注意したい点

ビルド専用 Mac に Visual Studio for Mac は不要

トラブルシューティングのチェックリスト

まとめ：.NET 9 Arm64 SDK をクリーンインストールし、ペアリングを再構成する

この記事を書いた人

コメント

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

Visual Studio 2022 で「The .NET runtime 9.0.5 or newer could not be found」エラーが出るときの Mac ビルドホスト解決手順

エラー「The .NET runtime 9.0.5 or newer could not be found」とは

なぜ Mac 側に .NET 9 ランタイムが必須なのか

Apple M3 / Arm64 環境で「Arm64 版 .NET SDK」が必須の理由

解決への全体像：クリーンインストール＋ペアリングやり直し

ステップ1：既存の .NET SDK をすべて削除する

ステップ2：最新の .NET 9 SDK（Arm64）をインストールする

ステップ3：dotnet コマンドで SDK／ランタイムを確認する

ステップ4：Mac を再起動して環境を確定させる

ステップ5：Windows 側から Mac とのペアリングをやり直す

ステップ6：プロジェクトをクリーン／リビルドして実行する

MSBuild プロパティ「DotNetRuntimePath」でカスタムパスを指定する

複数バージョンの .NET SDK を共存させる場合の考え方

iOS 17 以降と .NET 9 の組み合わせで注意したい点

ビルド専用 Mac に Visual Studio for Mac は不要

トラブルシューティングのチェックリスト

まとめ：.NET 9 Arm64 SDK をクリーンインストールし、ペアリングを再構成する

この記事を書いた人

関連記事

コメント

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

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