我的团队中的开发人员经常会创建一个新的Visual Studio项目并在其本地计算机上的某处引用DLL（例如，C：\ mydlls \ homersimpson \ test.dll）。然后，当我从源代码控制存储库获取项目时，我无法构建项目，因为我没有在我的机器上完全相同的位置引用的dll。
存储和引用共享库的最佳实践是什么？
我通常在我的项目中创建一个lib文件夹，在那里我放置引用的dll。然后我将引用指向lib文件夹中的dll。这样，每个开发人员都可以在从源代码控制中检索后构建项目。
如果它是内部构建的项目，您还可以将该项目添加到您的解决方案中。
我期望的最佳实践是，您的SC存储库包含并强制执行引用对象的相对位置（通常通过共享路径），因此您不直接处理此问题。原始开发人员应检查此信息。
如果程序集不在GAC中，请创建一个名为dependencies的目录并在其中添加所有程序集。文件夹和程序集将添加到源代码管理中。规则是，给定源代码管理中的任何项目，构建所需的全部内容是执行签出并构建项目（或运行一些也检查到项目中的工具）。
如果向解决方案添加文件夹并将程序集添加到解决方案文件夹，这也为devs提供了一个可视提示，指示存在哪些外部依赖项...所有依赖项都在该目录中。相对路径确保Visual Studio可以毫无问题地找到引用。
对于拥有20多个项目的大型解决方案，这使生活变得更加轻松！
如果您将实际的DLL检入源代码控制，那么您可以通过相对路径引用它们，并且所有开发人员在下次更新项目时将自动获得任何依赖项。
通过完整路径添加DLL引用将是开发人员错误，就像通过完整路径添加源文件将是一个错误。
经验法则：如果项目不是解决方案的一部分，请参考解决方案源代码控制树下的源控制/ binshare或/ lib目录中的dll。所有外部依赖项都应具有此/ binshare目录中的版本化DLL。
我理解你的同事在方便方面做了些什么。但是，该开发人员的方法与正确的配置/构建管理截然相反。
示例：如果在应用程序中使用MS数据应用程序块作为依赖项，则应引用正确发布的二进制文件，而不是从MS的开源中继获取最新信息。
我认为这种方法与我认为的最佳实践完全相反。我认为将第三方二进制文件保留在源存储库之外并通过构建过程中的Maven存储库等引用它们是一种更好的方法。将dll放在源存储库中会不必要地使存储库的内容膨胀，并导致项目获取时间大大延长。它还使第三方二进制文件的版本的独立管理通过不按名称引用版本而被隐含，而是通过引用存储在项目lib文件夹中的特定版本的dll来暗示。
为什么不设置私有NuGet-feed？这样，只有一个依赖项的副本（NuGet存储库），多个项目可以引用它。多个版本的依赖项可以共存，并且每个项目可以在必要时引用不同的版本。此外，TFS Build可以在构建时还原包。
配置VS：https://www.visualstudio.com/en-us/docs/package/nuget/consume