IsAssignableFrom() returns false when it should return true

Question

I am working on a plugin system that loads .dll's contained in a specified folder. I am then using reflection to load the assemblies, iterate through the types they contain and identify any that implement my IPlugin interface.

I am checking this with code similar to the following:

foreach(Type t in myTypes )
{
    if( typeof(IPlugin).IsAssignableFrom(t) )
    {
       ...
    }
}

For some reason IsAssignableFrom() keeps returning false when it should be returning true. I have tried replacing the t by explicitly giving it a type that should pass, and it works fine, but for some reason it isn't working with the types that are returned from the loaded assembly. To make things stranger, the code works fine on my co-worker's machine but not on mine.

Does anyone know of anything that might cause this sort of behavior?

Thanks

Answer 1

That typically happens when there's a mismatch between the assembly which contains the type IPlugin that the current assembly references, and the assembly which is referenced by the assembly containg the types you're iterating over.

I suggest you print:

typeof (IPlugin).Module.FullyQualifiedName

and

foreach (var type in t.GetInterfaces ()) 
{    
    Console.WriteLine (type.Module.FullyQualifiedName)
}

To see where the mismatch is.

Answer 2

I had same issue when interface was defined in a separate assembly to implementing type. Iterating and loading assemblies from root folder that contained dlls with classes AND dll with interface resulted in type mismatch as mentioned above.

One solution was to change LoadFrom() to LoadFile() The LoadFrom method has some disadvantages and that is one of them:

If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified.

Another way to overcome this is to place all dlls with types implementing interface into separate folder and not to copy referenced assembly (CopyLocal = False) so Assembly.LoadFrom will not load dll containing interface in memory.

Answer 3

Some other answers have mentioned the lack of clarity in the name of the IsAssignableFrom method. I agree, and as a result was using it in the wrong way.

Try a little experimenting with reversing the objects in your code and see if it works. For example:

Replace:

if (typeof(IPlugin).IsAssignableFrom(t))

with:

if (t.IsAssignableFrom(typeof(IPlugin)))

By doing this I not only got it to work, but began to understand what this method actually does.

Answer 4

Sometimes it's an issue with the dynamic assembly referencing another assembly.

One simple thing to do it to disable local copy on the assembly (in visual studio right click the reference and set copy local to false). This should make it easier to nail down the directory where the assembly lives.

You can also implement an assembly resolver in-case .NET doesn't know how to initalize the type.

        AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler([Resolve Function]);

Answer 5

If you are using .net core and are following the tutorial on this link then please make sure you remember to add this to your plugin project

<ItemGroup>
    <ProjectReference Include="..\PluginBase\PluginBase.csproj">
        <Private>false</Private>
        <ExcludeAssets>runtime</ExcludeAssets>
    </ProjectReference>
</ItemGroup>

as described in the link. You get the above error if you don't. This also helped me

Answer 6

I work in Java which has the same API method and I just can't get my mind to grok it when reading the code (for some reason); therefore, I always read it in reverse as, in your case, "t is assignable to IPlugin). So if C# has "is" as Jonathon suggests, I would always use it - when reflecting in Java "instanceof" does not work for Class objects, only instances of the object.

Answer 7

I had a similar issue which was caused due to dependency injection into plugins. Assume that assembly contains a definition of MyConcreteClass which implements ISomeInterface. MyConcreteClass constructor requires the dependencies I added to the serviceProvider. I am trying to instantiate the object using

 using Microsoft.Extensions.DependencyInjection;

 private IEnumerable<ISomeInterface> CreatePlugins(Assembly assembly)
 {
        ServiceCollection serviceCollestion = new ServiceCollection();
        serviceCollestion.AddSingleton(dependency1);
        serviceCollestion.AddSingleton(dependency2);
        serviceCollestion.AddSingleton(dependency3);
        var serviceProvider = serviceCollestion.BuildServiceProvider();

        foreach (Type type in assembly.GetTypes())
        {
            if (typeof(My.Namespace.ISomeInterface).IsAssignableFrom(type))
            {
                ISomeInterface result = ActivatorUtilities.CreateInstance(serviceProvider, type) as ISomeInterface;
            }
        }
 }

I got the exception:

Unable to resolve service for type 'My.Namespace.ISomeInterface' while attempting to activate 'Another.Namespace.MyConcreteClass'. at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider) at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.CreateInstance(IServiceProvider provider, Type instanceType, Object[] parameters)

I then found out that the process which called ActivatorUtilities.CreateInstance was already referencing a dependency of MyConcreteClass and that's why the instantiation failed. In order resolve this I followed the advice from the link below and cleared the folder of Another.Namespace from any assembly referenced by my process prior to loading it.

.NET: Unable to cast object to interface it implements

Answer 8

In my case was a dependency issue (even if the module names were identical). Check and add your level 1 dependencies for the plugin but they are not in the main app/shell (e.g. Oracle dll, some other nuget that is used only by the plugin). Once they are there (i.e. next to the plugin), it will return true.

Answer 9

The name of the Type.IsAssignableFrom method is vague and confusing when applied to testing inheritance or detecting interface implementations. The following wrapper for these purposes would make a lot more sense:

    public static bool CanBeTreatedAsType(this Type CurrentType, Type TypeToCompareWith)
    {
        // Always return false if either Type is null
        if (CurrentType == null || TypeToCompareWith == null)
            return false;

        // Return the result of the assignability test
        return TypeToCompareWith.IsAssignableFrom(CurrentType);
    }

Then, one can have more understandable application code such as:

    bool CanBeTreatedAs = typeof(SimpleChildClass).CanBeTreatedAsType(typeof(SimpleClass));
    CanBeTreatedAs = typeof(SimpleClass).CanBeTreatedAsType(typeof(IDisposable));

The advantage of this method instead of the 'is' keyword is that it can be used at run-time to test unknown, arbitrary Types, whereas the 'is' keyword (and a generic Type parameter) requires compile-time knowledge of specific Types.