Assembly conflict when using Type.IsAssignableFrom(Type)

Question

I am loading a DLL dynamically into an Assembly. My problem is when I try to use System.Reflection to get a certain type from that loaded assembly, that I want to use to create an instance of that type. The type I want happens to be an interface.

This is based on code that I have used successfully in the past, but for a new project, it fails. The problem seems to be that the types being compared are from two different assemblies.

Here is the code:

IMyInterface _classInstance;

String path = Path.Combine(Application.StartupPath, "mydynamic.dll");
if (File.Exists(path))
{
   Byte[] ba = File.ReadAllBytes(path);
   if (ba.Length > 0)
   {
      Assembly dll = Assembly.Load(ba);
      if (dll != null)
      {
         foreach (Type T in dll.GetTypes())
         {
            if (typeof(IMyInterface).IsAssignableFrom(T))
               _classInstance = (IMyInterface)Activator.CreateInstance(T);
         }
      }
   }
}

Using the advice from this question, I was able to determine that typeof(IMyInterface).Module.FullyQualifiedName returns the executing application (the EXE I am debugging). That, of course, does not match what I see for T.Module.FullyQualifiedName, which is the DLL.

I would like to resolve this without injecting some go-between assembly that does nothing but provide the type, if that is possible.

Maybe I misread your question, but you cannot create instances of interfaces - only instances of classes implementing those interfaces. — xxbbcc, Nov 12 '14 at 20:45
@xxbbcc In this case, it would work because the type that passes the test will be one that implements the interface, making the cast appropriate. — DonBoitnott, Nov 12 '14 at 20:46
Ah, ok, I saw that in your code now. I commented based on the text above the code example. :) — xxbbcc, Nov 12 '14 at 20:47
Do you get a run-time exception or is `_classInstance` just null after the code executes? — Philip Pittle, Nov 12 '14 at 21:13
And you are sure that the hosting application is referencing the same version of the assembly that contains `IMyInterface` as `mydynamic.dll` — Philip Pittle, Nov 12 '14 at 21:16
Where do you declare `IMyInterface`? The code you show will work if and only if you are actually dealing with the same type. The type you use in your loop _must_ be the same type that the DLL is using. See also [Managed Extensibility Framework](http://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx), as it may be applicable to your scenario. — Peter Duniho, Nov 12 '14 at 21:31
@PhilipPittle No exceptions. The match is never found, and the object remains `null`. — DonBoitnott, Nov 13 '14 at 12:00
@PeterDuniho The actual declaration is in both places. It's declared in a code page that is linked in each project. So both the EXE that is running, and the individual DLLs both know of `IMyInterface`. It's the single bit of glue that all rely on to do work. This is necessary because the EXE needs to be able to call a standard set of methods, while leaving the implementation to the DLL that has been loaded. — DonBoitnott, Nov 13 '14 at 12:02
@PeterDuniho Futher, I think I stated that I realize it's finding the type in two places, and thus failing the match. The very question is what I can/should do about that problem. — DonBoitnott, Nov 13 '14 at 12:02

score 0 · Answer 1 · answered Nov 13 '14 at 13:18

Satisfaction for the curious...

The answer came down to making a small concession in the project design. Instead of linking the interface class (code page) into each project, and allowing each project to be its own stand-alone entity, I had to only reference that class in the main EXE project. And instead of incorporating their own links to IMyInterface , the individual DLLs make a an assembly reference to that EXE project.

This resolved the incompatibility issue between the EXE's type and the loaded DLL's type.

I say "small concession" because the design was always to have a DLL in the EXE's working directory that would be loaded at runtime, so the project reference changes nothing philosophically.

Assembly conflict when using Type.IsAssignableFrom(Type)

1 Answers1