Exception on receiving Assembly reference from another AppDomain

Question

I am loading all DLLs from a specific "extensions" directory in a new AppDomain to get some Reflection related information out of those.

This is what I'm trying:

I created a new library AssemblyProxy in my solution which just has this class:

public class AssemblyProxy : MarshalByRefObject
{
    public Assembly LoadFile( string assemblyPath )
    {
      try
      {
        return Assembly.LoadFile( assemblyPath );
      }
      catch
      {
        return null;
      }
    }
}

I make sure this DLL is present inside my "extensions" directory. Then I use the following code to load all assemblies from "extensions" directory into the new AppDomain.

foreach( string extensionFile in Directory.GetFiles( ExtensionsDirectory, "*.dll" ) )
{
        Type type = typeof( AssemblyProxy.AssemblyProxy );
        var value = (AssemblyProxy.AssemblyProxy) Domain.CreateInstanceAndUnwrap(
            type.Assembly.FullName,
            type.FullName );

        var extensionAssembly = value.LoadFile( extensionFile );

        types.AddRange( extensionAssembly.GetTypes() );
}

Some DLLs do get loaded successfully but on some DLLs an exception is thrown like this:

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

EDIT: The exception is not thrown in the new AppDomain. The DLL gets successfully loaded in the new AppDomain. The exception gets thrown as soon as the assembly reference is returned to the main/calling AppDomain. Does the main/calling AppDomain try to load the assembly on its own on just receiving the reference?

Thanks.

Isn't ReflectionLoadOnly sufficient for your (untold) purposes? — Christian.K
@ConradFrix ReflectionOnlyLoad does load the assembly in the current AppDomain, just not its dependencies. As far as I am aware you cannot unload them from the current AppDomain. — C.Evenhuis
@ConradFrix: there are other reasons to. Like just scanning the assemblies or to build plugin systems (scan assembly after plugins & unload it if there are none + unload plugins which isn't used anymore) — jgauffin
@user1004959: Because you are returning Assembly. You will need to create a safe serializable/remotable object to transfer that info. As soon as a type crosses the boundary, you are screwed ;p — leppie

Panos Rontogiannis Panos Rontogiannis · Accepted Answer · 2013-01-04T10:47:16

You should not return an Assembly object from the new AppDomain because this will only work if you main AppDomain has access to those assemblies which it does not since the assemblies are located in a directory that:

is not the AppDomain's base directory (AppDomain.BaseDirectory),
is not in the directories specified in the AppDomain's relative search path (AppDomain.PrivateBinPath)

One way to avoid this to follow the leppie's comment and:

Create a serialized type that includes the minimum information you need from the Assembly object.
Add this type to new assembly that both AppDomain's have access to. The simplest way to do this by adding it to the GAC.

Another approach would be to use Mono.Cecil instead of System.Reflection. Mono.Cecil will allow you to inspect assemblies without loading them. For a very simple example look at the second half from this answer.

Exception on receiving Assembly reference from another AppDomain

1 Answers