The Managed Extensibility Framework (MEF) and Managed AddIn Framework (MAF, aka System.AddIn) seem to accomplish very similar tasks. According to this Stack Overflow question, Is MEF a replacement for System.Addin?, you can even use both at the same time.
When would you choose to use one vs. the other? Under what circumstances would you choose to use both together?
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 compatability 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.
Checkout http://kentb.blogspot.com/2009/02/maf-and-mef.html for some more details.
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.
In my view the two technologies actually target very different use cases.
MEF is typically best in a pure dependency injection scenario where the person or group delivering the final integrated solution is assembling everything and vouching for the overall integrity but has a need to have different implementations of key capabilities.
MAF is for a scenario where someone/group is developing a platform or host and other groups will add capabilities after the fact and in a way not under the control of the host group. In this scenario the need is for more elaborate mechanisms to "protect" the host from rogue add-ins (or to protect add-ins from each other).
A third similar-in-pattern technology is the whole ProviderBase scheme. This also enables replacing a capability but its goal is really the scenario where the host/app absolutely needs a capability and the need is really to specify different implementations via config.
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.
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:
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.
Licensing based on purchased components. We could control which AddIn were loaded by the user's role and permisions and wether the AddIn was licensed for use.
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.
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.
Scalability (add components as they are developed and released and they ”just work”). Scaling is only a matter of making and AddIn and installing the file. No other considerations were necessary!
New components worked with old components. AddIn that were developed early on kept on working. New AddIns fit into the Application seamlessly
I have to wonder why Visual Studio 2010 uses MEF, if the stability argument above is accurate.