ソリューションに多くのプロジェクトがある場合、ビルド時間は劇的に増加します。C＃コンパイラは、コピーされるすべてのdllを再分析するため、ある意味で「ローカルコピー」オプションは悪です。
考えられる解決策については、PatrickSmacchiaによる次の2つの記事をご覧ください。
つまり、ビルド時間はプロジェクトの数に応じて指数関数的に増加するため、必要なプロジェクトをマージして、必要なプロジェクトの数を最小限に抑えるようにする必要があります。プロジェクト/アセンブリは、アーキテクチャの境界を強制するためによく使用されます（そして、私もこのように使用します）が、これは大規模なプロジェクトには適していません。代わりに、 NDependなどのツールを使用して、アーキテクチャルールを検証し、タイプ間の循環依存を防ぐことができます。これを行うには、名前空間でタイプをグループ化し、機能ごとにタイプをグループ化します。
ただし、1つの注意が必要です。私は、オープンソースプロジェクトの1つであるSimpleInjectorのアセンブリを介したコードベースのパーティショニングに関するアドバイスを使用しました。プロジェクトは他のプロジェクトを直接参照するのではなく、アセンブリのみを参照します。これの欠点は、VSがプロジェクトについて何も知らないため、Visual Studioの[参照に移動]オプション（F12）が機能しなくなることです。コードにジャンプする代わりに、VSはタイプのAPI定義のみを含む生成されたファイルにジャンプします。これについてPatrickSmacchiaに相談した後、彼はこれを経験したことがないと説明しました。これは、彼のチームがコードにジャンプする方法をまだ知っているように見えるResharperを使用しているためです。
結論として、これを試す必要があり、すべての開発者にResharperなどの生産性ツールを提供することをお勧めします。これにより、「コードにジャンプ」することができます。また、NDepend（NDependは素晴らしい）などのツールが必要であり、それをビルドプロセスに統合して、開発者がアーキテクチャルールに違反しないようにします。
コンパイル時間を短縮するもう1つのオプションは、コアライブラリチームが「外部」になるようにチームを分割することです。これらのチームは、他のチームがソリューションに含めることができるDLLとして再利用可能なライブラリを開発、バージョン管理、およびリリースできます（そして、その特定のバージョンをソース管理にチェックインします）。これにより、これらのチーム（おそらく製品チーム）がベースライブラリをコンパイルする必要がなくなり、これらのDLLが（ソリューション内で）1つのフォルダーに配置されるため、Pattrickの記事で説明されているようにパフォーマンスがすぐに向上します。これは、開発ボックスとビルドサーバーの両方のコンパイル時間にプラスの影響を及ぼします。
このアプローチの欠点は、（再び）そのコードに「飛び込む」ことができず、コアライブラリを開発するプロセスがはるかに厳密になることです。これらのライブラリは再利用可能なフレームワークになり、これらのライブラリのパブリックAPIを簡単に変更することはできません。製品/機能の開発者は、コアライブラリのコードを追加/変更したり、バグを修正したりすることもできず、コアチームが新しいリリースを公開するのを待つ必要があります。ただし、組織の現在の規模（数百人の開発者）では、おそらくこのような構造がすでに必要です（または必要です）。