在我们的环境中,我们有一个Lib文件夹,其中包含我们项目引用的各种第三方程序集.例如,Enterprise Libary和Elmah.
有时开发人员不会在该文件夹上获取最新信息.然后,当开发人员加载无法在预期文件夹中找到程序集的项目时,Visual Studio会自动查找另一个副本并更新项目引用.
当开发人员检查项目并且其他人搞砸时,会出现问题.
有没有办法阻止visual studio 2008这样做？
更新:我想补充说我们正在使用TFS进行源代码管理.
以下是我们公司如何防范这种情况的方法。（您的里程会有所不同！）
任何非系统（或非 GAC）引用都来自我们的开发服务器，每个开发人员都已将其映射到他们的 W: 驱动器。我们有一个公共 DLL 目录，其中包含客户（或供应商）的子目录，以及更多适当的子目录。除了 Infragistics 偶尔需要的 license.dll 之外，任何 DLL 都不会存储在源代码管理中。
对于供应商提供的库（EntLib、Infragistics 等），我们从 W: 驱动器引用作为策略。时期。任何人无权从其他地方引用。这会将项目文件中的提示编码到公共路径。
对于内部库（客户端和内部项目），我们的持续集成过程将 DLL 输出到该目录的相应分支中——同样，我们所有的引用都来自该目录。
这确实会减慢我们的本地编译时间（用于本地调试），因为 VS 每次都会针对服务器自动刷新它们。这很烦人（有时一个项目可能需要 5 或 6 分钟才能在本地构建），但在使用不同参考的人周围工作是必要的罪恶。这里的优点是，一旦有人签入其中一个引用的代码，CI 服务器就会开始构建，每个人都很快就能得到它。
做到这一点的秘诀是稳定、可重复的构建过程和持续集成服务器。我们使用CruiseControl.NET，与NAnt构建集成，但在此处插入您最喜欢的 CI 服务器和构建工具。
到目前为止，我们在此过程中遇到的问题为零，除非构建服务器在我们的源代码控制系统（也称为 Demon Spawn，请参阅我最近的许多评论）执行大型多文件检查时启动-在。（因为《Demon Spawn》不支持交易签到。）然而，这种情况非常罕见——可能每 5 或 6 周发生一次。随后立即重建部队来解决这个问题。
只是一些想法...这种技术应该可以防止人们搞砸你的源代码管理——并且作为额外的好处，可以减少源代码管理的大小，因为你不会签入 DLL，而只签入 dll.refresh 文件。