さまざまなチームによって管理されているさまざまなソリューション/プロジェクトがたくさんあります。このソリューションでは、別のチームが所有する複数のプロジェクトを参照する必要があります。これらの依存関係をプロジェクト参照として追加したくありません。そのコードを変更するつもりはなく、単に使用したいだけだからです。また、ソリューションにはすでにかなりの数のプロジェクトがあり、Visual Studio の速度が低下するため、これ以上多くのプロジェクトを追加したくありません。そのため、これらのプロジェクトを別のソリューションで構築し、ファイル参照としてソリューションに追加しています。
私の質問は、人々はこれらの種類の依存関係をどのように管理しているのでしょうか? これらのプロジェクトへの変更を探し、それらをビルドし、dll をソース管理にチェックインした後、それらを他のサードパーティの依存関係のように扱う自動化されたプロセスを用意する必要がありますか? これを行うための推奨される方法はありますか?
必ずしも探しているものではないかもしれませんが、1 つの解決策は、依存する各サブシステムにリリースを実行させることです。このリリースは、MSI インストールの形式、またはアセンブリの単なるネットワーク共有の形式である可能性があります。重要な変更が加えられた場合、そのチームはあなたに知らせることができ、インストールまたはスクリプトを実行してファイルをコピーすることができます.
リリースを取得したら、それらを GAC に入れることができます。そうすれば、それらをプロジェクトの bin フォルダーにコピーすることを心配する必要がなくなります。
別の解決策は、ビルド サーバーまたは何らかの継続的インテグレーションを使用している場合、ビルド後のステップまたはプロセス ステージング ファイルを使用することです。いつでも、他のチームの開発者が新しいファイルを取得したり、スクリプトまたはバッチ ファイルをローカルにプルダウンしたりすることができます。
編集 - 別の解決策なぜこれらの依存関係があるのか を尋ねるのが最善かもしれません。アプリケーションの一部をビルドするときにローカルでそれらが本当に必要ですか? ソリューションの依存関係をモックアウトして、単体テストのコーディング、ビルド、および実行を可能にできますか? 実際のアプリケーションは、DEV/Test/Prod 環境でこれらを接続します。ソリューションを切り離して依存関係をなくしておくことは、個々のチームにとってより良いソリューションになる可能性があります。アプリケーションが実際の設定で実行される場合、統合と結合はそのままにしておきます。