views:

1610

answers:

3

As part of our migration from .net 1.1 to .net 3.5, we had to change out a few vender DLLs.

One of them is giving us trouble in only 1 spot out of the 4 spots we use it at:

The trouble spot is a windows form project that uses reflection to dynamically load some DLLs that run long running processes. One of these long running processes is an agent that relies on one of our vender DLLs

We're getting the missing assembly exception at the point where we first enter a function that references the library. I already checked the silly things such as if we had forgotten to move a reference from the old version to the new version, but that's not the case. I also checked the bin directory of the project and the assembly is there.

Has anyone encountered a situation in which .net 2.0 runtime refuses to load an assembly like that? And if so, how could we fix the issue.

Additional Information:

The specific vendor in this case is dtSearch and this is the boundry where the error gets thrown:

Private Sub BuildIndex()
    SetIndexOptions()
    ExecuteIndexJob()
End Sub

Private Sub SetIndexOptions()
    'Body removed for brevity
End Sub

The library is referenced in SetIndexOptions. BuildIndex() gets entered, but the exception happens when SetIndexOptions gets called. The function is never actually entered.

+1  A: 

The FileNotFoundException can be raised even when the assembly does exist if one of the dependent assemblies couldn't be loaded.

Try using Dependency Walker to check and see that all dependent assemblies are also present.

Kragen
Well, this complicates things. The DLL I'm trying to load says it's missing two DLLs that I've never heard of (IESHIMS.DLL and WER.DLL if it means anything), but at the same time, the .net 1.1 version of the DLL is also missing these components and had been functioning fine.
Evan Larkin
Those 2 assemblies are most likely red herrings - I think most assemblies I open up are missing those 2 even if they work fine.
Kragen
So the DLL is fine then?
Evan Larkin
Yes - according to Dependency Walker. Try fusion logging, or possibly using Reflector to walk through and open all the referenced assemblies.
Kragen
+2  A: 

If you are still having problems you can use the Assembly Binding Log Viewer (Fuslogvw.exe) to identify which assemblies are loaded by your application. This tool is part of the .NET Framework. This will provide you with details on all dependent assemblies.

I have used this in the past when working with third party assemblies, very usefull

Rohan West
A: 

Turns out the default compile option changed from VS2003 to VS2008 and it was compiling in the wrong bitness :\ Now I feel a bit silly!

Evan Larkin