Question

在版本控制系统中检查.NET项目的第三方参考Dll的理想位置（目录）是什么。通常，我已经看到大多数人将它们放在bin下，因此运行时可以自动拾取这些文件。然而，这是正确的方法。

我原本想要一个与bin并行的独立目录，名为lib，它将包含所有第三方Dll，但这需要更改应用程序配置文件，以便运行时选择lib目录。我在这里的想法是lib将包含第三方dll，而bin将包含二进制项目（可能是Dll或Exe）

首选方式是什么，浓度超过版本控制中的位置，而不仅仅是物理文件系统。

Answer 1

我们使用以下目录结构（更多详细信息on my blog）：

Solution\
  Libraries\
    third-party DLLs here
  Source\
    Project1\
    Project2\

每个项目引用（使用“添加引用”对话框中的“浏览”选项卡）“库”文件夹中的程序集。这些会在编译时自动复制到每个项目的“bin”文件夹中。（“Libraries”文件夹当然是提交给版本控制的。）

Answer 2

让单独的目录包含第三方程序集（这将使源控件中的维护更容易），然后在项目中为这些程序集创建引用。然后，在构建时，您的第三方程序集将被复制到\bin中，您不必进行任何配置更改。

Answer 3

我认为这些第三方DLL将用于你的一个项目中。因此，将DLL直接放在每个项目的bin下意味着你最终拥有与项目一样多的DLL副本（在VCS中），这是不优雅的。正如Andrew H.所提到的，如果DLL真的很常见，那么它们应放在一个公共目录中，所有其他需要它的项目都会引用它。这里唯一的问题是能够区分同一DLL的不同版本：随着时间的推移，你可能会得到类似的东西：

/common/ThirdPartyLibrary.dll  (version 1.2)    
/common/ThirdPartyLibrary.dll  (version 1.3)

我知道（现在）的最好方法是使用显式版本号重命名第三方DLL，并在项目中引用该新名称，这样您的项目肯定会始终引用正确的版本。像：

/common/ThirdPartyLibrary_v1.2.dll    
/common/ThirdPartyLibrary_v1.3.dll

.NET Project的版本控制中第三方Dll的位置

3 个答案: