【发布时间】：2018-01-05 13:36:50
【问题描述】：
我团队中的开发人员通常会创建一个新的 Visual Studio 项目并在其本地计算机的某个位置引用一个 DLL（例如，C:\mydlls\homersimpson\test.dll）。然后，当我从源代码控制存储库中获取项目时，我无法构建项目，因为我的机器上的完全相同的位置没有引用的 dll。
存储和引用共享库的最佳做法是什么？
【问题讨论】：
标签： dll version-control
【发布时间】：2018-01-05 13:36:50
【问题描述】：
我通常在我的项目中创建一个 lib 文件夹，其中放置了引用的 dll。然后我将引用指向 lib 文件夹中的 dll。这样，每个开发人员都可以在从源代码管理中检索后构建项目。
如果是内部构建的项目，您也可以将该项目添加到您的解决方案中。
【讨论】：
-
这也是我的第一个想法。我看到的唯一缺点是，如果你有一个常用的 DLL，它会在引用它的每个项目的多个位置的源代码控制中。
-
@vg1890：dll 的多个副本可能是一个好处，这将允许每个项目潜在地使用不同版本的 dll
-
我推荐 GAC 和版本控制。这样，通过使用预先构建的事件，您可以将该 DLL 从共享存储库安装到您的 GAC 中。
-
我认为现在最好将工件保留在外部，并在编译时使用 Artifactory、NuGet、Maven 等将其包含在内。
如果程序集不在 GAC 中，请创建一个名为 dependencies 的目录并在其中添加所有程序集。文件夹和程序集被添加到源代码管理中。规则是，给定源代码控制中的任何项目，构建所需的只是进行签出并构建项目（或运行一些也签入项目的工具）。
如果您将文件夹添加到解决方案并将程序集添加到解决方案文件夹，这也会为开发人员提供一个视觉提示，指示存在哪些外部依赖项......所有依赖项都在该目录中。相对路径确保 Visual Studio 可以毫无问题地找到引用。
对于包含 20 多个项目的大型解决方案，这让生活变得更加轻松！
【讨论】：
我期望的最佳实践是让您的 SC 存储库为您包含并强制执行引用对象的相对位置（通常通过共享路径），因此您不会直接处理此问题。原始开发者应检查此信息。
【讨论】：
-
怎么样？你不是在 SCC 中包含所有可链接的模块吗？
-
Right - "直接进入 dll-hell。不要通过 Go，..."
如果您将实际的 DLL 签入到源代码管理中，那么您可以通过相对路径引用它们，并且所有开发人员将在下次更新项目时自动获取任何依赖项。
通过完整路径添加 DLL 引用将是开发人员错误，就像通过完整路径添加源文件将是错误一样。
【讨论】：
-
您是否将二进制文件签入到源代码版本控制中？
-
不，不是我自己的二进制文件。我以为最初的问题是在谈论一些不是用该项目构建的第三方 DLL。
-
好吧，这更有意义。我们对第三方库做同样的事情。
经验法则：如果项目不是解决方案的一部分，请从解决方案的源代码控制树下的源代码控制 /binshare 或 /lib 目录引用已发布的 dll。所有外部依赖项都应该有版本化的 DLL，这些 DLL 位于 /binshare 目录中。
我了解您的同事在方便方面的做法。但是，该开发人员的方法与正确的配置/构建管理截然相反。
示例：如果您在应用程序中使用 MS 数据应用程序块作为依赖项，您应该引用正确发布的二进制文件，而不是从 MS 的开发源主干获取最新的。
【讨论】：
-
你的第一句话是用英文写的吗？ :) 也许一些逗号或连词可以帮助我理解它？
我认为这种方法与我认为的最佳做法完全相反。我认为将第三方二进制文件排除在源存储库之外并通过构建过程中的 Maven 存储库之类的方式引用它们会是一种更好的方法。将 dll 放入源存储库会不必要地膨胀存储库的内容，并导致获取项目的时间比必要的要长得多。它还通过不通过名称引用版本，而是通过引用存储在项目 lib 文件夹中的特定版本的 dll 来暗示对第三方二进制文件版本的独立管理。
【讨论】：
为什么不设置私有 NuGet 源？这样，依赖项（NuGet 存储库）只有一个副本，并且多个项目可以引用它。依赖项的多个版本可以共存，并且每个项目可以在必要时引用不同的版本。此外，TFS Build 可以在构建时恢复包。
配置VS：https://www.visualstudio.com/en-us/docs/package/nuget/consume
【讨论】：