Visual Studioの大規模ソリューションのベストプラクティス（2008）
約100以上のプロジェクト（ほとんどがC＃）を使用したソリューションがあります。当然、オープンとビルドの両方に時間がかかるため、このような獣のベストプラクティスを探しています。私が答えを得ることを望んでいる質問の行に沿って、次のとおりです。
- プロジェクト間の参照をどのように最適に処理しますか
- 「ローカルコピー」をオンまたはオフにする必要がありますか？
すべてのプロジェクトを独自のフォルダーにビルドするか、すべてのプロジェクトを同じ出力フォルダーにビルドする必要があります（すべて同じアプリケーションの一部です）
ソリューションのフォルダーは、ものを整理する良い方法ですか？
ソリューションを複数の小さなソリューションに分割することはオプションですが、リファクタリングとビルドの頭痛の独自のセットが付属しているので、おそらくそれを別のスレッドに保存できます:-)
私が書いたこれら2つのMSBuildの記事に興味があるかもしれません。
MSBuild：信頼できるビルドを作成するためのベストプラクティス、パート1
MSBuild：信頼できるビルドを作成するためのベストプラクティス、パート2
具体的には、パート2には、大きなソースツリーを構築するセクションがありますをご覧ください。
ただし、ここで簡単に質問に答えるには：
- CopyLocal？必ずこれをオフにしてください
- 1つまたは複数の出力フォルダーにビルドしますか？1つの出力フォルダーにビルドします
- ソリューションフォルダ？これは好みの問題です。
イブラヒム・ハシミ
マイブック： Microsoft Build Engine内：MSBuildとTeam Foundationビルドの使用
+1 sparingものを整理するのに役立つソリューションフォルダーの使用。
独自のフォルダーにプロジェクトをビルドする場合は+1。最初に共通の出力フォルダーを試しましたが、これにより、古い参照を見つけるのが微妙で苦痛になります。
FWIW、ソリューションにはプロジェクト参照を使用しますが、最近はおそらくnugetがより良い選択ですが、svn：externalsはサードパーティと（フレームワークタイプの）社内アセンブリの両方でうまく機能することがわかりました。 HEAD svn：externalsを参照するとき（有罪として有罪:)
頻繁に使用しないプロジェクトをアンロードし、SSDを購入します。 SSDはコンパイル時間を改善しませんが、Visual Studioを開く/閉じる/ビルドする速度が2倍速くなります。
対処すべき109のプロジェクトがあるため、同様の問題があります。経験に基づいて元の質問に答えるには：
1。プロジェクト間の参照をどのように最適に処理しますか
「参照の追加」コンテキストメニューオプションを使用します。 「プロジェクト」が選択されている場合、依存関係はデフォルトで単一のグローバルソリューションファイルに追加されます。
2。「ローカルコピー」をオンまたはオフにする必要がありますか？
私たちの経験ではオフです。余分なコピーは、ビルド時間を増やすだけです。
。すべてのプロジェクトを独自のフォルダーにビルドするか、すべてのプロジェクトを同じ出力フォルダーにビルドする必要があります（すべて同じアプリケーションの一部です）
すべての出力は、「bin」という単一のフォルダーに格納されます。このフォルダーは、ソフトウェアが展開されたときと同じであるという考えです。これにより、開発者のセットアップが展開のセットアップと異なる場合に発生する問題を防ぐことができます。
4。ソリューションフォルダーはものを整理する良い方法ですか？
私たちの経験ではありません。ある人のフォルダ構造は別の人の悪夢です。深くネストされたフォルダは、何かを見つけるのにかかる時間を増やすだけです。完全にフラットな構造ですが、プロジェクトファイル、アセンブリ、名前空間には同じ名前を付けます。
プロジェクトの構造化方法は、単一のソリューションファイルに依存しています。プロジェクト自体が変更されていなくても、これを構築するには長い時間がかかります。これを支援するために、通常、別の「現在のワーキングセット」ソリューションファイルを作成します。私たちが取り組んでいるプロジェクトはすべてこれに追加されます。ビルド時間は大幅に改善されていますが、現在見られている問題の1つは、現在のセットに含まれていないプロジェクトで定義されたタイプに対してIntellisenseが失敗することです。
ソリューションレイアウトの部分的な例：
\bin
OurStuff.SLN
OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]
ここでは、同様の大規模プロジェクトに取り組んでいます。ソリューションフォルダーは物事を整理する良い方法であることが証明されており、ローカルコピーをtrueに設定したままにする傾向があります。各プロジェクトは独自のフォルダーにビルドされ、そこに配置可能な各プロジェクトについて、適切なバイナリの正しいサブセットがあることがわかります。
時間のオープンと時間の構築に関しては、小さなソリューションに割り込むことなく修正するのは難しいでしょう。ここで速度を改善するために、ビルドの並列化（これを行い、UIに統合する方法については、Google「Parallel MS Build」）を調査できます。また、設計を見て、全体の数が少なくなるようにプロジェクトのリファクタリングが役立つかどうかを確認してください。
同様の問題があります。より小さなソリューションを使用して解決します。すべてを開くマスターソリューションがあります。しかし、パフォーマンス。その上悪いです。そのため、開発者のタイプごとに小さなソリューションを分割します。したがって、DB開発者には、関心のあるプロジェクト、サービス開発者、UI開発者に同じことをロードするソリューションがあります。誰かが必要なことを日々行うためにソリューション全体を開かなければならないことはまれです。それは万能薬ではありません-それには、長所と短所があります。 「マルチソリューションモデル」を参照してください この記事では （VSSの使用に関する部分は無視してください:)
ビルドの痛みを緩和するという点では、ビルドの「Configuration Manager ...」オプションを使用して、特定のプロジェクトのビルドを有効または無効にすることができます。特定のプロジェクトを除外し、特定のプロジェクトをターゲットにしているときに使用できる「プロジェクト[n]ビルド」を使用できます。
100以上のプロジェクトに関する限り、ソリューションのサイズを削減することの利点についてこの質問にhammerりたくないと思いますが、ロード時間を短縮することに関しては他の選択肢はないと思います（そしてdevenvのメモリ使用量）。
私がこれで通常行うことは、「デバッグ」プロセスが実際にどのように行われるかに少し依存します。通常、copy localをtrueに設定しませんが。各プロジェクトのビルドディレクトリをセットアップして、すべてを目的のエンドポイントに出力します。
したがって、各ビルドの後に、すべてのdllとすべてのWindows/Webアプリケーションが格納されたフォルダーがあり、すべてのアイテムが適切な場所にあります。 DLLが最終的に正しい場所に配置されるため、ローカルコピーは必要ありませんでした。
注
上記は私のソリューションで機能します。通常、これはWebアプリケーションであり、参照に関する問題は発生していませんが、可能性があります。
約60以上のプロジェクトがあり、ソリューションファイルは使用していません。 C＃プロジェクトとVB.Netプロジェクトが混在しています。パフォーマンスは常に問題でした。すべてのプロジェクトに同時に取り組むわけではありません。各開発者は、作業中のプロジェクトに基づいて独自のソリューションファイルを作成します。ソリューションファイルは、ソース管理にチェックインされません。
すべてのクラスライブラリプロジェクトは、ソースディレクトリのルートにあるCommonBinフォルダーにビルドされます。実行可能/ Webプロジェクトは、個々のフォルダーにビルドされます。
プロジェクト参照は使用せず、代わりにCommonBinフォルダーからのファイルベースの参照を使用します。プロジェクトを検査し、ビルド順序を決定するカスタムMSBuildタスクを作成しました。
数年前からこれを使用しており、苦情はありません。
このような大きなソリューションでは、ベストプラクティスはそれらを分割することだと思います。 「解決策」は、問題の解決策に取り組むために必要なプロジェクトやその他の要素をまとめる場所と考えることができます。 100以上のプロジェクトを、全体的な問題の一部のみのソリューションの開発に特化した複数のソリューションに分割することにより、必要なプロジェクトとの対話を高速化し、問題領域を簡素化することで、特定の時間に対処することができます。
各ソリューションは、担当する出力を生成します。この出力には、自動化プロセスで設定できるバージョン情報が含まれている必要があります。出力が安定したら、依存プロジェクトおよびソリューションの参照を最新の内部配布で更新できます。それでもコードにステップインしてソースにアクセスする場合は、Visual Studioを使用して参照アセンブリにステップインし、ソースコードを取得することもできるMicrosoftシンボルサーバーで実際にこれを行うことができます。
同時開発は、インターフェイスを事前に指定し、完全ではないが開発を希望する依存関係を待っている間に開発中のアセンブリをモックアウトすることで実行できます。
この方法で物理的に分解する場合、全体的な労力がどれほど複雑になるかには制限がないため、これがベストプラクティスであると思います。すべてのプロジェクトを1つのソリューションにまとめると、最終的に上限に達します。
この情報がお役に立てば幸いです。
CopyLocal = falseを設定するとビルド時間が短縮されますが、展開時にさまざまな問題が発生する可能性があります。
「ローカルにコピー」をTrueのままにする必要がある場合、多くのシナリオがあります。最上位プロジェクト、第2レベルの依存関係、リフレクションによって呼び出されるDLL。
CopyLocal = falseの設定に関する私の経験は成功しませんでした。私のブログ投稿で長所と短所の概要を参照してください 「サブシーケンスを理解していない限り、「Copy Local」プロジェクト参照をfalseに変更しないでください。）
それはすべて、ソリューションとプロジェクトが何であるかについての定義と見解に関係しています。私の考えでは、ソリューションはまさにそれであり、非常に特定の要件を解決するプロジェクトの論理的なグループ化です。大規模なイントラネットアプリケーションを開発しています。そのイントラネット内の各アプリケーションには独自のソリューションがあり、exeまたはWindowsサービスのプロジェクトも含まれる場合があります。そして、基本クラスやヘルパー、httphandlers/httpmodulesなどの集中フレームワークがあります。基本フレームワークはかなり大きく、すべてのアプリケーションで使用されます。このように多くのソリューションを分割することにより、ソリューションに必要なプロジェクトの量を減らすことができます。ほとんどのプロジェクトは互いに関係がないためです。
ソリューションにそのような多数のプロジェクトを含めることは、設計が悪いだけです。多くのプロジェクトをソリューションの下に置く理由はないはずです。私が見る他の問題は、特にプロジェクトをより小さなものに分割したい場合、プロジェクト参照に関するものです。
私のアドバイスは、これを実行し、一元化されたフレームワークを開発することです（必要に応じて、エンタープライズライブラリの独自の実装）。 GACを使用して共有するか、ファイルの場所を直接参照して中央ストアを使用できます。集中化されたビジネスオブジェクトにも同じ戦術を使用できます。
DLLを直接参照する場合、copy local false（c：\ mycompany\bin\mycompany.dllなど）を使用してプロジェクトで参照する必要があります。必要なランタイムapp.configまたはweb.configにいくつかの設定を追加して、GACまたはランタイムビンにないファイルを参照するようにします。実際には、ローカルにコピーされているかどうか、またはdllがbinまたはGACにあります。これは、両方の設定がオーバーライドされるためです。ローカルにコピーしてシステムが乱雑になるのは悪い習慣であると思います。しかし、アセンブリ。
GACなしでグローバルにDLLを使用する方法についての私の記事を読むことができます。GACが本当に嫌いです。