【问题标题】:Manage references in source control with Visual Studio使用 Visual Studio 管理源代码管理中的引用
【发布时间】:2010-07-19 18:07:15
【问题描述】:
我在 Visual Studio 的项目中管理我的 .dll 引用时遇到问题。所有注册的 .NET 和 COM 引用都可以正常工作,但是当涉及到磁盘上的 .dll 文件时,如果我引用磁盘上的文件,我的同事将丢失引用,因为他们可能将它放在磁盘上的不同位置等。 Visual Studio 有一个环境变量,如 $PATH 或其他东西,以便每台计算机都有路径,它会在说找不到引用之前先查看它?还是将 .dll 引用保留在源代码管理中是更好的选择?
好的,效果很好。在 VS 中,我只是在解决方案中添加了一个文件夹,将 dll 添加到文件夹中,并将所有内容添加到源代码管理中。我在单个项目中引用了这些 dll,当我从其他计算机获得最新版本时,它正确链接。谢谢大家
【问题讨论】:
标签:
visual-studio-2008
version-control
dll
reference
【解决方案1】:
这对我来说适用于颠覆和 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 不理解解决方案级别之上的依赖关系,因此如果您的解决方案依赖于解决方案,则必须在构建脚本/构建服务器中显示它。
【解决方案2】:
我喜欢在解决方案中添加一个解决方案文件夹,然后我将所有外部 DLL 放入其中。从那里我引用它而不是 PC 上的特定文件夹。
所以是的,它们在源代码中,但为什么不呢。尤其是在管理更新时。
非常适合我。
【解决方案3】:
在源代码管理中创建一个“引用”文件夹,其中包含您需要的任何引用程序集。如果源可用于这些程序集,则也将其存储。
我认为包含不属于操作系统或 .NET 框架的所有程序集是一种很好的做法。例如,您不想在开始新的开发人员安装(在新机器上或重新安装操作系统)时安装 Enterprise Library 或任何其他程序集。
【解决方案4】:
一般经验法则:将 dll 放在源代码管理中,并尽可能通过项目文件而不是 dll 添加引用
【解决方案5】:
我在源代码中有一个公共文件夹,其中存储了所有真正的第三方 dll。在每个项目下我有以下三个文件夹:
- 3rdParty - 一个 svn:externals 链接,指向公共集中所需的任何第 3 方 dll。
- 参考 - 一个 svn:externals 链接,指向任何内部构建项目的“Assemblies”文件夹。
- 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
【解决方案6】:
如果您的 .dll 文件存在于源代码管理中,那么您只需右键单击解决方案中的 Dependencies and packages 文件夹(位于源代码管理资源管理器下)并获取它的最新版本。
您会在系统上找到 .dll 文件。