How to Develop Dynamic Plug-In Based Functionality in C#

Question

I've been looking around for different methods of providing plug-in support for my application. Ideally, I will be creating a core functionality and based on different customers developing different plug-ins/addons such as importing, exporting data etc... What are the some methods available for making a C# application extensible via a plug-in architecture?

Lets make up an example. If we have a program that consists of a main menu ( File, Edit, View, et al. ) along with a TreeView that displays different brands of cars grouped by manufacturer ( Ford, GM, for now). Right clicking on a car displays a context menu with the only option being 'delete car'.

How could you develop the application so that plug-ins could be deployed so that you could allow one customer to see a new brand in the TreeView, let's say Honda, and also extent the car context menu so that they may now 'paint a car'?

In Eclipse/RCP development this is easily handled by extension points and plug-ins. How does C# handle it? I've been looking into developing my own plug-in architecture and reading up on MEF.

Towardly

Answer 1

MEF would be a good place to start.

Glenn Block's article Managed Extensibility Framework: Building Composable Apps in .NET 4 with the Managed Extensibility Framework provides a good overview.

BTW, don't be fooled by the title - you can also get MEF for .NET 3.5 SP1.

Allegro

I've watched a number of MEF videos which show the use of loading assemblies, catelogs, and containers however I have yet to fully understand how MEF allows you to deploy a plugin that modifies your main menu or a context menu for a given control. I guess I'm missing the final jump from what the videos portray and allowing my application to response to the presents of plugins i,e. adding a new menu button to the main menu for example. – Towardly

That should become easier to figure out if you use MVVM (msdn.microsoft.com/en-us/magazine/dd419663.aspx). This would enable you to bind Menus and MenuItems to an underlying (pluggable) object model. – Allegro

Answer 2

Visual Studio 2010 uses MEF, so I think its a safe bet this is the preferred way to go at MS. System.Addin always seemed a bit heavy, but it might be a better choice if you need addins to always work and your codebase is constantly evolving.

If you care about isolating addins, you should read up on AppDomains. I've got a demo project which I made to help learn how to deal with isolating assemblies within an AppDomain here, which you might find interesting. Quick facts about isolation: Only your types should ever cross the boundary and these types should be sealed, run screaming from cross domain event handling, and addins should NEVER extend MarshallByRefObject.

Leporid