C# Loading an Interface (not a class) at runtime from a DLL

Question

Here on stackoverflow there are plenty of good answers concerning how to load a class from a DLL at runtime. However, they seem to all imply that at compilation time the interface implemented by the class is known to both the loading app and the DLL. Hence the question: knowing the name, is it possible to load an interface from a DLL rather than the class implementing it?

`interface` implies implementation which can resides in class only. — Hamlet Hakobyan, Sep 23 '13 at 12:38
They can be loaded in the same way as classes. However, the reason for having an interface in the first place is so that the loading app and "plugin" understand each other. So I'm puzzled as to why you'd want to load an interface in this way. Could you give a code example of what you are trying to achieve? — David Arno, Sep 23 '13 at 12:38
This might be useful: http://stackoverflow.com/a/26750/261050. All you have to change is the check for an interface. But how are you going to communicate with the object if you do not know the interface? — Maarten, Sep 23 '13 at 12:58
David, indeed it might not be practical to do it in any other way than by referencing an interface DLL in both the implementation DLL and the consumer code. But suppose DLL developer and DLL consumer developer have agreed on a -documented- set of interfaces. -Theoretically- they don't need an interface DLL in common as the consumer code knows what to find and how to use it simply by using names. I guess it doesn't really take long to make a DLL out of some documented specifications. But I was wondering if it is a technically avoidable step, even though it might not be practical to do so. — manu3d, Sep 23 '13 at 19:45
Maarten, my comment/reply to David might shed some light: the interface is known, but only because it is documented in textual form somewhere. In the scenario I'm dealing with the object would be provided as a service by a service manager. Consumer objects could find the service by searching for it using the interface name, a string. Then they'd call methods and modify properties by name rather than directly, perhaps creating a wrapper class on the fly. But indeed it does beg the question why do that if you can simply reference the interface. ;) — manu3d, Sep 23 '13 at 19:55
By the way, Marteen, if you could convert your comment into an answer, specifically showing code to check and store an object coming from the DLL into an interface type, I'd happy to accept it the answer. — manu3d, Sep 23 '13 at 20:02
If C# supported duck/structured typing, I could see how your idea would work. You load a set of interfaces in a dll at runtime that match a set of names and things could all be mapped together. However just knowing the name ISomething isn't enough to allow Something and SomethingElse to implement it. You need that interface dll at compile-time for ISomething to be checked against Something and SomethingElse's implementations. Unless you are planning on bypassing conventional interface use and developing some sort of duck-typing framework, I don't think your idea could work in practice. — David Arno, Sep 24 '13 at 09:41

score 1 · Answer 1 · answered Sep 23 '13 at 12:38

1

You could try something like a plug-in approach: A known (rather expected) class in the target DLL that resolves the implementation for you. This way, only the implementing DLL has to know about the implementation.

The Managed Extensibility Framework provides this functionality for you.

answered Sep 23 '13 at 12:38

Myrtle

5,761
33
47

Thanks Maurice, indeed a plug-in approach is underlying my question. I am aware of MEF. First however I'd like to understand how it can be done quick and dirty. Then I can have a look how the Pros do it.. =) – manu3d Sep 23 '13 at 19:59
1

QD could be reflection.Scan the target assembly for objects that implement the interface and use the Activator class to instantiate them using the retrieved type. – Myrtle Sep 23 '13 at 20:15

score 0 · Answer 2 · answered Nov 11 '14 at 16:28

0

public interface IWorker
{
    void DoWork();
}
// wrap engineer in engineering.dll
public class Engineer:IWorker
{
    public void DoWork(){...}
}
// wrap Chef in logistics.dll
public class Chef:IWorker
{
    public void DoWork(){...}
}
// and now load interface from dll
IWorker LoadWorkerInterface(string libName, string typeName)
{
    Assembly assy=Assembly.LoadFrom(libName);
    Type t=assy.GetType(typeName);
    return Activator.CreateInstance(t) as IWorker;
}

answered Nov 11 '14 at 16:28

Willi

187
1
1
12

Notice the "as IWorker" at the end. That assumes that the loader knows about IWorker, while my original question poses a situation in which the only thing both DLL and loading app know is the interface name as a string. – manu3d Nov 11 '14 at 19:47
1

Sorry, I understood your question poor. It seems that we must query metadata of interface deep in .net framework. It looks hard. – Willi Nov 14 '14 at 13:14

C# Loading an Interface (not a class) at runtime from a DLL

2 Answers2