Question

The traditional procedure to develop a plugin architecture seems to be to create a separate DLL containing only the common interface that all plugins will implement, and make both the core app and the plugins depend on that.

I’m trying to do just the same, but without a separate interface dll. One obvious way is to make all plugins depend on the core app, but that’s hardly a pretty solution.

Can you think of prettier solution? Ideally, there wouldn’t be a dll bundling the interface; if that’s impossible, the it would be pretty cool if a user that doesn’t intend to run plugins wouldn’t need to download the plugin dll at all. Taht way, only those who run plugins need the interface DLL.

Answer 1

You could load the assembly and access its types through Reflection. There are some examples here: http://www.csharp-examples.net/reflection-examples/, and I’ve extracted some of the more interesting ones:

Assembly testAssembly = Assembly.LoadFile(@"c:\Test.dll");
Type calcType = testAssembly.GetType("Test.Calculator");
object calcInstance = Activator.CreateInstance(calcType);

// Get property value
PropertyInfo numberPropertyInfo = calcType.GetProperty("Number");
double value = (double)numberPropertyInfo.GetValue(calcInstance, null);

....

// invoke public instance method: public void Clear()
calcType.InvokeMember("Clear",
     BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.Public,
     null, calcInstance, null);

You can mandate that plugins are written in certain ways so that you know which classes to instantiate and which methods to call, and so on. Essentially, an informal interface that is expressed via documentation rather than through code.

Now, this is not a good way to implement a plugin architecture, because you lose a lot of compile-time checking when writing plugins, and generally speaking it’s better to take the hit of deploying the extra DLL.