ASP.NET DLL 地狱答案

【问题标题】：ASP.NET DLL hellASP.NET DLL 地狱
【发布时间】：2008-11-26 13:39:10
【问题描述】：

我有第三方工作流软件 (Captaris Teamplate)，它引用了我的项目中的一个程序集，它通过 GAC 引用了我们项目解决方案中的其他程序集。

当我们的应用程序执行时，它会调用 Captaris Teamplate 方法来创建一个工作流程，该流程又使用 GAC 中的项目程序集将数据存储到一个数据库。

问题是当我编译我的项目并从 GAC 中删除程序集并用新版本替换它们时，但是当我运行整个项目时，Captaris Teamplate 抛出一个错误：

异常类型：System.IO.FileNotFoundException
消息：找不到文件或程序集名称 VBAssembly 或其依赖项之一。
文件名：VBAssembly
FusionLog: === 预绑定状态信息 ===
日志：DisplayName = VBAssembly，Version=0.0.0.0，Culture=neutral，PublicKeyToken=null

也就是说，它不会给我程序集 DLL 文件的名称。它试图找到它正在寻找的版本。此类问题的故障排除就像在黑暗中射击，它可以杀死保存在 ASP.NET 临时文件夹、项目文件夹和网站文件夹 (inetpub) 中的旧程序集、重新启动等、测试错误、出现错误，搜索其他一些旧程序集等。

所以我的问题是：

是否有一种技术可以让我提取有关此异常的更多信息，例如缺少的程序集名称和版本？
是否有一种简单的方法可以在编译时从系统中清除所有旧的程序集版本？
在处理此 DLL Hell 和/或 Captaris Teamplate 时还有其他建议吗？

我们将 ASP.NET 1.1 版与带有 Captaris Workflow 5.0 的 Visual Studio 2003 结合使用。

【问题讨论】：

标签： asp.net assemblies dll captaris

【解决方案1】：

您可以做的另一件事是“强制”通过 web.config 引用您想要的程序集版本。这是我在 web.config 中的示例，以确保我在我的网络应用程序中访问正确版本的 Crystal Reports...

<assemblies>       
   <add assembly="CrystalDecisions.Web, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692FBEA5521E1304"/>
   <add assembly="CrystalDecisions.Shared, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692FBEA5521E1304"/>
   <add assembly="CrystalDecisions.ReportSource, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692FBEA5521E1304"/>
   <add assembly="CrystalDecisions.Enterprise.Framework, Version=11.5.3300.0, Culture=neutral, PublicKeyToken=692FBEA5521E1304"/>            
</assemblies>

我相信你可以做同样的事情来引用你的库，你只需要确保它们有一个强大的命名密钥，以便有一个 PublicKeyToken 可以引用。

【讨论】：

如果同一版本的gac中存在asm，则始终使用gac的。

【解决方案2】：

如果可能，请避开 GAC。它适用于 DLL Hell。 VBAssembly 可能实际上是非托管的，并且可能已从 WINDOWS/system32 目录中删除。

【讨论】：

【解决方案3】：

也许您可以创建一个绑定策略，将针对您从 XXX 删除到 GAC 的程序集的任何请求重定向到新位置。请参阅Binding Policy。

【讨论】：

是的，一个 BindingRedirect (msdn.microsoft.com/en-us/library/eftw1fys.aspx) 可以添加到从 machine.config 到应用程序根 web.config 的任何位置可能会有所帮助。

【解决方案4】：

或者你可以使用.NET Reflector。

但是，您也可能只想致电供应商并寻求他们的帮助。大多数时候，这些人对他们的产品感到非常自豪，所以他们会花时间通过电子邮件或聊天来引导您解决问题。我刚刚在使用的第三方电子表格组件中遇到了类似的问题，即使该公司在德国，我也能够通过让他们重新编译组件并在他们发送给我时快速解决问题新的 DLL 它工作得很好。

【讨论】：

【解决方案5】：

可能最有效的方法是运行FusLogVW.exe（.NET Framework SDK 的一部分，请参阅Assembly Binding Log Viewer (Fuslogvw.exe)），它将记录发生的每个绑定失败。这样，您可以列出应用程序中失败的绑定尝试。

【讨论】：

【解决方案6】：

使用Dependency Walker 找出缺少的依赖项。

【讨论】：

【解决方案7】：

一个起点是尝试使用'Clean Solution' 选项，然后构建解决方案。

【讨论】：