他のいくつかのプロジェクトといくつかの「プラグイン」アセンブリへの参照をまとめたプロジェクト「ProjA」があります。これらの参照はすべて、[ローカルコピー]が[True]に設定されています。プラグインアセンブリ（プロジェクト参照）のコードは、「ProjA」で直接参照されるのではなく、DI/Ninjectを介してロードおよび配置されることに注意してください。（したがって、プラグインアセンブリを出力フォルダーに入れる方法として、これらのプロジェクト参照を使用しています。理由については、以下を参照してください）
ProjAを参照するプロジェクト「ProjB」もあります。参照されているプラグインアセンブリを使用して、ProjAコードを呼び出します。
問題は、それが機能しないことです。プラグインアセンブリは、ProjA出力フォルダー（「ローカルにコピー」されます）からProjB出力フォルダーにコピーされません。したがって、Ninjectはそれらをロードせず、失敗します。
だから私の2つの質問：
- ProjAがプロジェクトP1、P2、P3、P4を参照し、copylocalをtrueに設定するようにVS/msbuildに指示した場合、ProjAを機能させるためにメイン出力アセンブリのみが必要であると想定するのはなぜですか？別の考え方をさせることはできますか？
- プラグインとプラグインを使用するプロジェクト（現在はプラグインの固定セット、したがってこのルート）の間のビルド依存関係をVSに認識させる方法として、プラグインアセンブリにローカルコピー参照を追加することは理想的ではないと思います。次に、プラグインアセンブリを「コンテンツ」としてプロジェクトに追加することは機能すると思いますが、2つの問題があります。1）TFSソース管理。プラグインプロジェクトには、ビルドするための書き込み可能なターゲットが必要です。おそらく、コンテンツファイルは「チェックイン」されます。2）一部のプラグインには独自のコンテンツがあります。参照を使用すると、何かが見つからないことを心配する必要はありません。コンテンツルートに行くには、別のプロジェクトのビルド出力フォルダーを参照し、そのすべてのコンテンツを含める必要がありますが、PDBは含めないでください。
また、プラグインプロジェクト（理想的ではありません：別のソリューションからこの新しいソリューションにそれらをプルしています。ビルド後のステップを追加すると、他のソリューションが台無しになる可能性があります）またはプロジェクトのビルド後の手順を検討して遊んでいますこれはそれらに依存します（これは問題ありませんが、相対パスを使用したXCopyであり、プロジェクトの依存関係を手動で設定する必要があります。
私が見逃しているものはありますか、何かアイデアはありますか？プロジェクト参照間でチェーンされたローカルコピーをコピーすると、完全に適合します。