最近、会社のほぼすべてのソースコードを単一のソリューションに移行しました。
どうして？
もともと、私たちは何十ものソリューションを持っていました。ソリューションのプロジェクトの中には、別のプロジェクトのプロジェクトを再利用するものがあり、パッケージマネージャーの使用を気にする人はいませんでした。ほぼすべての場所で使用されているプロジェクトを大幅に変更した日は、数日または数時間の会社全体の仕事が数日または数週間失われることを期待しています。最悪の部分は、あなたも知ることができないということであるものを正確に変更によって影響を受けるであろう。
すべてのコードを1つのソリューションにマージすることは代替手段でした。現時点ではうまく機能しており、依存関係を簡単に追跡できます。メソッドを変更するだけでなく、この変更がコードベースのどこにでも持つ可能性のある影響を追跡したいですか？Visual Studioはこれを簡単に行うことができます。私にとっては、成功です。
継続的な統合も簡単になりました。コンパイルおよびデプロイする1つのソリューション。設定するものはほとんどありません。
スケーラブルですか？
パフォーマンスに関しては、Visual Studioに非常に驚きました。たとえば、50のプロジェクトを含むソリューションで泣き出そうと思いました。今日、200以上のプロジェクトがあります。Visual Studioは、20個しかないかのように管理するのに十分な拡張性があるように見えました。はい、時間がかかることがあります。コードコントラクト、デフォルトで有効になっているコード分析などを使用してすべてのプロジェクトを再コンパイルする場合、しばらく時間がかかると予想されます。しかし、10個ほどの速さで200個のプロジェクトをコンパイルすることを期待する人はいません。起動時間（コールドスタート、ソリューションの読み込み）は非常に高速です。10個のプロジェクトほど高速ではないかもしれませんが、それでも十分に受け入れられます（5年以上前に購入したマシンで20秒未満）。
さらに進むには、プロジェクトを体系的にアンロードすることをお勧めします（プロジェクトがソリューション内のディレクトリに編成されている場合は非常に簡単です）。誰かが3つのプロジェクトのロードのみを必要とする作業を行う場合、200のプロジェクトすべてをロードする必要はありません（もちろん、依存関係が影響を受けない限り）。
バージョン管理も期待どおりに機能します（問題があればSVNサーバーを使用しています）。私は実際のコンカレント環境で作業したことはありません。たとえば、数十人の開発者が頻繁にコードをコミットしていますが、これで問題が多くなることはないと思います。多くの開発者が同時に新しいプロジェクトを追加する場合に注意してください。.slnファイルをマージするのは簡単なことではありません。
結論
再度決定を行わなければならなかった場合：
それでもすべてを単一のソリューションに移行します。これにより、依存関係の破損による痛みが大幅に軽減され、このメリットだけでも十分に価値があります。すべてのコードを一元化することも良い考えです。これにより、たとえばVisual Studio内で何かを検索できます。また、2つの弱く関連するプロジェクトで作業することもできますが、まだ1つのVisual Studioウィンドウしか開いていません。
また、もう少しNuGetとプライベートNuGetサーバーをホストする機能についても勉強します。NuGetを使用して依存関係を管理すると、いくつかのプロジェクトを共通ソリューションにマージしたくない場合の問題の一部を解決できます。個人的には、そのようなケースはありませんでしたが、他の企業が持っているかもしれないと思います。
最後に、すべての開発者のためにSSDに投資すると、大きな違いが生まれます。ただし、その必要はありません。私の場合、コードベースは通常のハードドライブに保存されています。