プロジェクトリファレンスとファイルリファレンス？
参照は、プロジェクトに2つの方法で追加できます。
- プロジェクトリファレンス。
- ファイルリファレンス。
しかし、いつプロジェクトを使用し、いつファイル参照を使用するのですか？
指定していませんが、Visual Studioを参照していると思いますか？
プロジェクト参照とファイル参照の主な違いは、ライブアップデートが利用可能かどうかです。プロジェクトリファレンスでは、Intellisenseなどのアイテムを介して、あるプロジェクトでの編集の効果を他のプロジェクトですぐに確認できます。したがって、たとえばFooという名前のクラスを追加すると、このタイプは、そのプロジェクトにプロジェクト参照があるすべてのプロジェクトですぐにインテリセンスで表示されます。
一方、ファイル参照では、ディスクに存在する変更のみを確認できます。変更を確認するには、コンパイルを実行してビットをディスクに書き込む必要があります。
一般に、プロジェクト参照を使用するのが最善です。
考慮する必要があるもう1つの角度は、プロジェクトの相対的な言語です。プロジェクト間の参照は、両方のプロジェクトの言語が同じである場合に最大限に役立ちます。言語が異なる場合、プロジェクト参照よりもファイル参照のように扱われる傾向があります。
私はこれを経験しました...
ベンダーから、63の異なるプロジェクト.dllを作成する約53の異なるVS2005 C＃ソリューションファイルを受け取りました。これらはすべて、別個の商用アプリケーションによって呼び出されます。
すべてのプロジェクトには、他のプロジェクトのdllへのファイル参照が含まれていました。
このアプローチの問題は大きかった。ソリューション間の依存関係を解決することはほとんど不可能であり、lotの「findstr」コマンドが関係していた。 VSの「定義の検索」機能は、ファイル参照dllのソースを検索せず、dll内の関数の定義のみを表示します。変更による再構築はエラーが発生しやすく、面倒であり、dllセット全体を再構築するために多くの異なるソリューションを開く必要がありました。
53の異なるソリューションファイルを1つにまとめるのに何週間も費やし、その後、すべてのファイルの依存関係をプロジェクトの依存関係に変更するためにさらに時間を費やしました。これで、「定義を見つける」と、ソースファイルが表示されます。これで、低レベルプロジェクトを変更すると、（1つの）ソリューションをビルドするときにすべての依存プロジェクトがビルドされます。
いくつか追加の変更を加えましたが、最も便利なのは、個別のプロジェクトのすべてのビルドディレクトリをsolutiondir/binに設定することでした。そうすれば、すべてのdllが1か所にまとめられます。
はい、そうです。参照されているすべてのプロジェクトのdllについて、「copylocal」を「no」に設定しました。このように、プロジェクトがビルドされ、次にビルドするプロジェクトによって検出されると、各dllはsolutiondir/binに表示されます。
現在の唯一の問題は、Windowsフォームを使用して別のプロジェクトのデータソースとして使用されているプロジェクトを変更すると、フォームのデータソースであるプロジェクトを再構築するまで、WindowsフォームがDesignerで開かないことです。プロジェクト参照のすべての利点を支払うための小さな、小さな価格。また、dllがsvnにないため、svnからのチェックアウト時にソリューションをビルドする必要があります。上記の場合、Designerが検索するデータソース.dllはありません。
私は、ファイル参照がそれをカットしない複数のプロジェクトで問題に遭遇しました。古い参照はブクの問題を引き起こします。マイクロソフトでは、必要な場合にのみファイル参照を使用することをお勧めします。
私は、ほとんどの場合、プロジェクト参照ではなくファイル参照を使用するように開発チームを特別に設定しました。私たちは高整合性ドメインで運用しています。したがって、直接この作業の一部ではない各コンポーネント（つまり、他のプロジェクト間で共有されるもの）は、意地悪に変更しないでください。したがって、アイデアは（理想的な、グリーンフィールド以外の作業で）、ネットワーク上のリリース領域からサブコンポーネントのテスト済みの承認済みの既知のバージョンを取得し、それらをソリューションのコンポーネント領域に含めることです。
これは、ビルド番号またはSVN番号が異なる多くの同様のバージョンが急増するのを防ぐため、メンテナンスとテストを簡素化することを目的としています。
2番目の理由（そしておそらく私のC/C++のバックグラウンドです）は、すべてのデバッグバージョンまたはすべてのリリースバージョンを使用していることを知りたいということです。 .NETプロジェクトではこれを簡単に行うことはできません。 components\$ configuration $ディレクトリにビルドアウトしてから、コンポーネント\ $ configuration $から上のディレクトリにコピーするビルド後の手順があります。すべてのファイル参照は、コンポーネントディレクトリ内のファイルへの参照であり、チェーン全体でデバッグビルドとリリースビルドが実際に行われていることを意味します（私は信じています）。
外部に出荷する場合は、送信されるDLLがすべてのユーザーに対して同じである必要があることを考慮する必要があると思います。そうしないと、後で問題を簡単にデバッグできなくなるリスクがあります（ソースコードから配信された実行可能ファイルまでの構成追跡）。
最後に、すべての参照はファイル参照です。プロジェクト参照は単なるビジュアルスタジオ機能であり、ソリューションでビルドされているファイルへの参照を作成するため、新しいビルドをビルドするたびに、参照は自動的に更新されます。ファイルをコピーして貼り付けます
私がファイル参照に行く理由は（私がソースを持っているか、自分でアセンブリを作成した場合でも）、その特定のアセンブリがあまり変更されないときです（たとえば半年に1回）。ビルド時間を少し短縮するためだけに。また、一部のプロジェクトは自動的にバージョン番号をインクリメントします（たとえば、ソリューションにAjaxControlToolkitプロジェクトを含めてみてください）。
参照に切り替える（および相対インクルードを削除する）ときに発生したエラー（C1083）の1つは、「ヘッダーが見つかりません」でした。私が持っていた：
- プリファレンスにはディレクトリが含まれます：
../../src/module - ソースコード内：
#include "file.h"
それが機能するための相対パスを修正します。
#include "module/file.h"
プロジェクトが再構築されると、プロジェクトを参照するすべてのプロジェクトも自動的に再構築されます。
これは、ファイル参照には当てはまりません。