如何阻止 Visual Studio 更新程序集引用？答案

【问题标题】：How to stop visual studio from updating assembly references?如何阻止 Visual Studio 更新程序集引用？
【发布时间】：2010-09-18 19:15:36
【问题描述】：

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

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

当开发人员签入项目并将其他人搞砸时，就会出现问题。

有没有办法阻止 Visual Studio 2008 这样做？

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

【问题讨论】：

是的，这很糟糕，这就是为什么我自己从来没有在 GAC 中放任何东西的原因。
另外，问题似乎出在你的开发者身上，也许你可以做点什么来教他们不要犯这个错误——比如每次有人犯这个错误他支付 5 美元——这应该有助于他们记住:)
主要问题在于 GAC 的程序集，例如 DevExpress 控件。我们最终指定了 1 人负责使用 3rd 方程序集更新 lib 文件夹，并且不允许其他人安装它们。这些控件有点痛苦，但它起作用了。

标签： .net ide tfs

【解决方案1】：

我认为这是不可能的。

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

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

【讨论】：

TeamCity 对最多 20 个用户和 20 个构建免费。这是我目前正在使用的，非常好。
我们已经设置了 CI。基本上，我正在清理我们的开发环境中的一个巨大混乱，在这个环境中，有人 gac'd 构建服务器上的所有这些程序集。问题当然是，这里的一些应用程序使用不同的版本，这会导致更多的问题。
不过，我想我的下一步是清理构建服务器 - 谢谢。
您也许可以在项目文件的 xml 中搜索并替换 HintPath 所有提示路径应该以 ../../lib/ 之类的开头

【解决方案2】：

这是我们在我的公司防止这种情况的方法。（您的里程会有所不同！）

任何非系统（或其他非 GAC）引用都来自我们的开发服务器，每个开发人员都已将其映射到他们的 W: 驱动器。我们有一个公用的 DLL 目录，其中包含客户（或供应商）的子目录，以及其他适当的子目录。除了 Infragistics 偶尔需要的 license.dll 之外，没有任何 DLL永远存储在源代码管理中。

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

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

这确实会减慢我们的本地编译时间（用于本地调试），因为 VS 每次都会针对服务器自动刷新这些。这很烦人（有时一个项目可能需要 5 或 6 分钟才能在本地构建），但在使用不同引用的人周围工作是必要的。这样做的好处是，只要有人签入其中一个引用的代码，CI 服务器就会开始构建，每个人都很快就会得到它。

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

到目前为止，由于此过程，我们遇到的问题为零，除非构建服务器启动，而我们的源代码控制系统（也称为 Demon Spawn，请参阅我最近的许多评论）执行大型 multi - 文件签入。（因为 Demon Spawn 不支持交易签到。）但是，这种情况非常罕见——可能每 5 或 6 周一次。之后立即进行部队重建。

只是一些想法......这种技术应该可以防止人们搞砸你的源代码管理 - 作为一个额外的好处，减少你的源代码管理的大小，因为你不会检查 DLL，只是 dll.refresh 文件.

【讨论】：

看起来这几乎是正确的答案。我们正在使用 TFS，我发现 ForbiddenPatternsPolicy 可以在签入时查看文件。谢谢！

【解决方案3】：

除了将您的 dll 置于源代码控制中之外，我在大多数方面都同意 John 的观点。

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

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

【讨论】：

我见过很多公司双向发展。我们曾经这样做过，但因为我们试图限制源代码管理中实际包含的工件的大小而停止了。

【解决方案4】：

是的，这绝对是疯狂的，真的很痛苦。这是您的另一种选择： 1. 从 GAC 中删除程序集，正如其他帖子所建议的那样。 2. 让您的依赖关系解析系统将程序集传送到您的 BIN 文件夹。这也是您的所有解决方案程序集也将被编译到的地方。 3. 设置所有引用 Copy Local = false AND Specific Version = False。这样做的目的是在调试时导致程序集加载异常，因为如果它不在 BIN 中，那么那里没有任何东西可以复制它。而且您的解决方案将编译得更快，因为 VS 不必复制文件。并且这将防止“不死” dll 位于 obj 目录中的某个位置，VS 会奇迹般地找到并复制它......

这适用于您控制的解决方案。我们多年来一直在这样做。并且很容易找出是否有事情偏离了轨道，然后您只需寻找具有 Copy Local = true 或 Specific Version = True 的程序集，这种情况偶尔会发生（忘记、累了等）。我目前的问题是我无法控制我正在研究的解决方案的结构或设置，因此为这个古老的问题寻找解决方案。我希望VS团队解决它......唉......团队，停止这种痛苦。

【讨论】：