Visual Studio でプロジェクトをアンロードすると、参照しているプロジェクトには、アンロードされたプロジェクトへの参照に関する三角形の警告が表示されます。私は巧妙なことを行うためのマクロを自分で作成しました (プロジェクトの追加/削除を検出し、ファイル/プロジェクトの依存関係からの参照を変換します) が、もっと単純なものが欠けていないとは信じられません。手動で参照を変更する必要がある場合、アンロード機能はどのように使用できますか (そして、「個人的なソリューション/共有プロジェクト」チーム開発パラダイムを壊します)。
(この質問は、Visual Studio での大規模なソリューションの構築に関するこの質問への回答に関連しています。多くのプロジェクトを含むソリューションを持っているが、パフォーマンスを向上させるために未使用のプロジェクトを「アンロード」するという回答もありました。)
ファイル参照を使用する場合、同じソリューションにプロジェクトを含めることの利点は何ですか?
をapp.exe使用utils.dllして のコードを変更したutils.dll場合、それが同じソリューション内にある場合、VS は依存関係に気づき、両方を再コンパイルします。ソリューションに含まれていない場合は、飛び出してutils.dll個別に再コンパイルし、戻って再コンパイルする必要がありますapp.exe。
これは、exeが参照している他のdllの数と、それらが変更される頻度に応じて、多かれ少なかれ重要になります（チーム環境では、私の経験ではdllの変更が頻繁に共有されます）。
また、VS に 100 個のプロジェクトがある場合、再コンパイルが必要かどうかを判断するためだけにすべてのプロジェクトを処理するのに長い時間がかかるという副作用もあります。
私のプロジェクトでは、assemblies他のプロジェクトがビルドをコピーする設定された場所からプロジェクトが自動的にコピーするフォルダーを作成します。
参照アセンブリのプロジェクトのビルド後:
if not exist "C:\builds\Project1" md "C:\builds\Project1\" copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
プロジェクトを参照するための事前ビルド:
「c:\builds\Project1\」が存在する場合は、「c:\builds\Project1*.*」「$(ProjectDir)assemblies」をコピーします
プロジェクト ファイルassembliesは参照用のサブフォルダーを指しているため、ソース プロジェクトがソリューションからアンロードされた場合でも、最後にビルドされたアセンブリが使用され、開発中にプロジェクト全体がメモリ内にあるというパフォーマンスの問題は発生しません。
ソリューションとプロジェクトの構造化に関する MSDN のドキュメントを読んで、ひらめいた瞬間がありました。
私が気付いていなかったのは、マルチプロジェクト ソリューションでは、ソリューション エクスプローラーのコンテキスト メニューが [プロジェクトの依存関係] ポップアップを提案することです。プロジェクト間のプロジェクト参照によって依存関係を定義していない場合は、ここでプロジェクトの依存関係を手動で定義できます。
こちらを参照してください(MSDN リンクなので、数週間後に自己破壊します)
プロジェクトのアンロードは一時的なアクションであるため、実際のプロジェクト ファイルを XML (テキスト) として編集できます。ソリューションからプロジェクトを完全に削除する場合は、[削除] メニュー オプションを使用する必要があります。これにより、そのプロジェクトへの参照がすべて削除されます。
プロジェクト参照を使用する利点の 1 つは、コードを簡単にデバッグできることです。また、正しい構成ビルドを使用していることも自動的に確認されます (つまり、「デバッグ」モードでビルドしている場合は、アセンブリのデバッグ バージョンが使用されます)。そうは言っても、依存プロジェクトのどのバージョン/ビルドを選択するかについての決定を失います-プロジェクト参照は、常に最新のものを使用することを意味します。
はい、Visual Studio がビルドの依存関係を判断するには、プロジェクト参照を意味するすべてのプロジェクトを表示およびビルドできる必要があります。