【问题标题】：visual studio.net dll reference problemsvisual studio.net dll参考问题
【发布时间】：2010-10-30 02:50:30
【问题描述】：
我们有几个 c# 项目、库和解决方案（一些 asp.net 应用程序、一些类库、windows 应用程序，如 windows 服务和 winform 应用程序等），其中大多数依赖于彼此的输出 dll。我们的一些项目被分组到解决方案中，它们使用项目依赖项。但有些项目不是。
我们（不幸的是）使用 VSS 来管理源代码。当将程序集引用到项目时，有时我会看到存储在 vss 中的刷新文件，但是当您最初获得最新版本时，实际的 dll 永远不会出现，有时只是程序集而不是 vss 托管，有时只是程序集，它们似乎由 vss 管理。您可以猜到，管理这些文件对我们来说是一场噩梦，尤其是在发布 Web 应用程序时。我们永远无法确定库 dll 的最新版本是否正在发布。
您能否就管理这种复杂性提出任何最佳实践建议？也欢迎任何文章。我们应该将所有库保存在网络文件夹中并使用刷新文件吗？所以团队中的每个开发人员都应该将他的输出文件复制到该网络共享？
谢谢，
乌姆特
【问题讨论】：
标签：
.net
build-process
reference
dependencies
【解决方案1】：
最简单和最手动的方法是在某处放置某种文档，描述您的 Web 应用程序并指出它的依赖项、它们的版本以及它们在源代码安全中的位置。将其添加为构建脚本的一部分。
实现某种形式的构建自动化是一种更难且更少手动的方法。我建议好好看看 MSBuild (http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx)，它使用 XML 文件作为一种脚本语言。同时下载社区任务包 (http://msbuildtasks.tigris.org/)。使用这两个工具，您应该能够生成一个 MSBuild 文件，该文件从 sourcesafe 获取各种解决方案，然后构建它们（请注意，您可以从 MSBuild 文件调用 MSBuild 文件。另请注意，Visual Studio 解决方案文件是 MSBuild 文件- 您可以让您的 MSBuild 脚本只运行开发人员在 Visual Studio 中创建的构建）。完成后，您可以将结果部署到任何您想要的位置。
【解决方案2】：
解决此问题的方法是将引用的 DLL 的副本放在我的 Web 应用程序的 bin 目录中，并将它们作为项目的一部分包含在源代码安全中。
这样，如果 DLL 被更新，它就像签出 - 覆盖 - 签入一样简单，团队中的所有成员都可以拥有最新的文件。
此外，它还简化了部署，因为文件在发布期间包含在内。只需将构建类型设置为内容即可。