Is it possible to assign an interface to an object at runtime?

After thinking about all the great answers I received in the previous question about modeling my code in order to maximize code reuse , I began to wonder if the interface can be assigned to an object at runtime, and not when it is encoded.

Take, for example, the simplified part of the code from my previous question :

public class OutboxManager { private IVendorMessenger _VendorMessenger; //This is the default constructor, forcing the consumer to provide //the implementation of IVendorMessenger. public OutboxManager(IVendorMessenger messenger) { _VendorMessenger = messenger; } public void DistributeOutboxMessages() { VendorMessenger.SendMessageToVendor() _OutboxMgrDataProvider.MarkMessageAsProcessed(om) } } 

Currently, if someone wants to use this class, he should encode a class that implements IVendorMessenger and provides it as a parameter during initialization:

  var MyOutboxManger = new OutboxManager(new MyVendorMessenger()) 

What if, instead of hard coding an interface parameter, it is parsed instead at runtime? That way, I could compile the dll for a class that implements IVendorMessenger , drop it into the same folder that OutboxManagerExecutable exists, and connect to everything at runtime. I suppose, using this logic, I could find a way to drop multiple IVendorMessenger implementations in the same folder and create an executable to be smart enough to go through all the corresponding DLLs and consume them accordingly.

Is this type of functionality possible in .NET 4?

+4
source share
5 answers

Check out the Managed Extensibility Framework (MEF) . It can automatically make dependencies of your application in the same way as you describe. It comes with .NET 4.0.

+4
source

This is a fairly common use case. API.NET gives you the snippets you need:

After that, you have an Object that you can apply to IVendorMessenger and pass it.

+2
source

Are you thinking about using MEF? It allows you to create an assembly of applications from several modules.

You can see it here

+1
source

EDIT: I just realized that I misunderstood the question. Actually, the question is not related to the purpose of the interface for the object at runtime, but rather for later names such as bindings.

I will leave the answer as a Community Wiki if someone else has the same misconception.


This is usually called Interface Injection and is on the wish list for both the CLI and the JVM as long as they exist.

Especially people who write implementations for programming languages ​​that were not originally intended for the CLI or JVM, such as JRuby, XRuby, Ruby.NET, IronRuby, IronPython, Jython, Rhino, IronJS, etc., have this function on their wish list, because this means that they no longer need to maintain a parallel type hierarchy and marshal objects between them.

However, they do not seem to be on the horizon any time soon, or even at all, although for the JVM there is at least a specification of straw with an accompanying partial prototype implementation for the Da Vinci machine.

+1
source

You can do it just fine (class wisely) in .Net 2.0 / 3.0 with Generics .

You can also use Reflection to load dlls at runtime .

+1
source

All Articles