Question

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

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

Answer 1

这对我来说都适用于subversion和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不了解解决方案级别之上的依赖关系，因此如果您拥有依赖于解决方案的解决方案，则必须在构建scrips / build服务器中显示该解决方案。

Answer 2

我想在解决方案中添加一个解决方案文件夹，然后我将所有外部DLL放入其中。从那里我引用它而不是PC上的特定文件夹。

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

非常适合我。

Answer 3

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

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

Answer 4

一般的经验法则：将dll放在源代码管理中，并尽可能通过项目文件而不是dll添加引用

Answer 5

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

3rdParty - 一个svn：externals链接到公共集所需的任何第三方dll。
引用 - 一个svn：externals链接到任何内部构建项目的“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

Answer 6

如果您的.dll文件存在于源代码管理中，那么您需要做的就是右键单击解决方案中的Dependencies and packages文件夹（位于源控制资源管理器下）并获取它的最新版本。

您将在系统中找到.dll文件。

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

6 个答案: