C＃プロジェクトに外部DLLを含めるかどうか

Question

私たちのプロジェクトには多くの外部DLLがありますが、そのほとんどがサードパーティのDLLではありません。

現在のところ、これらのDLLはプロジェクトには含まれていません。それらはSVNに含まれ、ビルド出力ディレクトリへのパスが与えられます。したがって、プロジェクトをビルドした後、SVNのために必要なファイルがそこにありますが、プロジェクト自体にはそれらの知識はありません。

プロジェクトのルートの下にあるDependanciesやThirdPartyのような名前のフォルダがあり、すべてのDLLがそこに含まれていて、ビルドイベントを設定して出力ディレクトリにコピーする必要があります。 SVNにも存在しますが、ビルド出力ディレクトリではなく、プロジェクトと同じ構造になります。

プロジェクト自体は、CommunicationProc.DLLというDLLのうちの1つのみを参照します。 CommunicationProc.DLLは、他のすべてのDLLを参照します。我々は、さまざまなタイプのラジオをサポートするための多数のDLLを持っています。したがって、すべてのDLLが使用されるわけではありませんが、ラジオの種類に応じていずれか1つを使用することができます。

DLLをプロジェクトに含めるべきかどうかについては、内部的に意見が異なります。チームビーレの一部は、SVN内にのみ存在し、プロジェクト自体には含まれないようにしてください。

これは.NET DLLではなく、ほとんどが古いC DLLです。

受け入れられている方法は何ですか？誰かが魅力的な議論を私にプロジェクトの中に入れるのかSVNだけを入れるのかについて、どちらか一方の方法で提供してくれますか？

Answer 1

ソース管理上のフォルダに入れて、ビルドイベントのデバッグフォルダにコピーする方が良いです。この方法で、自分のバージョンを管理できます。いくつかのdllの新しいバージョンが来たら、あなたは古いものを置き換えて、チェックインしていくつかのコメントを書くことができます。もしあなたがチームで働いているなら、デバッグフォルダから各チームメンバーにファイルをコピーするのではなく、メンバーは、ソース管理からのdllの同じセットを使用します。いくつかのコントロールを開発していて、顧客がそのコントロールを使用することを望むなら、.Net dllと一緒に顧客にそれらを与えることができるように、依存するDLLのセットを持つ方が簡単です。
管理されていないdllで同じ問題が発生し、すべてのチームメンバーが同じバージョンのdllを持つようにフォルダに入れてしまいました。お役に立てれば。

Answer 2

コードは含まれていませんが、すべての外部アセンブリとその依存関係が保持されているフォルダが含まれています。各ファイルに対して、[ビルドアクション]を[なし]に設定し、[コピーして出力をコピーしない]に設定します。プロジェクトは、この場所からバイナリを参照します。あなたの他のプロジェクトでは、この特別なプロジェクトを参照してください。ビルド時には、特別プロジェクトが参照され、必要なすべての依存関係を参照するため、必要に応じてバイナリがコピーされます。

特殊なプロジェクトを必要としない場合でも、メインプロジェクトにフォルダを作成し、アセンブリを追加してプロパティを設定し、必要に応じてアセンブリを参照します。

これにより、バージョンと出力を完全に制御することができます。さらに重要なことは、簡単です。