以前は5つのプロジェクトがあり、C＃アプリケーションにはそれぞれ5〜10個のディレクトリがありました。これを10個のプロジェクトに変更し、それぞれに2〜3個のディレクトリを含めることができます。
私のWebアプリケーションでは、以前は2〜3のようだったのではなく、これらの10のプロジェクトを参照しています。
この方法で開発を続け、アプリケーションが大きくなるにつれてプロジェクトを追加すると、パフォーマンスが低下しますか？私が疑問に思っているのは、1回のオフロード時間、メモリ使用量（プロジェクト自体に格納されている、参照するすべてのDLL）、およびコードを1つのプロジェクトのオブジェクトから別のプロジェクトに移動する必要がある時間です。
これらすべてのプロジェクトを参照する場合、アセンブリをロードするためのジッターにはわずかなペナルティがあります。
しかし、私はあなたが間違った質問をしていると思います。クラスまたはディレクトリの数に基づいて、コードを異なるアセンブリに分割しないでください。もしそうなら、1つのプロジェクトが最適です。
内部で何ができるかを気にする必要があります。これらの10個のアセンブリがある場合、プログラムのどの部分をプログラムの残りの部分から隠すことができます。プロジェクトの一部が他のプロジェクトを参照する必要がない依存関係のツリーはおそらくありますか？
いくつのテキストファイルがどこに行くかではなく、それがあなたの呼びかけであるべきです。
パフォーマンスの違いはごくわずかです（起動時間は数ミリ秒遅くなる場合があります）。アプリケーションアーキテクチャが複数のプロジェクトで優れている場合は、それを選択してください。
はい。ただし、実行時に顕著ではありません。
Visual Studioは、複数のプロジェクトの読み込みに時間がかかります。5〜10のプロジェクトではおそらく気付かないでしょうが、30〜40のプロジェクトでは気づき始めます。
コンパイルは（一般的に）遅くなります。これは、プロジェクトの依存関係を、それらに依存するプロジェクトの出力フォルダーにコピーする必要があるためです。より多くのプロジェクトがある場合は、コピーする出力ファイルがより多くあります。各プロジェクトの出力フォルダーを同じ場所に設定することでこれを軽減できますが、これはWebアプリケーションプロジェクトではより困難であり、とにかく面倒です。
実行時に、アセンブリを解決するときに、これらすべての余分なディスクアクセスに関連するパフォーマンスの低下が発生します。
ただし、実際にコードを実行する場合、パフォーマンスへの影響は（あるとしても）ごくわずかです。あるアセンブリで別のアセンブリよりもコードを呼び出すのに費用はかかりません（一度ロードされてJITされ、インライン化されていないと仮定すると）。