私は現在、非常に大きなライブラリに取り組んでいます（500万行のコード、VS2005のC ++、1つのソリューション、100近くのプロジェクト）。コンパイルを配布し、増分リンクを使用しますが、ソースの小さな変更後の再コンパイルと再リンクには、数分（通常は少なくとも3分）から1時間近くかかります。
これは、コード/ビルド/デバッグの変更サイクルが非常に長くなる傾向があり（私の好みです！）、ビルド中に「フロー」を失うのは非常に簡単です。通常、有用なことを行う時間はあまりありません（おそらく少しの電子メール、そうでなければオンラインでいくつかの記事または本の数ページを読んでください）。
新しいコードを書いたり、主要なリファクタリングを行ったりするときは、一度に1つのファイルだけをコンパイルしようとします。しかし、たとえばデバッグ中は、本当に神経質になります。
どうすれば時間を最適化できるのでしょうか。私はその状況で私だけではないと思います：あなたは何をしますか/しますか？
そのレベルでの開発についてはよくわかりませんが...複数のソリューションに分けるのは良い考えのようです。あなた/あなたの顧客が本当に主張するならば、あなたはそれらすべてを単一の.dllに統合する最後の「出荷前」ステップを持つことができます。
たとえば、さまざまなアセンブリ（System、System.Drawing、System.Windows.Forms、System.Xml ...）がある.NETFrameworkと比較してください。おそらく、これらすべてが異なるソリューションにあり、互いのビルド結果を参照している可能性があります（単一のソリューションにあり、互いにプロジェクトとして参照しているのとは対照的です）。
一歩一歩...
唯一の解決策は、コード ブロックの分離を開始することです。実装の漏れがあまりない場合 (以下の ** を参照)、背後にあるクラスを分離するファサードの構築を開始します。これらのクラスを別のプロジェクトに移動し、ファサードが起動時に dll をロードするようにし、呼び出しをファクトリ メソッドにリダイレクトします。
かなり安定している領域/ライブラリを見つけることに集中し、それらを分離されたライブラリ dll に分割します。それらを個別にビルドしてバージョン管理すると、統合の苦労を避けることができます。
私は過去にそのような状況に陥っていましたが、唯一の方法は忍耐をもって仕事をすることです.
ちなみに、コードを分割することの良い副作用は、インターフェイスがきれいになり、出力 dll サイズが小さくなることです!!. 私たちのプロジェクトでは、コードをサフリング/再編成し、不要なインクルードの量を減らすことで、最終出力を 30% 削減しました。
幸運を！
** --> obj->GetMemberZ()->GetMemberYT->GiveMeTheData(param1, param2) を呼び出す消費者
@Domenic：確かに、それは良いことです...しかし、チーム全体がしばらくの間それに取り組んできました、そして彼らが成功するまで、私たちは単一の.dllとかなりモノリシックなもので立ち往生しています:-(