具有相同签名的网站上的程序集引用错误答案

【问题标题】：Assembly reference error on web site with same signature具有相同签名的网站上的程序集引用错误
【发布时间】：2008-12-18 23:24:00
【问题描述】：

我在 IIS 6 和 Windows Server 2003 上拥有多个 ASP.NET 2.0 网站。每个站点都引用了一些 DLL：设计、逻辑等。每个站点都位于不同的 ApplicationPool 上，具有关于回收技术的默认配置。

每个 DLL 都是强命名的（没有延迟），并且有一个永不改变的版本 (2.0.0.0)，所有 DLL 都放在 GAC 中。

在我更新 GAC 中的 DLL（即 MyLibrary.dll）后，该 DLL 在某些内容（方法、类..）中发生了变化，以便在网站“A”中使用，并且仅在回收“A”应用程序池之后，当我尝试访问引用相同 DLL 的网站“B”时，我得到了关于该 DLL 的常见错误：

找到的程序集的清单定义与程序集不匹配参考。（HRESULT 的例外情况： 0x80131040)

当然，除了代码、相同的强键、相同的版本、文化之外，DLL 没有任何变化。当然，在回收“B”应用程序池时错误消失了。

什么会产生奇怪的RANDOM（我不得不说！）行为？还有更多的东西，比如散列，可以用来比较程序集？

附录

assembly="MyNamespace.MyComponent, 版本=2.0.0.0，文化=中性， PublicKeyToken=1234567890ASDFGH"

【问题讨论】：

【解决方案1】：

我不断重复自己：除非绝对必要，否则不要将文件存储在 GAC 中。 asp.net 将 dll 复制到临时文件夹并从那里运行该站点，这可能是加载的 dll 与临时文件夹中的 dll 之间的校验和不匹配。

您应该将站点的 dll 保存在站点的 bin 文件夹中。它将为您提供更大的灵活性，并且您不会通过为应用程序 A 更新 dll 来伤害应用程序 B。您还可以通过放弃一些磁盘空间的低价获得 xcopy 部署。

【讨论】：

【解决方案2】：

Frans，这是一个我理解的过程，它当然可以是一种部署方式，但我不明白的是，为什么即使完整的限定名称是正确的，但仍然会出现错误。我在 DLL 清单中看到，有哈希算法规范。 ASP.NET 是否对 DLL 执行散列比较？

简而言之：IIS/ASP.NET 发现 DDL“A”与 DLL“B”哈希不匹配，但三元组“key,culture,version”是相同的，所以为什么它不只是更新而不是弹出一个 web.config 错误？

【讨论】：

为什么它不更新 dll 对我来说也是一个谜，但恕我直言，它不会更新 dll，这类似于您在多个项目中两次引用相同的 dll 并且有它们之间的校验和不匹配：它可能会在编译过程中导致临时文件夹出错。