English 中文(简体)
ASP.NET DLL地狱
原标题:
  • 时间:2008-11-26 13:39:10
  •  标签:

我有第三方工作流软件(Captaris Teamplate),引用了我的项目中引用其他项目解决方案中的程序集,所有都通过GAC(全局程序集缓存)进行引用。

When our application executes, it invokes a Captaris Teamplate method to create a workflow process which in turn uses project assemblies in the GAC to store data into a database.

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

Exception Type: System.IO.FileNotFoundException
Message: File or assembly name VBAssembly, or one of its dependencies, was not found.
FileName: VBAssembly
FusionLog: === Pre-bind state information ===
LOG: DisplayName = VBAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

也就是说,它没有给我提供程序集 DLL 文件的名称。它试图找到需要的版本。解决这种问题就像是在黑暗中射击,它可能会花费数天的时间删除保存在 ASP.NET 临时文件夹、项目文件夹和网站文件夹(inetpub)中的旧程序集,重启等等,测试错误,出现错误,搜索其他旧程序集等。

所以我的问题是:

  1. Is there a technique that would allow me to extract more information on this exception such as the name of the assembly and version that is missing?
  2. Is there an easy way to clean up all those old assembly versions from the system at compile time?
  3. Any other suggestions in dealing with this DLL Hell and/or Captaris Teamplate?

我们正在使用带有Captaris Workflow 5.0的Visual Studio 2003的ASP.NET版本1.1。

问题回答

你可以做的另一件事是通过 web.config "强制" 引用你想要的程序集版本。下面是我的 web.config 样本,以确保我在我的 web 应用程序中访问正确的 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。它容易产生DLL地狱。VBAssembly实际上可能是未管理的,并且可能已从WINDOWS/system32目录中删除。

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

或者您可以使用.NET反编译器

然而,您也可以致电供应商并向他们寻求帮助。大多数情况下,这些人对其产品非常自豪,因此他们会花时间通过电子邮件或聊天为您解决问题。我遇到了一个类似的问题,我正在使用第三方电子表格组件,即使该公司位于德国,我也能通过让他们在其端重新编译组件来很快地解决问题,当他们向我发送新的DLL时,它完美运行。

可能最有效的方法是运行 FusLogVW.exe (.NET Framework SDK 的一部分,参见程序集绑定日志查看器(Fuslogvw.exe)),它会记录每一个绑定失败的情况。这样,您可以列出应用程序中失败的绑定尝试。

使用Dependency Walker找出缺失的依赖关系。

一个起点是尝试使用“清理解决方案”选项,然后构建解决方案。





相关问题
热门标签