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:

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?
Is there an easy way to clean up all those old assembly versions from the system at compile time?
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.

score 1 · Answer 1 · edited Apr 23 '12 at 18:07

1

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.

edited Apr 23 '12 at 18:07

Peter Mortensen

30,738
21
105
131

answered Nov 26 '08 at 15:57

Aaron Fischer

20,853
18
75
116

score 1 · Answer 2 · answered Nov 26 '08 at 16:03

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.

If there is an asm in the gac of the same version, then the gac'ed one will always be used. — StingyJack, Dec 09 '08 at 13:01

score 1 · Answer 3 · edited Apr 23 '12 at 18:10

1

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.

edited Apr 23 '12 at 18:10

Peter Mortensen

30,738
21
105
131

answered Nov 26 '08 at 16:09

Yep, a BindingRedirect (http://msdn.microsoft.com/en-us/library/eftw1fys.aspx) which can be added anywhere from machine.config up to the application root web.config may well help. – Zhaph - Ben Duguid Apr 25 '09 at 15:09

score 1 · Answer 4 · edited Sep 09 '12 at 21:30

1

Use Dependency Walker to find out what dependency is missing.

edited Sep 09 '12 at 21:30

Peter Mortensen

30,738
21
105
131

answered Nov 26 '08 at 16:26

StingyJack

19,041
10
63
122

score 1 · Answer 5 · edited Apr 23 '12 at 18:11

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.

score 1 · Answer 6 · edited Apr 23 '12 at 18:13

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.

edited Apr 23 '12 at 18:13

Peter Mortensen

30,738
21
105
131

answered Dec 09 '08 at 12:55

Jox

7,132
14
49
63

score 0 · Answer 7 · edited May 23 '17 at 12:01

0

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

edited May 23 '17 at 12:01

Community

1
1

answered Nov 26 '08 at 13:46

Julius A

38,062
26
74
96

ASP.NET DLL hell

7 Answers7