DLL 版本控制错误

Posted 2023-02-23

【中文标题】DLL 版本控制错误

【英文标题】：DLL versioning error

【发布时间】：2012-07-14 11:11:51

【问题描述】：

我有一个网站偶尔会抛出以下错误：

“/”应用程序中的服务器错误。

无法加载文件或程序集“ICSharpCode.SharpZipLib, Version=0.85.3.365, Culture=neutral, PublicKeyToken=1b03e6acf1164f73”或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。 （HRESULT 异常：0x80131040）

现在我知道我确实依赖于这个 DLL，但我的系统上有 0.85.5 版本。我系统地从服务器中删除了每个旧版本的 DLL，重新编译所有内容并重新发布。但无论我做什么，似乎每次重新发布后，有人访问该网站的前一两次，他们都会收到此错误。然后刷新一两次后，错误消失，网站正常运行。

更奇怪的是，如果我查看引发错误的代码行：

URLRewriter.ProcessRewritingResult(status, excludedEnum, siteName, viewMode, relativePath);

URLRewriter 是来自第三方包 (Kentico CMS - CMS.URLRewritingEngine.dll) 的类。我在那个 DLL 上运行了 Dependency Walker，发现 ICSharpCode.SharpZipLib 上没有任何依赖关系。

任何想法如何解决这个问题？

编辑：在@JeremyThompson 的建议下，我运行了进程监视器来捕获错误。这是一个屏幕转储，突出显示了相关部分（出于隐私原因，一个文件夹名称被隐藏了）。您可以通过右键单击它来查看它的全尺寸等...

编辑：这是来自错误的负载跟踪。这有帮助吗？

=== 预绑定状态信息 ===

日志：用户 = MY-SERVER-12\Administrator

日志：DisplayName = ICSharpCode.SharpZipLib，版本=0.85.3.365，文化=中性，PublicKeyToken=1b03e6acf1164f73 （完全指定）

日志：Appbase = file:///C:/inetpub/wwwroot/MySite/

日志：初始 PrivatePath = C:\inetpub\wwwroot\MySite\bin

调用程序集：CMS.WebAnalytics，Version=6.0.4377.2467，Culture=neutral，PublicKeyToken=834b12a258f213f9。

===

LOG：此绑定在默认加载上下文中开始。

LOG：使用应用程序配置文件：C:\inetpub\wwwroot\MySite\web.config

LOG：使用主机配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

LOG：使用 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config 中的机器配置文件。

日志：政策后参考：ICSharpCode.SharpZipLib，Version=0.85.3.365，Culture=neutral，PublicKeyToken=1b03e6acf1164f73

日志：正在尝试下载新的 URL 文件：///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/9760eb69/275bb3db/ICSharpCode.SharpZipLib.DLL。

日志：正在尝试下载新的 URL 文件：///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/9760eb69/275bb3db/ICSharpCode.SharpZipLib/ICSharpCode.SharpZipLib。动态链接库。

日志：正在尝试下载新的 URL 文件：///C:/inetpub/wwwroot/MySite/bin/ICSharpCode.SharpZipLib.DLL。

日志：正在尝试下载新的 URL 文件：///C:/inetpub/wwwroot/MySite/bin/ICSharpCode.SharpZipLib/ICSharpCode.SharpZipLib.DLL。

日志：正在尝试下载新的 URL 文件：///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/9760eb69/275bb3db/ICSharpCode.SharpZipLib.EXE。

日志：正在尝试下载新的 URL 文件：///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/9760eb69/275bb3db/ICSharpCode.SharpZipLib/ICSharpCode.SharpZipLib。可执行文件。

日志：正在尝试下载新的 URL 文件：///C:/inetpub/wwwroot/MySite/bin/ICSharpCode.SharpZipLib.EXE。

日志：正在尝试下载新的 URL 文件：///C:/inetpub/wwwroot/MySite/bin/ICSharpCode.SharpZipLib/ICSharpCode.SharpZipLib.EXE。

【问题讨论】：

嗨 Shual，这只是为了 ping Kentico 团队，我过去曾与他们打过交道，他们是***人物。我相信他们现在会在公共论坛上看一下这个。这家伙：@PetrPalas (***.com/users/1430236/petr-palas)，他真的很好。

【参考方案1】：

现在我知道我确实依赖于这个 DLL，但我有版本 0.85.5 在我的系统上。我从服务器系统地删除了每个旧版本的 DLL，重新编译并重新发布。

听起来“依赖项”需要 OLDER 版本的 DLL。为什么不使用 OLDER 版本 (0.85.3.365) 在您的系统上REPLACE NEWER 版本 (0.85.5) 的所有副本？ （确保同时检查 Web 应用程序的“bin”文件夹和“GAC”：c:\windows\assemblies）

如果需要，可以在这里下载旧版本：http://sourceforge.net/projects/sharpdevelop/files/SharpZipLib/0.85.3/

注意：

更换DLL后，停止IIS并清除所有Temporary ASP.Net 文件。例如。： C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET 文件 另外：记得更新您的 Visual Studio 解决方案，以便 引用旧版本。

干杯

皮特

【讨论】：

好吧，事实证明，我不需要更新版本的 DLL 中的任何东西，所以这个解决方案实际上对我有用。尽管从知识的角度来看，这是一个非常不令人满意的解决方案，但它确实可以解决问题，因此可以为您提供荣誉和赏金。谢谢！

【参考方案2】：

事实证明，Kentico 对ICSharpCode.SharpZipZip.dll 有自己的依赖关系——它期待找到旧版本。我找到了类似的解决方案here。通过将以下块插入到我的 web.config 文件中，我似乎终于消除了这个错误！

<runtime>
  <assemblyBinding>
    <dependentAssembly>
      <assemblyIdentity name="ICSharpCode.SharpZipLib" publicKeyToken="1b03e6acf1164f73"/>
      <bindingRedirect oldVersion="0.85.3.365" newVersion="0.85.5.452"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>

我仍然不明白的是，为什么 Dependency Tracker 没有显示这种依赖关系？

编辑：哦，天哪，这毕竟没有解决它。现在似乎不太频繁了，但是今天重新启动 IIS 后，我们的一位测试人员又收到了旧的错误消息！ :-(

【讨论】：

这就是我为绑定重定向所做的 => 从 0 到 .85.5.452 的任何内容（这意味着它将包括 .85.3.365 ... 使用 85.5.452。例如 @ 987654324@

【参考方案3】：

您提到用户第一次或两次访问该网站时您会收到错误消息。

要解决此问题，我建议您运行 Process Monitor 并查看它在哪里查找和加载程序集。

-iisreset -在服务器上启动进程监视器 -查看几页并尽快重现问题 -停止 ProcessMonitor 跟踪 - 在进程监视器跟踪中搜索ICSharpCode.SharpZipLib

如果失败了，看看还有什么原因：

-将 ProcessMonitor 结果保存为 CSV - 在 Excel 中打开 CSV -过滤所有列 -选择带有拒绝访问的列的下拉列表或...

这应该告诉你错误Could not load file or assembly的问题是什么

【讨论】：

感谢您的建议。我确实发现 IIS 工作进程 (w3wp.exe) 正在注册表和文件系统中寻找该 DLL 的 v0.85.3 并得到“未找到名称”或“未找到路径”......直到几百微秒后，当它找到 DLL 的 0.85.5 版本时。这告诉我们什么？

实际上，它似乎正在尝试（并且失败）在 GAC 中“创建文件”，然后在 .NET 临时文件夹中，然后在 bin 文件夹中成功执行“创建文件”我的网站。为什么是“创建文件”，而不是“读取文件”？

【参考方案4】：

我认为您在绑定重定向方面走在了正确的轨道上。但是，我建议您尝试将依赖程序集与较新版本绑定，而不是将您的应用与旧版本绑定。

通常，强制使用旧版本是更糟糕的选择，因为虽然它可能会修复依赖的程序集，但您可以将兼容性错误注入到依赖于新版本的代码中。

【讨论】：

我不明白...我正在绑定新版本...？还是我的代码中混杂了一些东西？

【参考方案5】：

尝试附加到 AppDomain.CurrentDomain.AssemblyResolve，这样您就可以查看何时/什么程序集加载并明确设置加载位置。

【讨论】：

怎么样？在哪里？请提供代码示例？

或使用程序集绑定日志查看器 (Fuslogvw.exe) 查看程序集是如何被探测的 msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx ---- 并查看 ---- ***.com/questions/255669/…

这篇文章并不是回答问题的实际尝试。请注意Stack Overflow doesn't work like a discussion forum，这是一个问答网站，每个帖子都是问题或问题的答案。帖子也可以有comments - 像这样的小句子 - 可用于批评或要求作者澄清。这应该是评论或new question。

【参考方案6】：

您可以使用 Fuslogvw.exe 应用程序记录程序集加载并提供有关加载错误的详细信息。

在此处阅读更多信息：http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

【参考方案7】：

Kentico CMS 和您的应用程序是否定义在同一个应用程序池中？尝试在自己的应用程序池中运行您的应用程序。

可能发生的情况是，当工作进程被回收时，有时您的应用程序是第一个被添加的，有时 Kentico CMS 是第一个被添加的，这会改变 ICSharpCode.SharpZipLib 的解析方式。

当您偶然刷新一次或两次时，您的应用程序首先被加载，这意味着它可以工作。

What is Application Pool in IIS and Asp.Net?

更新：您的应用程序是网站（首次访问时编译）还是 Web 项目（在 Visual Studio 中预编译）。如果它是一个网站，那么您可以转换为一个 Web 项目并尝试一下吗？

【讨论】：

它们都部署在同一个网站下，所以确保它们使用的是同一个应用程序池... :)