ASP.NET DLL hell

Question

I have third-party workflow software (Captaris Teamplate) that's referencing an assembly from my project that's referencing other assemblies from our project solution all through the 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.

The problem is when I compile my project and remove assemblies from GAC replacing them with new versions, but when I run entire project, Captaris Teamplate throws an error:

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

That is, it wouldn't give me the name of the assembly DLL file. It's trying to find nor version it's looking for. Troubleshooting of such an issue is like shooting in the dark and it can kill days of deleting old assemblies that are kept in the ASP.NET temporary files folder, project folder and website folder (inetpub), rebooting, etc., testing for error, getting an error, searching for some other old assemblies, etc.

So my questions are:

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?

We're using ASP.NET version 1.1 with Visual Studio 2003 with Captaris Workflow 5.0.

Answer 1

Probably the most effective way is to run FusLogVW.exe (part of .NET Framework SDK, see Assembly Binding Log Viewer (Fuslogvw.exe)), which will log every bind failure that happens. That way, you can list failed binding attempts from your application.

Answer 2

A starting point is to try to use the 'Clean Solution' option and then build the solution.

Answer 3

If at all possible, avoid the GAC. It lends itself to DLL Hell. The VBAssembly may actually be unmanaged, and may have been removed from the WINDOWS/system32 directory.

Answer 4

Another thing you can do is "forcibly" reference the version of the assembly you want through the web.config. Here's a sample of what I have in my web.config to make sure I'm accessing the proper version of Crystal Reports in my web app...

<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>

I'm sure you could do the same thing to reference your libraryies, you just need to make sure they have a strong naming key so that there is a PublicKeyToken to reference.

Answer 5

Maybe you can create a binding policy that will redirect any request for the assembly you removed from the XXX to the GAC to the new location. See Binding Policy.

Answer 6

Use Dependency Walker to find out what dependency is missing.

Answer 7

Or you can use .NET Reflector.

However, you also may just want to call up the vendor and ask for help from them. Most of the time, these guys take a pretty good pride in their products so they will take the time to step you through your problem over email or chat. I just ran into a similar issue with a third-party spreadsheet component that I was using and even though the company was in Germany, I was able to resolve the issue pretty quickly by having them recompile the component on their end and when they sent me the new DLL it worked just fine.