How to Develop Dynamic Plug-In Based Functionality in C#_问答_开发者

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

开发者 https://www.devze.com 2023-01-01 13:44 出处：网络

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

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 i开发者_StackOverflownto developing my own plug-in architecture and reading up on MEF.

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.

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.