Choosing between MEF and MAF (System.AddIn)

Question

The Managed Extensibility Framework (MEF) and Managed AddIn Framework (MAF, aka System.AddIn) seem to accomplish very similar tasks. According to this Stack Overflow questio

Answer 1

I just found this lengthy article discussing both MAF and MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

In addition to the points made by the other answers, it sounds as if one of the key differences between MEF and MAF is that the Managed Extensibility Framework would allow one composable part to depend on another. It would let a plug-in depend upon another plug-in, for example.

The Managed Extensibility Framework also doesn't really make distinctions between the host and the add-in, as the System.AddIn does. As far as MEF is concerned, they're all just composable parts.

Answer 2

MAF and MEF both can use AppDomains and both can load/unload dll in runtime. However the differences I have found are: MAF AddIns are decoupled, MEF components are loose coupled; MAF "Activates" (new instance) while MEF makes instances by default.

With MEF you can use Generics to make GenericHost for any contract. This means the MEF load/unload and component management can be in a common library and used generically.

Answer 3

In my opinion, the best way to discover the differences is some hands-on code. I found two MSDN walkthroughs, both with a calculator example so you can easily compare their implementations:

MEF: Simple calculator example using MEF parts
(Managed Extensibility Framework)

• Shows how to build up a simple calculator using MEF technology. Does not show how to load external dlls. (But you can simply modify the example by using catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); instead of using catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); and extract the calculator code and contract to separate DLL projects.)

• MEF does not need to have a specific directory structure, it is simple and straightforward to use, even for small projects. It works with attributes, to declare what is exported, which is easy to read and understand. Example: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF does not automatically deal with versioning

MAF: Simple calculator with V1 and V2 version MAF plugins
(Managed Addin Framework)

• Shows how to build up the calculator by using a V1 plugin and then how to move over to a V2 plugin while maintaining backwards-compatibility (note: you can find the V2 version of the plugin here, the link in the original article is broken)
• MAF enforces a specific directory structure, and it needs a lot of boilerplate code to make it work, hence I don't recommend it for small projects. Example:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

Both MEF and MAF are included in the .NET Framework 4.x. If you compare the two examples you will notice that the MAF plugins have a lot more complexity compared with the MEF framework - so you need to think carefully when to use which of those frameworks.

Answer 4

Having developed and shipped a MAF application. My views on MAF are somewhat jaded.

MAF is a "de-coupled" system or "loosely-coupled" system at worst. MEF is "coupled" system or "loosely-couple" system at best.

MAF benefits that we realized by using MAF are:

1. Installing new or updating existing components while the application is running. The AddIn could be updated while the Application was running and the updates appear to the user seamlessly. You have to have AppDomains for that.

2. Licensing based on purchased components. We could control which AddIn were loaded by the user's role and permissions and whether the AddIn was licensed for use.

3. Rapid development (quicker time-to-market). The AddIn development fits perfectly with Agile methodolgy, the development team developed one AddIn at a time without having to also develop the integration piece with the rest of the application.

4. Improved QA (only QA one component at a time). QA could then test and issue defects for a single bit of functionality. The test cases were easier to develop and implement.

5. Deployment (add components as they are developed and released and they ”just work”). Deployment is only a matter of making an AddIn and installing the file. No other considerations were necessary!

6. New components worked with old components. AddIn that were developed early on kept on working. New AddIns fit into the Application seamlessly

Answer 5

I've been evaluating these options and here's the conclusion that I came to.

MAF is a true addon framework. You can separate your addons completely, even running them inside a separate app domain so that if an addon crashes, it won't take down your application. It also provides a very complete way of decoupling the addons from depending on anything but the contract you give them. In fact, you can versionize your contract adapters to provide backwards compatibility to old addons while you are upgrading the main App. While this sounds great, it comes with a heavy price you have to pay in order to cross appdomains. You pay this price in speed and also in the flexibility of the types that you can send back and forth.

MEF is more like dependency injection with some additional benefits such as discoverability and ... (drawing a blank on this one). The degree of isolation that MAF has is not present in MEF. They are two different frameworks for two different things.

Answer 6

What Danielg said is good. I would add:

If you watch the videos about System.Addins, they are clearly talking about very large projects. He talks about one team managing the host application, another team managing each AddIn, and a third team managing the contract and the pipeline. Based on that, I think System.Addins is clearly for larger applications. I'm thinking applications such as ERP systems like SAP (maybe not that big, but you get the idea). If you watched those videos you can tell that the amount of work to use System.Addins is very large. It would work well if you had a lot of companies programming 3rd party add-ins for your system and you can't break any of those add-in contracts under penalty of death.

On the other hand, MEF seems to share more similarities to SharpDevelop's add-in scheme, the Eclipse plugin architecture or Mono.Addins. It's much easier to understand than System.Addins and I believe it to be a lot more flexible. The things you lose are that you don't get AppDomain isolation or strong versioning contracts out-of-the-box with MEF. MEF's strengths are that you can structure your entire application as a composition of parts, so you can ship your product in different configurations for different customers, and if the customer buys a new feature, you just drop the part for that feature into their install directory and the application sees it and runs it. It also facilitates testing. You can instantiate the object you want to test and feed it mock objects for all its dependencies, but when it runs as a composed application, the composition process automatically hooks all the real objects together.

The most important point I'd like to mention is that even though System.Addins is in the framework already, I don't see a lot of evidence of people using it, but MEF is just sitting there on CodePlex supposedly to be included in .NET 4, and people are already starting to build lots of applications with it (myself included). I think that tells you something about the two frameworks.