.net 如何阻止visual studio更新程序集引用？

在我们的环境中，我们有一个Lib文件夹，其中包含项目引用的各种第三方程序集。例如，企业图书馆和Elmah

有时，开发人员不会获取该文件夹的最新信息。当开发人员加载了一个项目，但在预期文件夹中找不到程序集时，VisualStudio会自动定位另一个副本并更新项目引用

当开发人员检查项目时，问题就出现了，它会把其他人都搞砸

有没有办法阻止VisualStudio2008这样做

---

更新：我想补充一点，我们正在使用TFS进行源代码管理。

我认为这是不可能的

如果在文本编辑器中打开项目文件，您将看到VisualStudio不存储对程序集的硬引用，而是存储“HintPath”。如果没有找到引用，VisualStudio将自动尝试GAC

---

设置一个持续集成服务器（如果您还没有）可能是一个好主意，这将作为此类情况的早期预警系统。

以下是我们公司如何防范这种情况。（您的里程数会有所不同！）

任何非系统（或非GAC）引用都来自我们的开发服务器，每个开发人员都将其映射到他们的W:drive。我们有一个公共DLL目录，按客户机（或供应商）提供子目录，并根据需要提供更多子目录。除了基础设施偶尔需要的license.dll之外，源代码管理中从未存储任何dll

对于供应商提供的库（EntLib、Infragistics等），作为我们从W:drive中引用的策略。时期任何人无权从任何其他地方引用。这会将项目文件中的提示编码为公共路径

对于内部库（客户机和内部项目），我们的持续集成过程将DLL输出到该目录的相应分支中——同样，我们的所有引用都来自该分支

这确实会降低本地编译时间（用于本地调试），因为VS每次都会针对服务器自动刷新这些编译时间。这是一件令人烦恼的事（有时一个项目可能需要5到6分钟在本地构建），但与使用不同引用的人打交道是一件必要的坏事。这里的优点是，只要有人签入其中一个引用的代码，CI服务器就会启动一个构建，每个人都会很快得到它

实现这一点的诀窍是一个稳定、可重复的构建过程和一个持续集成的服务器。我们正在使用，与构建集成，但在此处插入您最喜欢的CI服务器和构建工具

到目前为止，由于这个过程，我们没有出现任何问题，除了当构建服务器启动时，我们的源代码管理系统（也称为Demon Spawn，请参阅我最近的许多评论）执行大型多文件签入。（因为Demon Spawn不支持事务性签入。）然而，这种情况非常罕见——可能每5或6周发生一次。随后马上进行部队重建

---

只是一些想法。。。这项技术可以防止人们把你的源代码管理搞砸——另外，还可以减少你的源代码管理的大小，因为你不用签入dll，只签入dll.refresh文件。

除了将你的dll放入源代码管理之外，我在大多数问题上与John意见相左

我通常有一个第三方文件夹，其中会有供应商的产品和版本分类，因此ajax工具包存储在$/ThirdParty/Microsoft/AjaxToolkit/（一些版本号）中。我喜欢这种方法，因为我们可以给构建过程中的所有工件贴上标签

---

另一个想法可能是在项目中添加dll，因此如果他们获得项目的最新信息，他们将获得dll

是的，这简直是疯了，真的很痛苦。以下是您的另一个选择： 1.按照其他帖子的建议，从GAC上拆下组件。 2.让依赖项解析系统将程序集传递到BIN文件夹。这是您的所有解决方案程序集也将编译到的位置。 3.设置所有引用Copy Local=false和Specific Version=false。 这样做的目的是在调试时导致程序集加载异常，因为如果它不在BIN中，则无法将其复制到BIN中。而且您的解决方案将更快地编译，因为VS不必到处复制文件。这将防止“不死”DLL位于obj目录的某个位置，VS将奇迹般地找到并复制这些DLL

这在您控制的解决方案上非常有效。我们已经做了很多年了。而且很容易判断出是否有什么事情偏离了轨道，因为您只需查找Copy Local=true或Specific Version=true的程序集，这种情况偶尔会发生（忘记、疲劳等）。

---

我目前的问题是，我无法控制我正在研究的解决方案的结构或设置，因此，我正在为这个古老的问题寻找解决方案。我希望VS团队能解决这个问题。。。唉。。。团队，停止这种痛苦。

TeamCity最多可免费提供20个用户和20个版本。这是我目前正在使用的，非常好。我们已经设置了CI。基本上，我正在清理我们的开发环境中的一大堆混乱，其中有人在构建服务器上公开了所有这些程序集。当然，问题是，这里的一些应用程序使用不同的版本，这会在它进入生产时造成更多问题。但是，我想我的下一步是清理构建服务器-谢谢。您可能可以在HintPath项目文件的xml中搜索并替换所有HintPath，所有HintPath都应该以.././lib/之类的开头。我已经看到很多公司都这样做了。我们曾经这样做过，但是停止了，因为我们试图限制源代码管理中实际包含的工件的大小。我们正在使用TFS，我找到了禁止模式SP