このトピックに関する多くの投稿がありますが、私はまだ「本当の」解決策を見つけていません。
MSBuildプロジェクトファイル（つまり、プロジェクトとファイルの参照を介したVisual Studioプロジェクトファイル）を使用して、依存関係ツリー（コンパイル時とランタイムの両方）をどのように管理しますか？
コンパイル時の参照がない場合、実行時の依存関係がある場合、およびcopy-local = trueの場合でも、子プロジェクトからのプロジェクト参照はアプリケーションのbinディレクトリにコピーされないことはよく知られています。したがって、緩く結合されたコンポーネントはコピーされません。
この問題を解決するためのハックは、copy-local=trueを使用して親プロジェクトに依存関係を含めることです。ただし、これは基本的に依存関係ツリーを破壊します。これは、依存関係がどこにあるかがわからなくなったためです。最終的に、アプリが成長して変形すると、DLL地獄のバージョンになります。親プロジェクトは最終的に数十から数百のdllになり、そのほとんどは子プロジェクトのdllの実行時の依存関係です。
もう1つのハックは、カスタムターゲットファイルを作成し、それをすべてのプロジェクトファイルから呼び出すことです：http：//blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html。しかし、確かにもっと良い選択肢があります。これはそのようなパンとバターのことです。Java開発者は、このような些細な問題に対処する必要はありません。
私が収集できることから、この問題を解決するMicrosoftの方法は、すべての開発、テスト、および本番マシンのGACにすべての依存関係を登録することです。しかし、これは愚かで迷惑です。私はこのオプションと教育を受けた反論をわざわざ与えることはしません。
GACオプションを避けて、MSBuildを使用して、ランタイムのみの依存関係を含む依存関係ツリーを管理するにはどうすればよいでしょうか。マイクロソフトはどのようにそれを行いますか？確かに、上記のリンクにあるようなカスタムターゲットファイルは実行されません。
エンタープライズ.NETのバックグラウンドを持つ誰かがステップアップして、これについて実際のアドバイスを提供してくれることを願っています。それ以外の場合は、すべてのビルドスクリプトをNAnt（shudder）で書き直す必要があります。
皆さんありがとう。
アップデート
いくつかのコメントに応えて、以下は私の現在のプロジェクトからの問題の実際的な例です。
このアプリは、一連のWCFサービスを公開するWebアプリケーションプロジェクトです。外部サービスクラスを含む外部ドメインDLLと、内部サービスPOCO、ドメインオブジェクト、およびDAOを含む内部ドメインDLLがあります。すべての内部ドメインクラスのインターフェイス（DTO）を含む個別の統合DLLがあり、外部ドメインと内部ドメインを完全に分離できます。すべてがSpring.netに接続されています。これが明確であることを願っています。さらに詳しい説明が必要な場合はお知らせください。
私の現在のビルドプロセスは、MSBuildを使用してWebアプリケーションのデプロイメントパッケージを生成することです（TFSビルドで）。したがって、ソリューション全体が最初に構築されますが、Webアプリケーションからの出力のみがパッケージ化されます。したがって、Webアプリケーションは依存関係ルートとして扱われ、緩く結合された子参照は、「copy-always = true」に設定されている場合、ビルド時にコピーされるはずです。
したがって、Webアプリケーションには、サードパーティライブラリへの多くの参照とサードパーティライブラリに必要なさまざまな間接的および緩く結合された依存関係を含む内部ドメインDLLへの参照を含む外部ドメインDLLへの参照が含まれます。
この問題は、実行時にNHibernateが必要とするoracle.dataaccessなどの内部ドメインDLLにサードパーティの依存関係がある場合に発生します。これらのDLLに「copy-always=true」を設定しても、Webアプリパッケージにコピーされません。それらをパッケージに含めることができる唯一の方法は、これらのDLLをWebアプリの参照に追加することです。意味のある依存関係ツリーがなくなったので、これは行いたくありません。
これで問題が明確になることを願っています。不明な点がありましたらお知らせください。この種のものを説明するのは難しいです。
誰かが同様の問題を抱えている場合は、声を上げてあなたの経験を共有してください。