platform-detection

テストプラットフォームとフレームワークの判定

プロジェクトが使用するテストプラットフォーム（VSTest または Microsoft.Testing.Platform）とテストフレームワーク（MSTest、xUnit、NUnit、TUnit）を判定します。

回答のルール

ユーザーが指定したラベルと順序を厳守し、すべてのプレースホルダーを実際の分類に置き換えてください。最初に判定結果を記載してください。その前に見出し、検討メモ、ツール構文、テンプレートの引用を置いてはいけません。続けて、要求されたすべての分類を根拠づけるために必要なリポジトリの情報を挙げた、簡潔な証拠文を1文記載してください。Framework が要求された場合は、それを特定できるパッケージまたはプロジェクト SDK を明記してください。2文目を使えるのは、競合、不完全な構成、またはターゲットフレームワークごとの差異がある場合に限ります。

Platform は、実際にテストを実行するプラットフォームを意味します。VSTest または MTP のいずれかです。構成に競合がある、または不完全なために実行できるプラットフォームを特定できない場合は、実在しないプラットフォームを作り上げず、利用不可と報告してください。

global.json の test.runner だけを根拠に、実行されるプラットフォームを分類してはいけません。この設定が選択するのは dotnet test のコマンドモードです。VSTest が明示されていても、実行可能な MTP アプリケーションへ橋渡しされる場合があります。Platform: を記載する前に、プロジェクトのランナー、ブリッジ、出力形式を示すシグナルまで確認してください。

証拠をまとめる前に、次のスコープ判定を適用してください。

ユーザーの質問	含める証拠	省略する内容
プラットフォームとフレームワーク	最終的なランナー選択プロパティと、それを決定したソース。フレームワークを特定するパッケージまたはプロジェクト SDK。必要な場合は、実行可能にするプロパティ	コマンドモード。一般的な SDK の情報。欠落または競合がある場合を除き、OutputType
決定的なシグナル1つ	そのランナー選択プロパティ、そのソースが優先される理由、競合するパッケージが VSTest を選択も示唆もしない理由。要求されたフレームワークを特定するパッケージまたはプロジェクト SDK も引き続き明記	構成が完全な場合、ブリッジ、OutputType、SDK モード、無関係な前提条件
ターゲットフレームワークごとのプラットフォーム	条件付きで設定される、異なる最終値のみ	共通のプロパティ、プロジェクト全体に関する SDK の説明
明示的なオプトアウト	最終的な UseVSTest の値と、それを決定したソース	競合の原因にならない、上書きされた既定値
dotnet test モード	コマンドモードと、実際にテストを実行するプラットフォームの個別の分類	なし

要求されたラベルに dotnet test mode が含まれない場合、回答のどこにもコマンドモードを記載したり説明したりしないでください。正確なブリッジプロパティがプラットフォームを決定する証拠になる場合でも、それを SDK モードや CLI モードの説明に広げてはいけません。 ユーザーが、明示的なランナープロパティと Microsoft.NET.Test.Sdk のどちらが決定的なシグナルかを尋ねた場合、証拠文では、ランナープロパティが MTP を選択することと、Microsoft.NET.Test.Sdk は VSTest を選択も示唆もしないことの両方を明記してください。

インポートの優先順位によってプロパティが決まる場合は、どのような理由でそのソースが優先されるのか（たとえば、後からインポートされる、または条件が適用される）を説明してください。最終値を含んでいる、または別の設定を上書きしていると述べるだけでは不十分です。

説明は、要求された分類軸に絞ってください。

• global.json による SDK バージョンの固定は補足情報であり、プラットフォームの選択ではありません。test.runner の設定が実際に VSTest またはネイティブ MTP を選択している場合に限り、global.json がそれを選択すると述べてください。
• UseVSTest=true が決定的な場合は、そのことを直接述べてください。存在しない test.runner について推測したり、SDK のバージョン固定を追加のプラットフォーム選択として説明したりしてはいけません。
• コマンドモードを要求されていない場合は、実行されるプラットフォームを内部で判定するために必要だったとしても、コマンドモードを追加してはいけません。

クラシックプロジェクトについての質問でコマンドファミリーも求められた場合は、Command family: MSBuild + vstest.console.exe のような行を直接追加してください。任意の代替案にしたり、不要なビルド条件を加えたりしてはいけません。 ファイルベースのリクエストでは、次の設定ファイル名を一度だけ列挙し、該当するファイルが存在する場合はすべてまとめて読み取ってください： global.json、.csproj、packages.config、Directory.Build.props、 Directory.Build.targets、Directory.Packages.props、および明示的にインポートされた .props／.targets。プロジェクトファイルにない設定がインポート先で定義されている場合があるため、.csprojだけから最終値を推測しないでください。リポジトリの設定だけで十分な場合は、ウェブを検索したり、無関係なファイルを調べたりしないでください。

固定の「プロジェクト設定がpropsより優先される」というルールではなく、実際のMSBuildインポート順に沿ってプロパティを解決してください。該当する各ターゲットフレームワークについて、次のようにします。

1. インポートグラフと条件をたどります。後から適用される代入が優先されます。 Directory.Build.propsは通常、プロジェクト本体より前にインポートされるため、無条件のプロジェクト内の代入が通常はこれを上書きします。後続の.targetsがプロジェクトの設定をさらに上書きする場合もあります。
2. UseVSTest、フレームワークのランナー選択子、TestingPlatformDotnetTestSupport、OutputTypeについて、最終値と、その値を決定した設定元を記録します。
3. Directory.Packages.propsは、関連するプロパティも含んでいない限り、バージョンの根拠として扱います。バージョンに依存する既定値を適用する前に、パッケージ／SDKのバージョンを解決してください。
4. パッケージが存在することからプロパティを推測しないでください。パッケージまたはSDKの既定値を採用できるのは、解決されたバージョンが実際にその値を提供し、かつ後続の代入で上書きされていない場合だけです。

プロジェクトシステムの判定

CLIを選択する前に、プロジェクトを分類します。

• ルートのSdk属性または<Sdk>宣言：SDKスタイル。
• ToolsVersion、Microsoft.Common.props／Microsoft.CSharp.targetsのインポート、明示的な<Reference>および<Compile Include>項目：クラシックな非SDK形式。
• packages.config：クラシックなNuGet依存関係管理。

クラシックなプロジェクトでもVSTest互換アダプターを使用できますが、dotnet testを常に有効な実行方法として扱うことはできません。リポジトリのスクリプト／CIコマンド（一般的にはMSBuildに続いてvstest.console.exeを実行）を優先してください。MSTest.exeに言及するのは、リポジトリの設定またはドキュメントでそのレガシーランナーが確認できる場合に限ります。

テストフレームワークの判定

.csproj、隣接するpackages.config、および Directory.Build.props／Directory.Packages.propsを読み、次の参照を探します。

パッケージまたはSDK参照	フレームワーク
MSTestメタパッケージ、<Project Sdk="MSTest.Sdk[/version]">、または<Sdk Name="MSTest.Sdk">	MSTest
MSTest.TestFramework + MSTest.TestAdapter	MSTest（v3/v4でも有効）
xunit、xunit.v3、xunit.v3.mtp-v1、xunit.v3.mtp-v2、xunit.v3.core.mtp-v1、xunit.v3.core.mtp-v2	xUnit
NUnit + NUnit3TestAdapter	NUnit
TUnit	TUnit（MTPのみ）

クラシックなプロジェクトでは、パッケージIDとバージョンがpackages.configにのみ記載され、プロジェクト側にはHintPath値を持つアセンブリの<Reference>要素だけが含まれている場合があります。両方の情報源を使用してください。

実行されるテストプラットフォームの判定

ユーザーが明示的にdotnet testモードを要求した場合は、回答する前に references/command-mode.mdを読んでください。 プラットフォーム／フレームワークだけに関するリクエストでは、このリファレンスを読み込んだり、コマンドモードに言及したりしないでください。

SDK 8/9のリクエストで、コマンドモードについて明示的に尋ねられており、有効なブリッジがない場合は、因果関係を示す1つの文で次の3点すべてを述べてください。ランナーによりプロジェクトはMTP対応になりますが、dotnet testは引き続きVSTestモードで実行され、ブリッジがないため実際のテスト実行にはVSTestが使われます。この結果の説明に役立つ場合に限り、ネイティブMTPコマンドモードはSDK 10から始まることにも触れてください。

実行が許可されており、プロンプトにもglobal.jsonにもSDKが指定されていない場合は、dotnet --versionを一度実行してください。実行を禁止する読み取り専用の識別リクエストでは、インストール済みSDKを調べず、リポジトリの情報を使い、必要なSDKの前提条件を明記してください。

最終的なプロパティ値を解決した後、次の順序で分類してください。

1. 最終的な UseVSTest=true は VSTest を選択します。同時に global.json がネイティブ MTP コマンドモードを選択している場合は、 コマンドモードとプロジェクトのオプトアウトが競合するため、 Platform: unavailable と報告します。
2. global.json でネイティブ MTP が選択されている場合、最終的な OutputType=Exe を持つ互換性のある MTP アプリケーションは MTP で実行されます。 VSTest 専用のプロジェクト、ライブラリ出力のプロジェクト、またはオプトアウトした プロジェクトは利用できません。
3. SDK 8/9 では、MTP ランナーが有効で、最終的な TestingPlatformDotnetTestSupport=true と最終的な OutputType=Exe が設定されている場合、 MTP で実行されます。
4. ランナーが有効でもブリッジが存在しない、または false の場合、MSTest、 NUnit、xUnit に対応するプロジェクトは引き続き VSTest で実行されます。ランナーによって MTP の機能は利用可能になりますが、SDK 8/9 の dotnet test からは到達できず、 代わりに VSTest アダプターがテストを実行します。ブリッジが true でも ランナーが有効でない場合、プロジェクトは同様に VSTest のままです。
5. ランナーとブリッジが設定されていても、実行可能形式でない出力では不完全なため、 利用できません。選択された SDK の経路から到達できない MTP 専用フレームワークも、 VSTest ではなく利用不可です。

各シグナルの役割を正確に区別してください。

• ランナープロパティはテストアプリケーションを選択します。
• TestingPlatformDotnetTestSupport=true は SDK 8/9 の dotnet test から そのアプリケーションへ到達できるようにします。
• OutputType=Exe は実行可能なホスト形式を指定します。MTP を選択したり有効にしたりするものではありません。

MSTest メタパッケージと MSTest.Sdk プロジェクト SDK を混同しないでください。 PackageReference Include="MSTest" と EnableMSTestRunner=true の組み合わせで MSTest MTP ランナーは有効になりますが、TestingPlatformDotnetTestSupport が 暗黙的に設定されることはありません。

MSTest.Sdk は既定で MTP ランナーを有効にします。ブリッジの動作については、 解決されたバージョンと評価済みプロパティを確認してください。バージョン 3.8 では、 後続の代入で上書きされない限り TestingPlatformDotnetTestSupport が設定されます。 一方、.NET 10 の新しい SDK ではネイティブ MTP モードが想定される場合があります。 <UseVSTest>true</UseVSTest> は VSTest への切り替えを指定します。

シグナル	意味
<Project Sdk="MSTest.Sdk..."> と UseVSTest なし	MTP アプリケーションです。解決された SDK バージョンと評価済みのブリッジプロパティを確認してください
MSTest メタパッケージ + <EnableMSTestRunner>true>	MTP ランナーが有効です。VSTest から MTP へのブリッジを意味するものではありません
<UseMicrosoftTestingPlatformRunner>true	xUnit のランナー選択を決定するシグナルです
<EnableMSTestRunner>true> / <EnableNUnitRunner>true>	MSTest/NUnit のランナー選択を決定するシグナルです
TestingPlatformDotnetTestSupport=true	VSTest から MTP へのブリッジに必要な実行前提条件であり、ランナー選択のシグナルではありません
Microsoft.Testing.Platform パッケージ	MTP 対応アプリケーションです。それだけでは決定的なシグナルではありません
TUnit	MTP 専用フレームワークです
最終的に評価された <OutputType>Exe</OutputType>	パッケージベースの MTP アプリケーションに必要な実行可能ホスト形式です

Microsoft.NET.Test.Sdk だけでは決定的ではありません。MTP 対応プロジェクトでも、 互換性のために残されている場合があります。明示的なオーバーライドによって結果が 決まる場合は、上書きされた既定値ではなく、最終的なオーバーライドとそのソースを 示してください。 ランナー選択プロパティと Microsoft.NET.Test.Sdk が競合する場合は、ランナープロパティが MTP を選択し、Microsoft.NET.Test.Sdk は VSTest を選択も示唆もしないと説明してください。 互換性サポートとして残される場合はありますが、二次的なものです。 TestingPlatformDotnetTestSupport=true はブリッジに必要な前提条件であり、 ランナー選択のシグナルではありません。このプロパティだけでブリッジが有効になるとは 決して説明しないでください。どの単一のシグナルが決定要因かを尋ねられた場合は、 そこで回答を終えてください。設定が完全な場合は、ブリッジやホスト形式の前提条件を 省略し、選択されたランナーが実行できない理由を説明する必要がある場合にのみ追加してください。 同様に、有効なランナーが上書きされている、または到達できない場合は、両方の軸を 因果関係が分かるように説明してください。ランナープロパティによってプロジェクトは MTP 対応になりますが、実際にどのプラットフォームで実行されるかは最終的な UseVSTest／ブリッジ／出力設定によって決まります。フレームワークの特定にパッケージ参照を 使う前に、ランナー選択プロパティを示してください。 シグナルの寄せ集めではなく、因果関係を示す根拠を使います。たとえば：

Platform: MTP
Framework: NUnit

Directory.Build.props supplies final EnableNUnitRunner=true and
TestingPlatformDotnetTestSupport=true, so NUnit executes on MTP.

互換性のない構成の場合は、ファイルを変更せずに、判定の後に最小限の調整方法を1つ提示します。プロジェクトで構成されたプラットフォームをグローバルに選択するか、プロジェクトのオプトアウトを削除して、グローバルに選択されたプラットフォームを使用します。

条件付きプロパティとターゲットフレームワークごとのプロパティ

ターゲットフレームワークごとに、ランナーとブリッジのプロパティを評価します。条件によって実行されるプラットフォームが異なる場合は、プロジェクト全体で1つのプラットフォームにまとめず、各ターゲットを明示して報告します（例：net8.0: VSTest、net9.0: MTP）。