ソリューション フィルター ファイルは、ソリューション内のすべてのプロジェクトからビルドまたは読み込むプロジェクトを示す拡張子 .slnf を持つ JSON ファイルです。 MSBuild 16.7 以降では、ソリューション フィルター ファイルで MSBuild を呼び出して、フィルター処理を有効にしてソリューションをビルドできます。
注
ソリューション フィルター ファイルは、読み込まれたりビルドされたりするプロジェクトのセットを減らし、形式を簡略化します。 ソリューション ファイルは引き続き必要です。
コマンド ラインからソリューション フィルターをビルドする
コマンド ラインからソリューション フィルター ファイルをビルドする場合、ソリューション ファイルのビルドとまったく同じ構文が使用されます。 次のように、フィルター処理を有効にしてビルドするソリューションではなく、ソリューション フィルター ファイルを指定します。
msbuild [options] solutionFilterFile.slnf
スイッチや追加のプロパティを通常どおり追加することもできます。 MSBuild コマンド ライン リファレンス を参照してください。 このコマンドは、フィルター処理されたプロジェクトと、それらが依存するすべてのプロジェクトをビルドします。 コマンド ラインからソリューション フィルターをビルドすると、MSBuild は自動的に依存関係に従います。 フィルターで指定されている場合、またはビルドされたプロジェクトによって参照されている場合は、プロジェクトがビルドされます。
ソリューション フィルター ファイル
Visual Studio を使用して、ソリューション フィルター ファイルを操作できます。 Visual Studio でソリューション フィルターを開くと、アンロードされたプロジェクトと読み込まれたプロジェクトが表示され、ビルド用に選択するプロジェクトをさらに読み込むオプションが表示されます。 初期プロジェクトまたはプロジェクトが依存するすべてのプロジェクトを読み込んでビルドすることもできますが、必須ではありません。 フィルター処理されたソリューション を参照してください。
ソリューション フィルターは、ソリューションと同じフォルダーに存在する必要はありません。 ソリューション ファイルへのパスはソリューション フィルター ファイルの場所を基準としていますが、各プロジェクトへのパスはソリューション ファイル自体に対する相対パスであり、ソリューション ファイル内のプロジェクト パスと一致する必要があります。 次の例では、相対パスの使用方法を示します。
{
"solution": {
"path": "..\\..\\Documents\\GitHub\\msbuild\\MSBuild.sln",
"projects": [
"src\\Build.OM.UnitTests\\Microsoft.Build.Engine.OM.UnitTests.csproj"
]
}
}
パス内の円記号はエスケープされるため、2 倍にする必要があります。
注
MSBuild 17.12 以降でサポートされている .slnx ソリューション ファイル形式を使用している場合、.slnx ファイルは .slnf ファイルよりも優先されます。
例
Visual Studio でフィルター処理されたソリューションの例を次に示します。
でフィルター処理されたソリューションのスクリーンショット
このソリューションでは、ClassLibrary1 は ProjectA と ProjectB の両方で使用されるため、ClassLibrary1 はプロジェクト参照として一覧表示されます。
Visual Studio によって生成されるソリューション フィルター ファイルを次に示します。
{
"solution": {
"path": "MyApplication.sln",
"projects": [
"MyApplication\\MyApplication.csproj",
"ProjectA\\ProjectA.csproj"
]
}
}
この例では、(コマンド MSBuild [options] MyFilter.slnfを使用して) フィルター処理を有効にしてビルドすると、MSBuild は、ソリューション フィルター ファイルに明示的に一覧表示されるため、MyApplication と ProjectA をビルドします。 ProjectA のビルドの一環として、ProjectA が依存しているため、MSBuild は ClassLibrary1 をビルドします。 ProjectB はビルドされていません。 (この説明では、クリーン ビルドを前提としています。プロジェクトが以前にビルドされている場合は、既に -date up-toされているプロジェクトのスキップに通常のルールが適用されます)。