私には、相互に依存する 40 を超える C# および C++/CLI プロジェクトを含む Visual Studio 2008 ソリューションがあります。このソリューションでの作業は非常に遅く、通常は一度に必要なプロジェクトは数個だけです。そこで、ソリューションを 3 ～ 5 個のプロジェクトを含む複数のソリューションに分割することにしました。また、すべてのプロジェクトで「完全な」ソリューションを維持したいと考えています (自動ビルドや、すべてのプロジェクトに影響する大規模なリファクタリング アクションに便利です)。(これがここでの主な条件です。そうでなければ、もちろん、プロジェクトをソリューションに分割するのは簡単です。)
それを実行する方法はありますか?
私の最初のアイデアは、新しい空のソリューションを作成し、既存のプロジェクト ファイルの一部をこれらの各ソリューションに追加するというものでした。しかし、そうすると、VS はプロジェクト参照を見つけられなくなります (同じソリューション内にないため)。参照を「通常の」ファイル参照として追加できます。しかし、そうすると、依存関係が失われるため、「完全な」ソリューションは機能しなくなります。
編集：
皆さんの回答に感謝します。質問を少し明確にしたいと思います。私のソリューションには、テストを除いて 44 個のプロジェクトが含まれています。したがって、2 つの部分に分割することは実際には考えておらず、5 ～ 8 つの部分に分割することを考えています。そのため、VS が完全なビルドの正しいビルド順序を判断できる「完全な」ソリューションを保持したいと思います。8 つの個別のソリューションのビルド順序を手動で (たとえば、バッチ ファイルで) 維持すると、エラーが発生しやすくなるように思われます。
また、プロジェクトを「論理的に」グループ化したい（つまり、通常、1つのソリューションで一緒に変更されるプロジェクトをグループ化したい）。しかし、そのグループ化は依存関係と常に一致するとは限りません。たとえば、依存関係チェーンがあるとします。
A is referenced by B is referenced by C is referenced by D
そして、A と D は一緒に変更されることが多いが、B と C はほとんど変更されないとします。(当然、そのためには、B が使用する A のインターフェイスは変更されないままである必要があります。) 次に、A と D を 1 つのソリューションに、B と C を別のソリューションに含めます。ただし、すべてのプロジェクトを最初から構築する場合、A、B、C、および D を含む完全なソリューションが手付かずの場合にのみ機能します。そのビルドが完了すると、A/D ソリューションを開いて、その 2 つのプロジェクトのみを編集/ビルドできます。
しかし、私の問題に対するエレガントな解決策はないのではないかと心配しています。（しゃれではありません）
ベストアンサー1
検討したいもう 1 つの方法は、使用していないプロジェクトをアンロードすることです。作業していないプロジェクトを右クリックしてアンロードするだけです。これにより、Visual Studio の動作がはるかに速くなります。これにより、VS メモリから多くのものが排除されます。
他にできることとしては、ビルド定義を編集し、変更されていないプロジェクトを削除することです (リンクの状況に応じて、何が必要か、何が更新されたか、何が不要かがわかります)。
解決-> 右クリック ->構成マネージャー-> チェックを外す建てる変更されず、必要のないプロジェクトについてはすべてのビルド他の理由で。これにより、バイナリがダンプされる場所から、これらのプロジェクトの最後のビルドの出力を使用することで、ビルドが高速化されます。
注記：プロジェクトを右クリックしてビルドし、出力を更新してからソリューションを再構築して最新の状態にすることができます。ビルド構成を何度も変更して含める代わりに、これを実行できます。
アップデート
パフォーマンスを重視する (たとえば、VS 2010 まで待つなど) という精神で、他の Stack Overflow の質問に記載されている対策を講じましたか。Visual Studio でのコンパイル時間が非常に遅いそしてVisual Studio の最適化これらは大きな違いを生み、パフォーマンスを許容できるレベルにまで引き上げる可能性がある。VS 2010 の出荷を待つ
パフォーマンスに良い影響を与える可能性のあるその他のいくつかの事項:
- 私SSDを強くお勧めしますオプションであれば、SSD をお勧めします。コストはかかりますが、間違いなく価値があります。ソリューション内のファイルが多いほど、メリットが大きくなります。職場で新しいマシンを注文したとき、開発チーム全体が SSD を選択しました。その違いは驚くべきものでした。大規模なソリューションを扱う場合、ドライブを回転させ、ファイルを読み込むためだけに物理ヘッドを何千もの場所に切り替えます...そこで SSD が勝り、シーク時間は実質的に 0 ミリ秒です。
- 同様に、無料のソリューションは優れたドラフラグメンターです（物理的な場合のみ、SSDをデフラグしないでください）は大きな違いをもたらします...Visual Studioを念頭に置いて何かを使用する場合。私はお勧めしますマイデフラグ(フリーウェア) デフラグ用のネイティブ アルゴリズムはディレクトリ構造を念頭に置いているため、少なくとも物理ドライブでは、ソリューションに必要なファイルを切り替えるのにそれほど時間がかかりません。ファイルはすべてディスク上で非常に近くにあります。
- 上記のSSDの提案では、安価なドライブと高速ドライブの間でSSDのパフォーマンスに大きな差があることを念頭に置いて、ここで少し調査してください。システムについて心配する必要はありません。無料のユーティリティでgPartedなどOS ドライブ全体を非常に簡単に移動でき、古いドライブはバックアップのままになります... SSD に C のデータが収まる限り、問題ありません。