Best practices for implementing an addin/addon/plugin strategy

views:

100

answers:

+2 Q:

Best practices for implementing an addin/addon/plugin strategy

My application should be extensible. For my own needs I have implement some services. These services are based on the IoC/DI princple. So the services encapsulate the concept of the application.

For exsample, there are an IApplicationService. The ApplicationService exposes information about the current exceuting application. There are specified the AssemblyInfo and so forth. An other exsample is the INavigationService(see mef.codeplexcom in the samples). This services provides some properties where are information about the current selected item specified and also some events.

I think, that the "service approach" is the easiest and simplifies the extension points for the application. So, I am not sure that this is really the best approach. What do you think? How do you would implement "extensions points" in an application like addins/addons/plugins ... ?

Thanks in advance for your replies! And sorry, my english is poor. ;)

+4 A:

Are you familiar with MEF (Managed Extensibility Framework)?

The Managed Extensibility Framework (or MEF for short) simplifies the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.

CD 2010-07-25 13:49:36

+1 A:

You seriously need to look at MEF - the Managed Extensibility Framework.

It's a great new framework that Microsoft itself is using in e.g. Visual Studio 2010 for its extensibility story. Great and easy to use - why reinvent the wheel when you can use something that thousands of dev will use shortly??

marc_s 2010-07-25 13:50:19

Yes, I am familiar with MEF. I also use the concept of MEF, but there some disadvantages. My application is IoC/DI like and together with MEF is a bit complicated. MEF is not really a DI container so to use MEF with an other DI container(e.g. ninject, unity, ...) is difficult to implment this. I won't to use MEF with other DI containers. So to mix MEF with other DI containers is not really good.

I hope you can understand my concern.

Addition: It is not possible to load extensions in to an AppDomain in MEF. So this is for my needs not good. System.AddIn or MAF supports this, but I won't use System.AddIn, because this is very heavy ... .

Carnation 2010-07-25 14:09:33

If you want to add information, please **update** your original post by editing it - don't add your own answer - makes it harder to follow...

marc_s 2010-07-25 14:30:14

Yes, MEF is **not** a DI container - since its job is different from a DI container. But I disagree - mixing MEF and a DI container (like StructureMap, or Unity) is really not that hard and can be done quite nicely. You might need to explain in more detail why you don't think this would work for oyu.....

marc_s 2010-07-25 14:31:13

Managing loading into an AppDomain is non-trivial and I don't think most DI frameworks will handle this either. All of your services will need to be proxied to cross the AppDomain boundary, which also means all classes that pass back and forth must be either MarshalByRef or Serializable. You might consider having one category of 'trusted' extensions (with no marshaling) and another category of 'untrusted' extensions that only get access to a limited number of marshaled services.

Dan Bryant 2010-07-25 14:41:27

On a side note, it might be possible to use MEF (or an IoC container) inside an AppDomain if you explicitly register the proxy instances to resolve the service Imports. MEF is usually configured via attributes, but it is possible to explicitly add Exports. You'd basically have a separate CompositionContainer for the AppDomain where you load the extension.

Dan Bryant 2010-07-25 14:50:22

ansaurus

tags:

views:

answers:

Best practices for implementing an addin/addon/plugin strategy

related questions