logo标签列表

存储和引用DLL库的最佳实践是什么？

dllversion-control
27

很多时候，我的团队中的开发人员会创建一个新的 Visual Studio 项目，并引用他们本地机器上的某个 DLL (例如，C:\mydlls\homersimpson\test.dll)。然后，当我从源代码控制库获取该项目时，我无法构建该项目，因为我在我的计算机上没有完全相同位置的所引用的dll文件。

存储和引用共享库的最佳实践是什么？

7个回答
20

我通常在我的项目中创建一个lib文件夹，并把引用的dll放在里面。 然后我指向lib文件夹中的dll进行引用。这样，每个开发人员都可以在从源代码控制检索后构建项目。

如果这是一项内部建立的项目，您也可以将该项目添加到您的解决方案中。

这也是我的第一反应。我唯一看到的缺点是，如果你有一个常用的 DLL，每个引用它的项目都会在源代码控制中有多个位置。 - Rob Sobers
4
多个dll副本可能很有益，这将允许每个项目潜在地使用不同版本的dll。 - PaulG
我建议使用GAC进行版本控制。这样，通过使用预构建的事件，您可以将该DLL从共享库安装到您的GAC中。 - Saeed Neamati
我认为现在最好将构件保留在外部，并在编译时使用Artifactory、NuGet、Maven等工具进行包含。 - Giulio Caccin
3
如果程序集不在全局程序集缓存中（GAC），请创建一个名为“dependencies”的目录并将所有程序集添加到其中。该文件夹和程序集都将添加到源代码控制中。规则是，对于源代码控制中的任何项目，构建所需的全部内容仅需签出并构建该项目（或运行同样被检入项目中的某些工具）。
如果您向解决方案添加一个文件夹并将程序集添加到该文件夹中，这也提供了一种视觉提示，以指示开发人员存在哪些外部依赖项... 所有依赖项都在该目录中。相对路径确保Visual Studio可以轻松定位引用。
对于具有20个以上项目的大型解决方案，这使得生活变得更加轻松！
2

我期望的最佳实践是，您的SC存储库应该包括并强制执行引用对象的相对位置（通常通过共享路径），因此您不必直接处理此问题。原始开发人员应该检入这些信息。

怎么会呢？你难道没有在SCC中包含所有可链接的模块吗？ - dkretz
直接进入dll-hell，不要经过Go，... - dkretz
1

我认为这种方法与我认为的最佳实践完全相反。更好的方法是将第三方二进制文件从源代码库中排除，并通过类似于Maven存储库的方式在构建过程中引用它们。将dll文件放入源代码库中会不必要地膨胀存储库的内容，导致项目获取所需时间比必要的时间长得多。这也使得第三方二进制文件版本的独立管理变得模糊，因为没有按名称引用版本，而是通过引用存储在项目lib文件夹中特定版本的dll来隐含地引用版本。

1
如果您将实际 DLL 提交到源代码控制中，则可以通过相对路径引用它们，并且所有开发人员在下次更新项目时将自动获取任何依赖项。
通过完整路径添加 DLL 引用将是一种开发人员错误，就像通过完整路径添加源文件一样。
1
你是否将二进制文件提交到源代码版本控制中？ - grepsedawk
不是我的二进制文件。我认为原问题是在谈论一些未与项目一起构建的第三方DLL。 - Greg Hewgill
好的，这样更有意义。我们也会对第三方库执行相同的操作。 - grepsedawk
1
经验法则：如果项目不是解决方案的一部分，请从受源代码控制树管理的/binshare或/lib目录引用已发布的dll。所有外部依赖项应该有版本化的DLL，放在这个/binshare目录中。

我理解你的同事为了方便而采取的做法。然而，那位开发者的方法与正确的配置/构建管理截然相反。

例如：如果您在应用程序中使用MS Data Application Block作为依赖项，则应引用正确发布的二进制文件，而不是从MS的开发源代码主干获取最新版本。

你的第一句话是用英语写的吗？ :) 或许加上一些逗号或连词会帮助我更好地理解它？ - Patrick Szalapski
1
为什么不设置私有NuGet-feed呢？这样，只有一个依赖项的副本（NuGet存储库），多个项目可以引用它。依赖项的多个版本可以共存，如果需要，每个项目可以引用不同的版本。此外，TFS Build可以在构建时还原包。
配置VS: https://www.visualstudio.com/en-us/docs/package/nuget/consume
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接