次のシナリオが通常のバージョンの VS で実装できるかどうか教えてください。つまり、チーム エディションではありません。まず、私たちのチームは 10 人の開発者と十分に小さく、リポジトリとして SVN を使用しています。ディレクトリ構造はすべての開発者にとって比較的同じであり、簡単にするために次のようになります
ワーキング\デプロイ
ワーキング\ソース
すべてのプロジェクトは「Sources」ディレクトリにあり、出力 dll は「Deploy」ディレクトリに置かれます。
1 つはプロジェクト「CoreLibrary」に取り組んでおり、出力 dll は CoreLibrary.dll であり、2 つ目は「SomeLibrary」プロジェクトに取り組んでおり、参照として CoreLibrary.dll を使用しています。これは単純化された状況です。実際には、このプロジェクトは、他の開発者の責任の対象となる多数の dll に依存する可能性があります。このシナリオでは、SomeLibrary がコンパイルされた後に CoreLibrary が変更されたときに、このような状況になる可能性があります。たとえば、他の開発者に参照を更新するように通知するのを忘れていました。そして、この変更により SomeLibrary プロジェクトがコンパイルされなくなりますが、それは実行時にのみわかります -) したがって、これを回避するために、すべてのプロジェクトを 1 つの複合ソリューションに結合することにさらに決定しました。そのため、ソリューション全体のビルドがすべて互換性があることを意味する場合。しかし、問題が 1 つあります。このためには、ソース プロジェクトの依存関係を dll からプロジェクトに変更する必要があります。また、スタンドアロン プロジェクトを開くと、このリファレンスの反対側に感嘆符アイコンが表示されますが、プロジェクトは引き続きコンパイルできます。
つまり、結論として、dll を介してプロジェクト間 (各プロジェクト - アトミック機能) を参照しています。アトミシティは、1 つの「アトム」を変更するときに、この変更が他の依存アトムと互換性があるかどうかを確認する必要があることにつながります。これは、最新のソースをロードしてコンパイルを試みる全体的なソリューションを持つ方が便利です。ただし、プロジェクト間の依存関係を dll からプロジェクトに変更する必要があります。ソース スタンドアロン プロジェクトの参照が変更されるため、これは「正しくない」ようです。すべての開発者に 1 つの大きなソリューションを作成し、すべてのソースを再コンパイルするよう強制し、彼のプロジェクトだけでなく、それも悪いことです。