具有相同签名的网站上的程序集引用错误
我在 IIS 6 和 Windows Server 2003 上有多个 ASP.NET 2.0 网站。 每个站点都引用一些 DLL：设计、逻辑等。 每个站点都位于不同的应用程序池上，具有有关回收技术的默认配置。
每个DLL都是强命名的（不延迟）并且有一个永不改变的版本（2.0.0.0），所有DLL都放置在GAC中。
在我更新 GAC 中的 DLL（即 MyLibrary.dll）后，该 DLL 在某些内容（方法、类..）中发生了更改，以便在网站“A”中使用，并且仅回收“A”应用程序池后，当我尝试访问引用相同 DLL 的网站“B”我收到有关该 DLL 的常见错误：
找到的程序集的清单 定义与程序集不匹配 参考。 （HRESULT 的异常： 0x80131040）
当然，除了代码之外，DLL 中没有任何改变，相同的强键、相同的版本、文化。 当然，通过回收“B”应用程序池，错误就会消失。
什么会产生奇怪的、随机（我不得不说！）的行为？ 还有更多的东西，比如散列，它可以用来比较程序集？
附录
- Perpetualcoder问我DLL是如何引用的，如果有完整的限定名，我想是的，这里有一行web.xml。配置：
程序集=“MyNamespace.MyComponent， 版本=2.0.0.0，文化=中立， PublicKeyToken=1234567890ASDFGH"
I've more than one ASP.NET 2.0 web site on IIS 6 and Windows Server 2003.
Each site reference some DLLs: design, logic and so on.
Each site is on a different ApplicationPool with default configuration about recycling techniques.
Every DLL is strong named (not delayed) and has a version that never changes (2.0.0.0), all DLLs are placed in GAC.
After I update a DLL in GAC (ie. MyLibrary.dll) that has changed in something (method, classes..) for the use in web-site "A", and after recycling only the "A" application pool, when I try to access to web-site "B" that reference the same DLL I get the common error about that DLL:
The located assembly's manifest
definition does not match the assembly
reference. (Exception from HRESULT:
0x80131040)
Of course nothing is changed in DLL rather than code, same strongkey, same version, culture. The error disappear over recycling "B" application pool, of course.
What can generate a strange, RANDOM (I've to say!), behavior? There's something more, like hashing, that it's used to compare assemblies?
Addendum
- Perpetualcoder asked me how DLLs are referenced, if with full qualified name, I think it is, here a line of web.config:
assembly="MyNamespace.MyComponent,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=1234567890ASDFGH"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不断重复自己：除非绝对必要，否则不要将文件存储在 GAC 中。 asp.net 将 dll 复制到临时文件夹并从那里运行站点，加载的 dll 与临时文件夹中的 dll 之间的校验和可能不匹配。
您应该将站点的 dll 保存在站点本地的 bin 文件夹中。 它将为您提供更大的灵活性，并且您不会通过更新应用程序 A 的 dll 来损害应用程序 B。您还可以以放弃一点磁盘空间的低廉价格获得 xcopy 部署。
I keep repeating myself: don't store files in the GAC unless you absolutely have to. asp.net copies dlls to a temp folder and runs the site from there, it might be checksums mismatch between the loaded dll and the one in the tempfolder.
You should keep your site's dlls local to the sites, in their bin folder. It will give you more flexibility and you don't hurt application B by updating a dll for application A. you also get xcopy deployment for the low price of giving up a bit of diskspace.
弗兰斯，这是我理解的一个过程，当然它可能是一种部署方式，但我不明白的是为什么即使完整的限定名称是正确的，但是也会出现错误。
我在DLL清单中看到，有哈希算法规范。
ASP.NET 是否对 DLL 执行哈希比较？
我的意思是：IIS/ASP.NET 发现 DDL“A”与 DLL“B”哈希不匹配，但三元组“key、culture、version”是相同的，所以为什么它不只是更新而是弹出出现 web.config 错误？
Frans, it is a procedure that I understand and it could be a way to deploy of course, but what I don't understand is why even if full qualified name is correct, error comes however.
I saw in DLL manifest, there's the hashing algoritm specification.
Does ASP.NET perform a hashing compare over DLLs?
What I mean in few words: IIS/ASP.NET finds that DDL "A" doesn't match DLL "B" hash, but triplet "key,culture,version" is the same so why it doesn't just update instead popping out an web.config error?