"System.IO.FileNotFoundException: Could not load file or assembly" when the assembly does in fact exist

Question

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.

Answer 1

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!

Answer 2

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.

Answer 3

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