7

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.

user1004959
  • 627
  • 6
  • 16
  • Isn't [`ReflectionLoadOnly`](http://msdn.microsoft.com/en-us/library/ms172331(v=vs.100).aspx) sufficient for your (untold) purposes? – Christian.K Jan 02 '13 at 14:56
  • What's wrong with [CreateInstanceAndUnwrap](http://msdn.microsoft.com/en-us/library/system.appdomain.createinstancefromandunwrap.aspx)? – Algirdas Jan 02 '13 at 15:01
  • @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 Jan 02 '13 at 16:07
  • @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 Jan 03 '13 at 06:51
  • @all Please see the edit in my question. Why the question was closed, I have no idea. At least 24 hours should be given to make changes. :) – user1004959 Jan 03 '13 at 08:36
  • Since it's closed, do I have to ask a new question? – user1004959 Jan 03 '13 at 08:40
  • Use `Assembly.LoadFrom` instead of `Assembly.LoadFile`. – leppie Jan 03 '13 at 08:49
  • @leppie Same exceptions. – user1004959 Jan 03 '13 at 09:21
  • @all I've realized that 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? – user1004959 Jan 03 '13 at 10:12
  • @user1004959: WRT to last comment. That will never work. As soon as the assembly or a type of it crosses the domain boundary into the primary domain, it cannot be unloaded. You might want to rethink your approach. – leppie Jan 03 '13 at 11:13
  • @leppie Why is it being loaded in primary domain at all? I just want some reflection related information available to primary domain. Like collection of all types from all assemblies of the secondary AppDomain. – user1004959 Jan 03 '13 at 11:15
  • 2
    @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 Jan 03 '13 at 11:23
  • *Why the question was closed, I have no idea. At least 24 hours...* See this feature-request [Let questions stay open for a minimum amount of time before being closed](http://meta.stackexchange.com/q/10890/148672) I guess the best thing to do to avoid a closure is to be as responsive to comments as others are to answer your question. – Conrad Frix Jan 03 '13 at 15:38
  • @leppie Are you sure there is something wrong with the `Assembly` object? Because if I use `ReflectionOnlyLoadFrom` then an object reference of same `Assembly` type gets returned successfully. – user1004959 Jan 04 '13 at 14:51
  • @user1004959: I can't say, never dealt with ReflectionOnly, but I would say the semantics might be different then. Have you tested it for side-effects? Remember, in that context, concrete types might not need to be created, so it does not infect the calling domain for 'executable' types. – leppie Jan 04 '13 at 15:10

1 Answers1

3

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:

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

  1. Create a serialized type that includes the minimum information you need from the Assembly object.
  2. 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.

Community
  • 1
  • 1
Panos Rontogiannis
  • 4,154
  • 1
  • 24
  • 29
  • Are you sure there is something wrong with the `Assembly` object? Because if I use `ReflectionOnlyLoadFrom` then an object reference of same `Assembly` type gets returned successfully. – user1004959 Jan 04 '13 at 14:48
  • @user1004959 I'm positive that returning an Assembly object is not what you should do. Perhaps the specific assembly was allready loaded to the main AppDomain. Add a breakpoint in the last line of the foreach, run the program, then use the QuickWatch feature of Visual Studio and evaluate System.AppDomain.CurrentDomain.GetAssemblies(). If you can see the loaded assembly then it was somehow loaded to your main AppDomain. Have you by any chance subscribed to the AssemblyResolve event while experimenting? – Panos Rontogiannis Jan 04 '13 at 15:53