証拠とリソースが必要です。相互に関連する多くのプロジェクトがあり、それらのコードを取得するための浸透があり、それらの小さなサブセットのみに取り組んでおり、他のプロジェクトのすべてのバイナリの最新バージョンを持っています。 、私が使用しているプロジェクトのみを追加し、参照をdll参照として追加するか、変更したり見たりする必要がない場合でも他のプロジェクトを追加する方が良いですか。
それは個人的な好みですか？なぜ？ベストプラクティスは何ですか？
注: プロジェクト数は増え続けており、現在は 25 プロジェクト、さらに増えています!
一般的な回答ではなく、参照とリンクを提供してください。
注: すべてのプロジェクトは、外部のオープンソース プロジェクトではなく、私たちのチームによって開発されました。
それは個人的な好みではありません。
可能な限り、プロジェクトが生成する DLL ではなく、プロジェクト自体を参照する必要があります。理由は次のとおりです。
考えられる唯一の懸念は、使用しているプロジェクトの数です。あまりにも多くの場合、各部分自体が一貫しており、関連するすべてのプロジェクトを参照する部分にソリューションを分割します。したがって、SolutionA には Project1、Project2、Project3 があり、SolutionB には Project3、Project4、および Project5 がありますが、いずれかをビルドしても一貫したビルドが生成されます。リリースビルド用のすべてのプロジェクトを含むソリューションを維持します。
25 のプロジェクトはまだ管理可能です。また、異なるソリューション フォルダーにグループ化されたプロジェクトを含む 1 つのソリューションを使用することもできるため、VS のソリューション エクスプローラーで 25 個の大きなリストになることはありませんが、それらは同時にビルドされます。
ソリューションに含まれるすべてのプロジェクトは、DLL として参照されます。それは同じです。唯一の違いは、25 のプロジェクトのいずれかで一部のコードを変更する必要がない場合、再構築を行うたびに非常に悪い結果になることが多いということです。
問題は次のとおりです。ソリューションをビルドするときに、参照されているプロジェクトが変更されていないとビルドされません。つまり、ソリューションにすべてのプロジェクトが含まれていないのと同じです。
ただし、クリーン アンド ビルドを実行すると、ソリューションのすべてのプロジェクト DLL が削除され、すべてのプロジェクトが再度ビルドされます。これにはさらに時間がかかります。
現時点で思いつくのはこの2点だけです。