Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

IsAssignableFrom() returns false when it should return true

Tags:

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

like image 415
bingles Avatar asked Dec 05 '08 22:12

bingles


2 Answers

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.

like image 152
Jb Evain Avatar answered Sep 22 '22 18:09

Jb Evain


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.

like image 26
elm Avatar answered Sep 21 '22 18:09

elm