私たちは、MS Visual StudioでC＃を使用して約12人の開発者によって開発された30〜50のプロジェクトのようなものを含む新しいアプリケーションの開発を開始しています。
アーキテクチャをサポートし、並列作業を可能にするために、アプリケーションモジュールのコンポーネント化に取り組んでいます。
私たちは主張しています：私たちはいくつの解決策を持っているべきですか？
それぞれ15〜30のプロジェクトで1〜2のソリューションが必要であると主張する人もいます。コンポーネントごとにソリューションが必要であると主張する人もいます。つまり、それぞれ約3〜6個のプロジェクトで約10〜12個のソリューションが必要です。
それぞれの方向（または他の方向）の長所/短所と経験を聞いてうれしいです
私は両極端の製品に取り組んできました: 1 つのソリューションに ~100 のプロジェクトを含むものと、それぞれ 4 ～ 5 プロジェクト (テスト、ビジネス レイヤー、API など) の 20 を超えるソリューションを含むものです。
それぞれのアプローチには長所と短所があります。
単一のソリューションは、変更を行うときに非常に便利です。依存関係を処理しやすく、リファクタリング ツールを適切に機能させることができます。ただし、ロード時間とビルド時間が長くなります。
複数のソリューションは、懸念事項の分離を強化し、ビルド/ロード時間を短縮するのに役立ちます。また、焦点が狭く、サービス境界が明確に定義された複数のチームを持つのに適している場合があります。ただし、多くの参照はプロジェクト参照ではなくファイルであるため、リファクタリングに関しては大きな欠点があります。
大部分は小規模なソリューションを使用するハイブリッド アプローチの余地があるかもしれませんが、大規模な変更が必要な場合は、すべてのプロジェクトを含む単一のソリューションを作成してください。もちろん、2 つの別々のソリューションを維持する必要があります...
最後に、プロジェクトと依存関係の構造は、ソリューションの編成方法に影響を与えます。
そして、長期的にはRAMはプログラマーの時間よりも安いということを覚えておいてください...
依存関係を管理するためのソリューションが実際に存在するため、複数のソリューションが依存している場合は、複数のソリューションでプロジェクトを作成できます。ソリューションの数は、実際には依存関係グラフによって異なります。
編集：これは、相互に依存していないプロジェクトを同じソリューションに固執するべきではないことを意味します。これは、依存関係の錯覚を生み出すため、2つのプロジェクトが実際に独立している必要があるときに誰かが実際の依存関係を作成できることを意味します。
私は200近くのプロジェクトでソリューションに取り組んできました。十分なRAMがあれば大したことではありません:)。
覚えておくべき重要なことの1つは、プロジェクトは相互に依存しているということです（依存関係であれ参照であれ）、おそらく同じソリューションにあるはずです。そうしないと、さまざまなプロジェクトがさまざまなソリューションでさまざまな依存関係を持っているときに、奇妙な動作が発生します。
プロジェクト参照を維持したい。相互に依存する2つ以上の個別のプロジェクトのセットでソリューションを安全に分割できる場合は、それを実行します。できない場合は、それらはすべて一緒に属します。
約 130 のプロジェクトを持つソリューションがあります。約 3 年前、vs.net 2003 を使用していたとき、これはひどい問題でした。ソリューションと VSS がクラッシュすることがありました。
しかし、VS.NET 2005 では問題ありません。読み込みだけに時間がかかります。私の同僚の何人かは、使用していないプロジェクトをアンロードしています。高速化するための別のオプションです。
ビルド タイプをリリースに変更することは、別の問題です。しかし、現在は MSBuild スクリプトがあります。VS.NET のリリース ビルドはもう使用しません。
プロジェクト/ソリューションの数を誇張してはいけないと思います。
再利用できるものと再利用されるものをコンポーネント化します。そうでない場合は、コンポーネント化しないでください。透明性が低下し、ビルド時間が長くなるだけです。パーティション化は、フォルダーまたは論理クラス構造を使用してプロジェクト内で実行することもできます。
実際のソリューションの数は重要ではないと思います。さらに重要なのは、機能的な線に沿って物事を分割することです。ばかげた、不自然な例として、外国のWebサービスとの相互運用を処理するライブラリのクラッチがある場合、それは解決策になります。動作する必要のあるDLLを含むEXEは別のものになります。
1つのソリューションに含まれる非常に多くのプロジェクトについての唯一のことは、参照とビルド順序が混乱し始めることです。
原則として、プロジェクトの数を減らし（プロジェクトをもう少し一般的にする）、開発者にそれらのプロジェクトのソース管理を共有させますが、これらのプロジェクト内の機能をサブ名前空間で分離します。
他の回答でも言われていますが、おそらくもう一度言う価値があります。
プロジェクトの依存関係は、依存関係に変更があった場合に依存プロジェクトを再構築できるという点で優れています。
アセンブリファイルの依存関係を作成する場合、VSまたはMSBuildが一連のプロジェクトをビルドする必要があることを知る方法はありません。何が起こるかというと、最初のビルドで、変更されたプロジェクトが再ビルドされます。ビルド出力に依存関係を置いている場合は、少なくとも2番目のビルドで、それに依存するプロジェクトがビルドされます。しかし、チェーンの最後に到達するために必要なビルドの数は不明です。
プロジェクトの依存関係により、すべてが整理されます。
したがって、プロジェクトの依存関係が確実に使用されるようにするために必要な数（または少数）の回答があります。
チームがソースコードのチェックインではなく、より正式なリリースメカニズムを持つ機能領域に分割されている場合は、それらの行に分割するのが良い方法です。そうでない場合は、依存関係マップが友だちになります。
必要な数だけ用意する必要があります。ハード リミットやベスト プラクティスはありません。プロジェクトとソリューションとは何かについて練習して読み、そこから必要なものについて適切なエンジニアリング上の決定を下します。