Plugins using a (assembly) reference to the host Application

I'm developing an application which i want to be expandable using plugins.

Here at SO i found many suggestions on using MEF which is a simple solution to load the plugins DLLs from a directory. The common approach would be to setup a base class or interface that plugins must inherit/implement and include that class/interface in a library assembly, i.e PluginBase.dll, that both the application and the plugin will reference.

I have two problems using this tecnique:

1. Shared classes

   There will be classes in the main application that should also be available to the plugins.

   The obvious solution is to move them to the common library assembly, still i don't think it's correct to have thoose classes in PluginBase.dll as they're not related to the plugin architecture.

   I could also make a separate DLL for such classes but that would mean that a second dll should be loaded at startup and included in the plugin for development (not really a problem, but i'd prefer newbies to just add a single reference).

2. Members visibility

   This is the real problem: I'm also writing internal plugins that have more control on the application.

   Since any member开发者_开发百科 of internally-used type would require its class to be moved to PluginBase.dll, I had to inherit a base plugin class in 2 other types (normal and internal plugin) and only put the base and normal classes on PluginBase.dll. But actually it's worse because the plugin can have a GUI or not so at the end of the day everything is doubled... this is getting too messy.

The solution (is it?)

I discovered that i can directly add a reference to the main Application in the Plugin project and doing so i can easily access any class. But also, hiding class/members is just a matter or using the internal visibility specifier. No interfaces to implement, no other assemblies to load at startup, it just seems quicker, simpler and more effective.

Are there side-effects i should be aware of using this approach?

---

The way I do it is in the same sense as this: http://rickrat.wordpress.com/2011/01/24/using-mef-to-link-view-model-locator-and-load-assembly-uis-dynamically/

The app and the plugin do not need to know about each other, they only need to reference the shared contract assembly.

Word of caution: Make sure your shared contracts dll is signed with a public key, because if MEF finds it in the addin folder (which it could be) it would try to load it twice. Having a public key it checks it against what is already loaded and does not load it again.

---

If you are using WPF, then you need to see Prism Its a nice one , may be it will helps you for making Plugin based application.