3

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

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

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

プロジェクト自体は、CommunicationProc.DLLと呼ばれるこれらのDLLの1つのみを参照します。次に、CommunicationProc.DLLは他のすべてのDLLを参照します。さまざまなタイプの無線をサポートするために、多数のDLLがあります。したがって、すべてのDLLが使用されるわけではありませんが、無線の種類に応じていずれかのDLLが使用される場合があります。

DLLをプロジェクトに含めるかどうかについては、社内で意見が異なります。一部のチームは、DLLはSVNにのみ含まれ、プロジェクト自体の一部ではないと考えています。

これは.NETDLLではなく、ほとんどが古いCDLLであることに注意してください。

受け入れられている慣行は何ですか？誰かが、プロジェクトに含めるか、SVNだけに含めるかについて、何らかの説得力のある議論を私に提供できますか？

4

2 に答える 2

4

それらをソース管理上のフォルダーに入れてから、ビルドイベント時にデバッグフォルダーにコピーすることをお勧めします。このようにして、それらのバージョンを管理できます。いくつかのdllの新しいバージョンが来たら、古いバージョンを置き換えて、チェックインしてコメントを入れることができます。また、チームで作業している場合は、デバッグフォルダから各チームメンバーにファイルをコピーする代わりに、各チームに許可することができますソース管理から同じdllのセットを使用するメンバー。コントロールを開発していて、顧客にそのコントロールを使用してもらいたい場合は、依存するdllのセットをどこかに配置して、.Netdllと一緒にそれらを顧客に提供できるようにする方が簡単です。
いくつかの管理されていないdllで同じ問題が発生し、すべてのチームメンバーが同じバージョンのdllを持つように、それらをフォルダーに配置することになりました。お役に立てれば。

于 2012-05-02T18:18:27.443 に答える
1

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

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

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

于 2012-05-02T18:36:47.060 に答える