Visual Studio 2022 を 17.12.4 に更新した直後から、テストエクスプローラー実行が「Unable to connect to testing platform runner process」で失敗する──。特に .NET 8 のテストプロジェクトで MSTest と xUnit を同居させていると発生しやすい現象です。本記事では、原因になりやすいプレビュー機能と、すぐ効く回避策・恒久策・報告のコツを整理します。
症状：テストエクスプローラーから実行すると必ず失敗する
Visual Studio 2022 を 17.12.4 にアップデート後、.NET 8 のテストプロジェクトで MSTest と xUnit を同一プロジェクト内で併用している構成だと、テストエクスプローラーからの実行や探索（Discovery）が失敗し、次のようなメッセージが表示されるケースがあります。
Unable to connect to testing platform runner process [xxxTests.dll]
一方で、Visual Studio のプレビュー機能をオフにすると正常にテストが実行できるため、テストコードそのものの不具合というより「Visual Studio 側のテスト実行経路」に原因が潜んでいる可能性が高い、というのが出発点になります。
再現条件をメモする（報告・切り分けに効く）
このエラーは「たまに起きる」よりも「特定条件で必ず起きる」ことが多く、再現メモがあるだけで対応が一気に楽になります。例えば次の項目は、Issue 報告や社内共有でそのまま使えます。
| 項目 | 例 |
|---|---|
| Visual Studio | Visual Studio 2022 17.12.4（Enterprise/Professional/Community なども） |
| .NET | .NET 8 のテストプロジェクト（net8.0） |
| テスト構成 | 同一プロジェクト内に MSTest と xUnit を併用 |
| 失敗タイミング | 探索（Discovery）で失敗／実行で失敗／両方 |
| 回避策の効果 | 「Use testing platform server mode」をオフにすると成功 |
背景：Visual Studio 17.12 以降で進む “新しいテスト実行基盤”
Visual Studio のテストエクスプローラーは、17.12 以降 Microsoft Testing Platform（Microsoft.Testing.Platform）のプロトコルをサポートしています。VS とテストランナー間は JSON-RPC ベースで通信し、従来の VSTest とは仕組みが異なります。
この新しい経路を試験的に有効化するスイッチとして、プレビュー機能の 「Use testing platform server mode」 が用意されています。オンにすると、VS は「runner（テスト実行プロセス）」を起動して接続し、そこ経由で探索・実行を行います。
なお、xUnit.net 側のドキュメントでは、Visual Studio 2022 の比較的新しいバージョンでは Microsoft Testing Platform の Test Explorer 体験が既定で有効になっている、という記載もあります。つまり、将来的にこの経路が “当たり前” になっていく可能性が高く、今のうちに切り分け方法を知っておく価値はあります。
| 観点 | 従来（VSTest 経路） | 新方式（Microsoft Testing Platform / server mode） |
|---|---|---|
| VSとの通信 | 従来プロトコル（JSONベース） | JSON-RPC ベースで runner と通信 |
| 起動される実体 | vstest.console.exe / testhost.exe など複数の実行体 | テストプロジェクト（ビルド成果物）をホストにして動かす思想 |
| 切り替え方法 | 既定（長年の実績） | 「Use testing platform server mode」やプロジェクト設定で切替 |
| メリット | 互換性・安定性が高い | 拡張性が高く、将来的な標準化が進む |
| ハマりどころ | アダプターやSDKの不整合 | runner が起動前に落ちると VS 側は「接続できない」としか言えない |
まず疑うべきは「プレビュー機能由来の不具合」
同一の現象は他の開発者からも報告されており、Microsoft 側の回答でも「プレビュー機能の潜在的な問題の可能性がある」「こちらでは再現しないが特定条件で起きているかもしれない」という趣旨で案内されています。まずはプレビュー機能を疑うのが合理的です。
さらに、GitHub 側でも「server mode を有効化すると runner process に接続できない」という系統の Issue が複数立っており、少なくとも 17.12.4 付近で同種の報告があったことが確認できます。
最短で直す：プレビュー機能「Use testing platform server mode」をオフにする
結論から言うと、いますぐテストを動かすことが目的なら、この回避策が最も確実です。実際に「オフ＋VS再起動で解決した」と明記されている報告もあります。
設定場所は Visual Studio のバージョンや UI によって表記が若干揺れますが、代表的には次のルートです。
- ツール → オプション → 環境 → プレビュー機能 → 「Use testing platform server mode」をオフ
変更後は Visual Studio を再起動して、テストエクスプローラーから再実行してください。プレビュー機能は試験的なため、本番開発環境では「基本オフ、検証環境だけオン」という運用もよく取られます。
チームで事故らない恒久策：プロジェクト側で新しいプロトコルを無効化する
「自分の環境ではオフにしたいが、他プロジェクトではオンにして試したい」「チーム全員に“手動で設定を変えて”と言うのはつらい」場合は、プロジェクト単位で制御できる方法が有効です。
Microsoft Learn のドキュメントでは、テストエクスプローラーが新しいプロトコルを使うのを止める方法として、プロジェクトに次のプロパティを追加する手順が案内されています。
<PropertyGroup>
<DisableTestingPlatformServerCapability>true</DisableTestingPlatformServerCapability>
</PropertyGroup>
この設定をコミットしておけば、個々の開発者がプレビュー機能のオン／オフを迷わずに済みます。特に「問題が出るのは特定のテストプロジェクトだけ」という場合、ピンポイントで被害を抑えられます。
なぜ「接続できない」になるのか：runner が落ちると VS は詳細を拾えないことがある
server mode では、Visual Studio がテストランナーを起動し、TCP ポート（動的割り当て）で接続を張って通信します。ログには “TCP listener を作った” “dotnet.exe で DLL を –server 付きで起動した” といった記録が残ります。
ところが、runner が起動直後にクラッシュしたり、依存関係不足でプロセスが即終了したりすると、VS 側は通信を確立できません。その結果、ユーザーに見えるのは「Unable to connect to testing platform runner process」という抽象的なエラーになりやすい、という構造です。
“すべてのプロジェクトで動く” 機能ではない点にも注意
例として、.NET Framework のテストプロジェクトで server mode を有効にしたところ、runner の起動方式（dotnet で DLL を直接起動）と噛み合わず失敗した報告があります。このケースは最終的に「仕様（By Design）」扱いでクローズされています。つまり、server mode は移行期であり、対象・前提が合わないと動きません。
今回の対象は .NET 8 なので同じ理由ではありませんが、「接続できない」という同じ見え方になることは覚えておくと、切り分けが速くなります。
MSTest と xUnit を同居させると起きやすい理由
本来、テストフレームワークの併用自体は「段階的移行」などで現実的な選択肢です。ただし、IDE の探索・実行はフレームワークごとのアダプターや実行基盤に支えられており、併用によって初期化や登録処理が複雑化します。
実際に Microsoft のリポジトリでは、MSTest の runner と別フレームワークの runner を同時に有効化した結果、「アダプターファクトリが既に登録済み」という例外でテストアプリがクラッシュし、VS には接続失敗しか表示されない、という報告が出ています（MSTest＋NUnit の再現例）。
同じ構図が MSTest＋xUnit の組み合わせでも起こり得ます。とくに server mode はまだ移行期の機能なので、「単体では動くが、併用で落ちる」「環境依存で発火する」といった症状になりやすい点は押さえておくと、切り分けが早くなります。
プレビュー機能をオンのまま使いたい人向け：切り分けチェックリスト
「速度向上や新しい体験のために server mode を試したい」「将来の標準化を見据えて MTP を追随したい」場合は、次の順で切り分けると無駄が減ります。
| チェック | 見たいポイント | 具体的なアクション |
|---|---|---|
| まずは再現条件の固定 | 「いつ・どの操作で」失敗するか | 探索（Discovery）で落ちるのか、実行で落ちるのかを分けて確認 |
| runner が起動しているか | 起動→即終了していないか | テスト出力に “Launching test runner” や “Logging diagnostics under …” が出るか確認 |
| 依存関係不足 | dll / deps / runtimeconfig の欠落 | bin/Debug 配下に *.runtimeconfig.json があるか、missing assembly が出ていないか確認 |
| フレームワーク併用の衝突 | 登録済み例外・アダプター競合 | 一時的に MSTest だけ／xUnit だけにして動作確認（差分で原因特定） |
| CPU アーキテクチャ | x86/x64 の不一致 | 既定のテスト実行アーキテクチャを Test → Test Settings で合わせる |
| キャッシュ破損 | 古い探索結果の残骸 | VS 再起動、bin/obj 削除、必要なら .vs フォルダ削除 |
runner の診断ログを確認する
server mode では、ログに “Logging diagnostics under …” のような行が出て、出力先ディレクトリが示されることがあります。そこに JSON-RPC 接続前後の情報が残るため、まずはそのログを確認してください。
ログが残っていない場合は「起動前に失敗している」「起動コマンドが呼ばれていない」可能性があるので、プレビュー機能のオン／オフや DisableTestingPlatformServerCapability の有無を見直すと切り分けが進みます。
依存関係の欠落は “接続失敗” に化けやすい
GitHub の報告例では、探索ログの背後に「依存関係マニフェストに書かれたアセンブリが見つからない」「testhost がエラーで終了した」といった原因が含まれていました。runner が落ちれば VS は接続できないため、表面上は同じエラーになります。
そのため、まず dotnet test で同じプロジェクトが動くかを確認すると、テストコードの問題か IDE 連携の問題かを切り分けやすくなります（CLI で通るなら、IDE 連携や server mode 側を疑うのが近道です）。
CPU アーキテクチャの不一致も見落としがち
テスト対象や依存 DLL が x64 前提なのに、Visual Studio が既定で x86 のテストランナーを使う設定になっていると、依存 DLL がロードできずに失敗することがあります。Stack Overflow でも、Test → Test Settings → Default Processor Architecture を x64 に合わせたら解決した、という報告があります。
今回のエラーが必ずしもアーキテクチャ問題とは限りませんが、「ある PC だけで起きる」「32bit 依存物が混ざっている」などの条件があるなら、確認する価値は高いポイントです。
併用を続けるなら：現実的な設計パターン
server mode の不具合を避けつつ、MSTest と xUnit を併用したい場合は、運用・設計でリスクを下げられます。
- パターンA：プロジェクトを分ける
同じソリューションに「MSTest 用」と「xUnit 用」のテストプロジェクトを作り、段階移行する。実行基盤が分離され、衝突が起きにくくなります。 - パターンB：当面は VSTest 経路に固定する
DisableTestingPlatformServerCapabilityを設定して、少なくとも問題が解決するまで server mode を使わない。 - パターンC：MTP 対応フレームワークへの移行を検討
例えば xUnit.net v3 は Microsoft Testing Platform との統合を前提に設計されており、互換性のために VSTest 用パッケージを残す運用も推奨されています。将来的に MTP を標準で使う環境が増えることを考えると、選択肢に入ります。
バグ報告・情報提供で直りやすくするコツ
この系統の問題は「特定条件でのみ再現」しやすく、報告情報の質がそのまま解決速度に直結します。Microsoft 側も GitHub リポジトリでの追跡を案内しており、まずは関連 Issue をウォッチするのが近道です。
新規で Issue を立てる（または既存 Issue に追記する）なら、最低限次を添えると再現条件の特定に役立ちます。
- Visual Studio のエディションと正確なバージョン（例：17.12.4）
- .NET SDK の情報（
dotnet --info） - 該当テストプロジェクトの
.csproj（テストSDK／アダプター／フレームワークのバージョンが分かる部分） - プレビュー機能「Use testing platform server mode」のオン／オフ
- テスト出力と診断ログ（可能なら zip）
- 「MSTest と xUnit を同居」など、特徴的な構成要素
まとめ：実務でのおすすめ対応
| やりたいこと | おすすめ | 理由 |
|---|---|---|
| とにかく今日中にテストを回したい | 「Use testing platform server mode」をオフ | 最も再現性の高いワークアラウンド |
| チーム全体で安定させたい | DisableTestingPlatformServerCapability をプロジェクトに追加 | 個々の設定差分をなくし、事故を減らせる |
| 原因を突き止め、将来に備えたい | 診断ログを取り、GitHub Issue を追跡・追記 | 再現条件が特定できれば修正が進みやすい |
プレビュー機能は便利な反面、移行期は環境依存の落とし穴もあります。まずは確実に回避して開発を止めないことを優先しつつ、余力があるタイミングで原因切り分けと情報提供を進めるのが、現実的で安全な進め方です。
コメント