When are .Net interfaces considered to be equivalent?

Question

I am writing code to implement a plug-in type of architecture. I have defined an interface, let's call it IThing in the namespace MyStuff, for the plug-in and I also have code to dynamically create an instance of the plug-in from a DLL. My code does this by looking through exposes classes, fields and methods and ultimately testing what it finds with:

if (typeof(IThing).IsAssignableFrom(instType))

This is all fine and works OK when the interface is implemented by something in my own code, i.e. referencing the assembly that provides the MyStuff.IThing definition.

Another developer, in another company located in a different country, is writing the pluggable component.

I sent the interface definition, i.e. the C# source, for MyStuff.IThing to the developer and he included it in his code.

The problem we saw first is that his component, even though it implemented MyStuff.IThing, would fail the above IsAssignableFrom test. The reason for the failure seems to be that he has the interface definition in a different assembly (naturally), even though it has the same namespace and the interface definition has not changed. The solution here is simple enough, which is that I send him the assembly DLL containing the interface.

My question is this: given that the namespace matches and the interface definition is identical, why should it matter which assembly it is found in? If assembly A contains MyStuff.IThing with exactly the same interface definition as MyStuff.IThing in assembly B, why are those assemblies not interchangeable for the purposes of an application that wants to work with an instance of MyStuff.IThing?

Answer 1

given that the namespace matches and the interface definition is identical, why should it matter which assembly it is found in?

The choice of treating these interfaces as equivalent would make it harder to compare interfaces: rather than comparing a fixed set of items (i.e. the qualified name and the assembly) CLR would need to compare the qualified name, and the list of all properties and all methods, along with their argument types, which would be recursive. Doing so would be prohibitively slow, especially if you want to do it consistently and include classes and structs into a similar comparison scheme.

Note: when you share a DLL with the developer in another country, make sure that your assembly has a strong name. This would ensure that you both link to the same assembly, and detect mismatches early. For example, if you change your interface, but the other developer sends you a plug-in compiled with an old DLL, the plugin would fail to load.

Answer 2

.NET does not check the properties and their types and make a conclusion for equivalences.

In your case, the simplest way would be putting your interfaces in a class library and share that DLL with those who'd like to implement the interface.