使用Visual Studio管理源代码管理中的引用

我在管理Visual Studio中的项目中的.dll引用时遇到问题。所有注册的.NET和COM引用都可以正常工作，但是当涉及到磁盘上的.dll文件时，如果我在磁盘上引用了我的文件，我的同事将缺少引用，因为它们可能位于磁盘上的其他位置。 Visual Studio有一个像$ PATH或类似的环境变量，以便每台计算机都有路径，它会先查找，然后说它找不到引用？或者将源代码管理中的.dll引用保留为更好的选项？使用Visual Studio管理源代码管理中的引用

好的，它的工作完美。在VS中，我只是向解决方案添加了一个文件夹，将dll添加到文件夹并将所有内容添加到源代码管理。我在个别项目中提到了这些DLL，当我从其他计算机上获得最新版本时，它会正确链接。谢谢你们

来源

2010-07-19 xster

这个工作对我来说，无论是在颠覆和VSS。

\root 
    \trunk 
     foobar.sln (solution file goes here) 
     \References 
      foo.dll (3rd party, ie. you don't compile this) 
      bar.dll 
      (Don't put dll's for Project 1 here, Visual Studio will take care of it) 
     \Project1 
      .proj file goes here 
       \bin (don't put dll's here!) 
     \Project2 (This might reference Project1

请勿将dll放入\ bin，因为像VSS这样的存储库使它们只读，这会中断清理并重新构建。

Visual Studio不理解解决方案级别以上的依赖关系，因此如果您有依赖解决方案的解决方案，则必须在您的构建脚本/构建服务器中显示该解决方案。

来源

2010-07-19 18:33:45 MatthewMartin

我喜欢在解决方案中添加一个解决方案文件夹，然后我将所有外部DLL放入其中。然后，我参考该文件，而不是PC上的特定文件夹。

所以是的，他们是在源，但为什么不。特别是在管理更新时。

适用于我。

来源

2010-07-19 18:14:31

一般的经验法则：把源代码管理中的DLL和尽可能通过增加项目文件，而不是DLL引用

来源

2010-07-19 18:20:25 CarneyCode

创建包含您需要的任何引用的程序源代码管理“引用”文件夹中。如果源可用于这些程序集，请将其存储。

我认为包含所有程序集并不是OS或.NET框架的一部分是一种很好的做法。例如，当开始安装新的开发人员（在新计算机上或重新安装操作系统）时，您不希望安装Enterprise Library或任何其他程序集。

来源

2010-07-19 18:22:05

我有一个共同的文件夹在所有真正的第三方dll存储源。在每个项目下，我有以下三个文件夹：

3rdParty - 一个svn：外部链接到任何第三方dlls需要从公共集合。
参考文献 - svn：外部链接到任何内部构建项目的“Assemblies”文件夹。
组件 - 这是项目的构建输出将去的地方。通过这种方式，可能需要引用程序集的其他项目只有一个地方可供项目使用，并且使用svn：externals可以控制他们希望使用的版本。

\root 
    \Common.3rdParty (common third party dlls) 
    \Solution 
     \Project1 
      \3rdParty (svn:externals links to common third party dlls that are needed) 
      \Assemblies (Project's build output) 
      \References (svn:externals links to referenced project "Assemblies" folders) 
      \[Project's Folders...] 
     \Solution.sln

More Info Here

来源

2010-07-19 18:25:12 gregwhitaker

如果您的.dll文件存在于源代码控制，那么所有你需要做的是正确的点击从溶液的依赖和包文件夹（这是在源控制资源管理器），并获得最新版本的它。

，你会发现你的.dll文件系统上的文件。

来源

2013-07-02 11:37:18