ビルドを Visual Studio SLN ファイルの使用から MSBUILD sript の使用に移行したいと考えています (SLN ファイルで 100 プロジェクトに近づいています) が、コードを編集するときに SLN ファイルを二重に維持したくありません。 Visual Studio 内。
私が望むのは、MSBUILD スクリプトの依存関係ツリーを作成し、Visual Studio から任意の MSBUILD スクリプトを選択して、SLN ファイルのように使用できるようにすることです。すべての依存プロジェクトが自動的に含まれます。
Visual Studio でこれを行うことはできますか? MSBUILD スクリプトから SLN ファイルを動的に作成できる既存のツールはありますか? これを行うためのツールを作成しようとした人はいますか?
（コンパイルされたdllではなく）参照プロジェクトに依存している限り、またXmlの経験がある限り、このようなものを作成するのはそれほど難しいことではありません。最初のcsprojファイル（Xml）を解析し、プロジェクトへのすべての参照を読み取ります。彼らはこのように見えます：
<ProjectReference Include="..\..\src\Test\Test.csproj" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Project>{ab709f59-aa17-4297-b827-101d086586e1}</Project>
<Name>Test</Name>
</ProjectReference>
ご覧のとおり、関連するcsprojファイルへのパスがあります。関連するプロジェクトへのすべてのパスを収集し、すべてのファイルを処理するまで、これらの各パスに対して同じことを再帰的に実行します（複数のプロジェクト（重複）から参照されるプロジェクトに注意してください。そうしないと、無限ループに陥ります）。csproj要素は空でない名前空間に属しているため、Xmlを解析するときにこれを考慮する必要があることに注意してください（.NET Xml APIはこれらを処理できます）。すべてのプロジェクト（パス、名前、GUID）を収集してから、slnファイルを作成するか、新しい参照を見つけるたびにその場で作成することができます。
csprojをそのままビルドできます。すべてのcsprojのアイテムグループを作成してmsbuildに渡すと、依存関係の順序が決定されます（dll参照ではなくプロジェクト参照がある場合）。自動的に。
プロジェクト参照はビルドを遅くし、dll参照を使用してビルドすると、ビルドをはるかに速くすることができますが、トレードオフは、依存関係の順序を知っているか決定する必要があることです。そうすれば、混乱が確実になります。
sln内の100のプロジェクトは多く、VSが遅くなります。私はエンティティごとにslnを使用する傾向があります。たとえば、モノリシックビルドやslnではなく、WebサイトやWebサービスなどです。
私は 2011 年 12 月に *.sln ファイルを動的に生成するツールを書きました。ビルド システム用に 600 を超えるプロジェクト ファイルを維持していますが、これはソリューションとしては非常に大きすぎます。少なくとも、実際に IDE に読み込もうとするソリューションです。
それにもかかわらず、MSBuild によって読み込まれる動的に生成されたソリューション ファイルを使用します (Devenv.exe ではありません)。私の知る限り、誰もそのソリューション ファイルを IDE に読み込もうとしません。
とにかく、私が作成したツールは、ソース コードを含むディレクトリをパラメーターとして受け取ります。その中のすべての *.vcxproj および *.csproj ファイルを再帰的に検索して見つけます。次に、プロジェクト ファイルごとに、MSBuild API を使用してファイルを解析します。各ファイルを解析するときに、他のプロジェクト ファイル間の依存関係を探します。*.lib ファイルのネイティブの依存関係を見つけるのに十分スマートです。#using のようなコード ファイル自体で依存関係を指定するマネージド c++/CLI の依存関係を見つけるのは十分にスマートです。また、アセンブリ参照を使用して通常の管理された依存関係を見つけることもできます。また、他のいくつかの方法で依存関係を見つけます。
次に、これらすべての依存関係を取得して、ソリューション ファイルを生成します。ご不明な点がございましたら、お気軽にお問い合わせください。
既存のツールについては知りません。これがあなたの質問に直接答えるものではないことは承知していますが、大規模なプロジェクトに取り組んだ私の経験を共有できます。
私たちは常に、大きなソリューション ファイルを、関連するプロジェクトのいくつかの小さなファイルに分割してきました。次に、1 つまたは 2 つのビジュアル スタジオを開いて、作業したいプロジェクトを表示できます。
次に、各ソリューションを順番にビルドして製品全体とインストーラーを生成する msbuild スクリプトがあります。
動的なソリューション生成は必要ありません。そのようなものを維持するにはかなりの労力がかかるのではないかと心配しています。また、動的に生成されたさまざまなソリューションに常に取り組んでいるため、物事がどこにあるかを覚えていないという状況になるのではないかと心配しています。いくつかの固定ソリューション ファイルを使用して、プロジェクトをいくつかのフォルダーに整理することができます。そうすれば、何がどこに行くかについて頭の中である種の整理ができます。まともな組織があれば、2 つのソリューションを開いて同時に作業する必要がある場合がたまにしかないことがわかります。
他のソリューション間で共有される定義を持つプロジェクトを含む 1 つ以上の基本/コア ソリューションがあります。しかし、それらを使用するより高いプロジェクトと一緒に、ベースからすべての依存プロジェクトを複製する必要があるとは思いませんでした。依存プロジェクトをソリューションに含めなくても、依存プロジェクトを介してデバッグできます。変更が必要な場合は、基本ソリューションを開いて編集およびビルドし、続行します。
Google がこの目的のために作成したGYP (Generate Your Projects) (プロジェクトとソリューション ファイルの作成) を見て、必要に応じてビルドを自動化することもできます。
彼らのウィキから：
GYP はもともと、Chromium をビルドするためのネイティブ IDE プロジェクト ファイル (Visual Studio、Xcode) を生成するために作成されました。
[..]
また、gyp の設計の一部は、ソースから完全に構築された大規模なプロジェクトでの Google での経験に基づいています [..]。
私は現在、Visual Studio 2012 の *.vcxproj および *.sln ファイルを生成するために使用されるChromium Embedded Frameworkで作業するときに使用します。この場合、259 個のプロジェクトで 1 つのソリューション ファイルが生成されます。古いバージョンの Visual Studio を使用している場合は、*.vcproj ファイルも生成されます。
補足として、これは、プロジェクト ファイルをバージョン管理システムから除外し、新しい開発者のためにプロジェクトをすばやくセットアップするための優れた方法です。
編集:質問をもう一度読んだ後、MSBUILD スクリプトから *.gyp ファイルを生成できるとは思いませんが、それでも変換作業を行う価値はあります。
編集2：特に有望と思われるgypfy.pyで、役立つ可能性のある別の回答を見てください：https://stackoverflow.com/a/9387350/1412348