Question

I want to implement a plug-in system in my .net application, without the use of MEF.

My application loads and creates instances of types, that are contained in the DLLs.

There is an interface (IPluginContract) that the main application assembly uses to load dll types, and this very same interface is used by the dll projects (the plug-ins) to implement it.

So different projects need access to the same interface.

I can realize this requirement by pushing the interface class into a separate Class Library, that both main app and the plug-ins will reference.

Is it a correct way to work around the described problem?

Answer 1

Yes, pushing your interfaces out into a shared library is a preferred solution. You then only need to distribute this library to plugin developers, which could be considered as lightweight, but the plugin will be coupled to an exact version of the interface.

Another solution is a convention based solution, where plugin writers have types that “conform” to an interface e.g. have appropriate methods on a class which they can point to via a config file. You can then use reflection, IL generation, etc, to wire this up to a concrete internal interface\proxy. The benefit here is that plugins are then not hard-wired to a specific interface version, so there is more flexibility in versioning.

You could also consider versioning by maintaining all versions of your interface e.g. IPlugin_1, IPlugin_2, etc. It’s then up to plugin writers to implement whichever version, and for you to be able to handle each version.