私のプロジェクトでは、いくつかのサードパーティライブラリを使用しています。 Visual Studioの参照フォルダーを使用してそれらを含めます。
しかし、DLL=ファイルを保存する必要がありますか?ファイルシステム内のパスから参照されますが、プロジェクトに含めることができればいいでしょう。
これが私がすることです:
ソリューションフォルダを追加してそこに追加することもできます。
上記の答えは、 NuGet が初期段階にあったときでした。 FWIW、NuGetアイテムがある私のアプローチ:
packages.config
ファイルを特定のパッケージにバージョンをロックダウンする必要がある場合実際、NuGetを使用して内部依存関係を管理し、プライベートフィードを持っています。
通常、私のプロジェクトの構造は(少なくとも)次のようになります。
projectname
- trunk
- src
- lib
- support
- docs
- releases
trunk
フォルダーには、現在作業中のソースのコピーが含まれています。また、プロジェクトによって参照されるすべてのサードパーティアセンブリを含むディレクトリ「lib」があります。
(その位置でアセンブリを参照します)。
「リリース」フォルダには、トランクのブランチが含まれています。たとえば、v1がリリースされると、アプリケーションのバージョン1をビルドするために必要なソースコードとそのすべての依存関係のコピーがあるように、トランクからブランチが取得されます。 (これはバグ修正に便利です。そのブランチのバグを修正し、トランクに修正をマージし、そのブランチを再構築すると、アプリケーションのv1が修正されます)。
これらはすべてソース管理に組み込まれます。 (はい、参照アセンブリも同様です)。そうすることで、他の同僚がプロジェクトに取り組む必要がある場合でも非常に簡単です。彼はソース管理から最新バージョンを取得するだけで、彼(または彼女)はコンパイルとビルドができるようにすべてを準備しています)。
(これは CruiseControl のようなものを continuous integration に使用する場合にも当てはまることに注意してください。).
NuGet を見てください。これはVisual Studio 2010のパッケージ管理拡張機能であり、目的に合わせて設計されています。
DLLへの参照のためのVisual Studioのプロパティウィンドウには、「ローカルコピー」と呼ばれるプロパティがあります-これをtrueに設定すると、ローカルプロジェクトのbinディレクトリにコピーされます
NuGet (Visual Studioのパッケージマネージャー)をご覧ください...
NuGetは、Visual Studioでオープンソースライブラリとツールを簡単にインストールおよび更新できるVisual Studio拡張機能です。
次に、このNuGetドキュメントを読んで、クレームドラクレームを取得します。
これに適切に答えるには、環境とワーキングセットを区別する必要があります。
環境:
ワーキングセット:
コンポーネントが適合するカテゴリを決定する必要があります。
個人的には、サードパーティDLLのソース管理にフォルダー(各会社、組織用のフォルダー)があり、そこから参照します。
これらのファイルは、ソースをダウンロードするすべての開発者が利用でき、簡単に更新できます。