我们有几个c＃项目，库和解决方案（一些asp.net应用程序，一些类库，windows应用程序，如windows服务和winform应用程序等），其中大多数都依赖于其他输出dll。我们的一些项目被分组到解决方案中，它们使用项目依赖性。但有些项目不是。 我们（不幸的是）使用VSS来管理源代码。当引用程序集到项目时，有时我会看到存储在vss中的刷新文件，但是当你最初获得最新版本时，实际的dll永远不会出现，有时只是程序集而不是vss托管，有时只是程序集，它们似乎是由vss管理的。您可以猜测，为我们管理这些文件是一件噩梦，尤其是在发布网络应用时。我们永远不确定图书馆dll的最新版本是否正在发布。 你能建议任何有关管理这种复杂性的最佳实践吗？任何文章也欢迎。我们应该将所有库保留在网络文件夹中并使用刷新文件吗？那么团队中的每个开发人员都应该将他的输出文件复制到该网络共享中？
谢谢， 了Umut
答案 0 :(得分：2)
我要解决的问题是在我的网络应用程序的bin目录中删除引用的DLL的副本，并将它们作为项目的一部分包含在源代码安全中。
这样，如果DLL被更新，就像Check Out - Overwrite - Check In一样简单，团队中的所有成员都可以拥有最新的文件。
此外，它使部署变得简单，因为文件包含在发布期间。只需将构建类型设置为内容。
答案 1 :(得分：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中创建的构建版本。完成后，您可以随时在任意位置部署结果。