C# deserialization of System.Type throws for a type from a loaded assembly

Question

I have an application a.exe which is running fine and has loaded an assembly b.dll, which is a Prism module if that matters. This dll is loaded from a directory that is not in the path but is in the directory where a.exe resides.

Loading of the assembly is done by Prism, and is set up like this:

public class MyModuleCatalog : ComposablePartCatalog
{
  private readonly AggregateCatalog _catalog;

  public MyModuleCatalog()
  {
      //directory Modules is not in the path, but all
      //dependencies of b.dll are, so b.dll gets loaded fine
    var asmCat = new AssemblyCatalog( "Modules/b.dll" );
    _catalog.Catalogs.Add( asmCat );
  }

  public override IQueryable<ComposablePartDefinition> Parts
  {
    get { return _catalog.Parts; }
  }
}

class BootStrapper : MefBootstrapper
{
  ....
  protected override void ConfigureAggregateCatalog()
  {
    base.ConfigureAggregateCatalog();

    AggregateCatalog.Catalogs.Add( new AssemblyCatalog( Assembly.GetExecutingAssembly() ) );
    AggregateCatalog.Catalogs.Add( new MyModuleCatalog() );
  }
  ....
}

In b.dll there is a class ImInB:

[Export]
public class ImInB
{
  public void DoIt()
  {
    try
    {
      var stream = new MemoryStream();
      //using System.Runtime.Serialization.Formatters.
      var formatter = new BinaryBinaryFormatter();

        //serialize our type
      formatter.Serialize( stream, this.GetType() );

        //get it back
      stream.Position = 0;
      var obj = formatter.Deserialize( stream ); //this throws??
    }
    catch( Exception e )
    {
    }
  }
}

This is just example code, and is part of a persisting framework that loads/saves settings to a database. The object's type is always serialized and serves as akey to the database. Upon deserializing, the type is retrieved back as a double check against the object that gets loaded. The function gets called from a.exe:

container.GetExportedValue<ImInB>().DoIt();

The exception thrown upon deserializing the type (whih was serialized sucessfully two lines earlier) is:

"Could not load file or assembly 'b.dll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies. The system cannot find the file specified."

Questions:

• How is this even possible? The function gets called from within the dll, yet is says it cannot find that dll.
• How do I fix this? How do I tell Deserialize hey, that dll is already loaded, don't go looking for it

UPDATE my second question is basically answered by Felix K; the following code fixes the problem:

public static class AssemblyResolverFix
{
  //Looks up the assembly in the set of currently loaded assemblies,
  //and returns it if the name matches. Else returns null.
  public static Assembly HandleAssemblyResolve( object sender, ResolveEventArgs args )
  {
    foreach( var ass in AppDomain.CurrentDomain.GetAssemblies() )
      if( ass.FullName == args.Name )
        return ass;
    return null;
  }
}

//in main
AppDomain.CurrentDomain.AssemblyResolve += AssemblyResolverFix.HandleAssemblyResolve;

This also proves that the assembly is effectively loaded, including all of it's dependencies, so the first question remains: it's a mistery to me why the framework cannot figure this out by itself. Moreover I cannot reproduce it in a second application that uses roughly the same structure.

Answer 1

I don't know why this happens when the dll is already loaded but i think this has nothing to do with the serialization itself, it looks like a .NET error to me.

This might gonna help you, or points you in the right direction:

AppDomain current = AppDomain.CurrentDomain;
current.AssemblyResolve += new ResolveEventHandler(HandleAssemblyResolve);

static Assembly HandleAssemblyResolve(object sender, ResolveEventArgs args)
{
    /* Load the assembly specified in 'args' here and return it, 
       if the assembly is already loaded you can return it here */
}

Everytime when a dll is missing the resolve method is called, so this should also happen when your dll is missing. dotNET can't find it because it's in the "Modules" folder so you have to resolve the reference by yourself.

Answer 2

Type identity is a fickle thing. These two blog posts from the inimitable Suzanne Cook really cleared it up for me a few years ago:

LoadFile vs LoadFrom: http://blogs.msdn.com/b/suzcook/archive/2003/09/19/loadfile-vs-loadfrom.aspx Choosing a Binding Context: http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx