Implementing Plugin Architecture - Dynamic DLL loa

问题:

I've an application which is basically a designer with preloaded controls where you can design your pages using the controls.

I'm planning to release more and more controls in the future. I don't want to release a new build for newly added controls as it has its disadvantages. So I was thinking of addon/plugin kind of architecture where I just release the addon/plugin separately which they can install and get the controls inside the designer.

Right now I'm using xml files as addons to specify the controls, its behaviors, its styles etc. Each xml (addon) represents a single control. But I'm finding it very difficult to implement this since I've to write a generic parser to read all the plugins.

Instead, can I release a dll for each addon which gives me more control to write code to define the behavior/look of the control and dynamically load it through the main engine? If so how can I check for dlls and load it dynamically in my application?

回答1:

You might want to look at the Managed Extensibility Framework. This will probably solve most of your issues and more, but will require learning some new tech...

You should also definitely look into the System.Addin Namespace as mathieu suggests!

If you want to go with your own route, I suggest the following approach:

• an interface for addons in your main application
• implement that interface in addon dlls
• load the dlls at runtime with Assembly.Load
  • you might want to look into loading the addon assemblies into a separate AppDomain

回答2:

You should have a look at System.Addin namespace, as it really fits your need. After an addin is developped, you just have to drop it in a folder, and it is available (at runtime) for your application.

• http://kentb.blogspot.com/2008/06/maf-gymnastics-skeletal-solution.html

See this question for comparison : Choosing between MEF and MAF (System.AddIn)

回答3:

The MEF or System.Addins routes mentioned are likely the most efficient way to go about this. I only pipe in to say a few things about the alternatives.

I have "hand rolled" this sort of solution a number of times and I would say that unless there is a compelling reason to do it from scratch it is better to use an existing addin framework. But if you are going to do so, I have found dependency injection containers like Castle or (insert your preferred DI container here) to be help handle some of the mechanics.

Also depending on exactly the sort of thing you are looking to do, the approach of embedding a macro language is potentially useful. Iron Python is easily embeddable. And Ayende wrote a very interesting book DSLs in Boo on doing this sort of thing and much more.