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