DLL 版本控制错误答案

【问题标题】：DLL versioning errorDLL 版本控制错误
【发布时间】：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 (stackoverflow.com/users/1430236/petr-palas)，他真的很好。

标签： c# asp.net iis dll sharpziplib

【解决方案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 ---- 并查看 ---- stackoverflow.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 项目并尝试一下吗？

【讨论】：

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