MEF vs. Unity vs. System.AddIn... Also, is Microsoft involved?

First of all is MEF a Microsoft project or not? Blog posts from Glen Block and Brad Abrams indicates that it is a Microsoft project. The most telling is Brads post which translates MEF to
Microsoft Extensibility Framework and not
Managed Extensibility Framework as this site does.

And now to some more technical questions...

Clearly MEF is overlapping with a lot of other libraries/technologies out there and I wonder how you differ from them. As other people already has mentioned you could draw comparisons between MEF and Unity from P&P and you could also say that MEF is trying
to solve a problem that has already been solved in the System.AddIn namespace in .NET 3.5. I would like to hear you elaborate a little further about the main differences of these tecnologies, and about which problems MEF solves better than other plugin frameworks?
I'm sure there is a premise for MEF but I just think it's unclear what it is.

My first impressions (from a user/developer point of view) of MEF, is simplicity, which is often a good thing. So if simplicity was a design goal, then congrats on a job well done! ;)

The name is Managed Extensibility Framework and we are a Microsoft project. We better be because we are shipping in a future verison of .NET :)

MEF does have some overlap, however its very specialized in what it does. It certainly has some aspects of IoC, but it is not a general purpose DI container. For example its required use of attributes, its use of catalogs, its part notion and its lifetime
story are all very different.

It IS focused solely on the extensibility / composition story. If I had to say 3 words about MEF it's Extensibility, Discovery and Composition.

MEFs simple goal is that extending apps is simply dropping a binary into a folder and you are done. We want to be a unified mechanism for doing this. We want our platform and products to use it. We want developers to have to stop reinventing the wheel everytime
they need such a mechanism.

Unity, Windsor et al, do not have this goal. They have other capabilities beyond this, but we are specialized in this which they are not.

MAF is focused on a very specific problem as well...Isolation and Versioning. That is if you need app/process isolation for addins either for managability, or security then MAF provides an answer that none other do. It makes app domains invisible to the
user, manages when they crash, and can even unload them when not in use. MAF does not provide any handling of dependencies as MEF does. So in MAF when it comes to services others need, you need to handle providing the instances. It does provide some support
for passing them, but not constructing them.

We actually think all of them can work together, using traditional IoC for your general IoC concerns, MEF for extensibility, and MAF for isolation. You'll see some stuff coming from us in the future that shows how this all comes together.

We'll be posting more about this on our blogs and in the wiki as we go forward.

Our team is working with Unity and PRISM (or CAG or CAL or whatever it's called) and we really like these technologies. Now we're starting to look into MAF and MEF, trying to figure out what they are and what they do. My comment/question is similar to Johannes'...
I'm beginning to get an idea about each one in isolation, however I'm not clear on how PRISM, Unity, MEF, MAF can all work together in an optimal way. I have some ideas, but I'd hate to spend a week developing a sample (or POC or spike or whatever
these experiments are called) if you guys are already working on one. You have more deep knowledge of these things, plus they are kind of a moving target and you, as an insider, know where they are going, so your sample would be more "correct"
than mine. You mentioned in the 9/7/2008 post, above, that we'll see some stuff on how this all comes together. Also, on 6/20/2008 you mentioned you were "planning to do a port of Prism with MEF" (http://www.codeplex.com/CompositeWPF/Thread/View.aspx?ThreadId=29380).
Is there any "official" sample or documentation showing PRISM+Unity+MEF+MAF working together as of yet? Any documentation or guidance on how to do this in an officially recommended way? Just wondering... thanks in advance, and keep up the good work
:-)

Our team is working with Unity and PRISM (or CAG or CAL or whatever it's called) and we really like these technologies. Now we're starting to look into MAF and MEF, trying to figure out what they are and what they do. My comment/question is similar to Johannes'...
I'm beginning to get an idea about each one in isolation, however I'm not clear on how PRISM, Unity, MEF, MAF can all work together in an optimal way. I have some ideas, but I'd hate to spend a week developing a sample (or POC or spike or whatever these experiments
are called) if you guys are already working on one. You have more deep knowledge of these things, plus they are kind of a moving target and you, as an insider, know where they are going, so your sample would be more "correct" than mine. You mentioned
in the 9/7/2008 post, above, that we'll see some stuff on how this all comes together. Also, on 6/20/2008 you mentioned you were "planning to do a port of Prism with MEF" (http://www.codeplex.com/CompositeWPF/Thread/View.aspx?ThreadId=29380).
Is there any "official" sample or documentation showing PRISM+Unity+MEF+MAF working together as of yet? Any documentation or guidance on how to do this in an officially recommended way? Just wondering... thanks in advance, and keep up the good work
:-)

Concerning the question of how PRISM, Unity, MEF, and MAF can all work together, I think creating a mega-RI using all of these technologies would be less benifical than having a few focused comparision-oriented demonstrations.

The active MEFContrib project will address MEF, the CompositeWPF (aka Prism) and Unity. In light of your observation I'll address MAF and MEF in a different demo, perhaps even create smaller samples with MEF+CompositeWPF and MEF+Unity.

I can appreciate/understand your observation more clearly now that I've been delving into the SandCastle project; there are a number of smaller components that are tied together with batch processing and the lack of documentation makes it somewhat overwhelming
and impractical to even try to wrap my brain around. Fortunately the Sandcastle help file builder does the job nicely so I won't even try.

For those new to Dependency injection (like I was not to long ago), MVP, PresentationModel and WPF it won't be practical to try to wrap your mind around a "mega-RI". After the current MEFContrib project is wrapped up I'm going to reel
it in and go for byte size chunks with plenty of documentation.

By the time a team of developers learn all of this and try and put all these pieces of the puzzle together and figure out all the problems hacking MEF, MAF, PRISM and RIA together, another team not using this would deliver the product, make money
and be ready to upgrade to another technology by then.

This is crazy when you can't even figure out what product does what and why. Seriously google this discussion and see if you can answer two questions:

I would want to use MEF in my application because _________________________________.

I would want to use PRISM in my application because _________________________________.

I would not want to use them BOTH because it'll slow development times and confuse my developers and be slower as now the code is going thru 5 layers before render.

*The only thing concrete is that MEF is a plugin framework of some sort that can help you if you want plugins for your product. But if you change the word plugin to model then wow it can also allow you to plugin in models for model views dynamically??
I mean is that its purpose or not?
If I was writing Adobe Photoshop I would use MEF because I want third party plugins and therefore use MEF, if I'm writing a line of business app I would use PRISM..is it so hard to validate this statement?

[razor247] I would not want to use them BOTH because it'll slow development times and confuse my developers and be slower as now the code is going thru 5 layers before render.

Speaking from experience (http://EHR.CodePlex.com) this is not a true statement, although it could be if not done correctly. I use MEF for Add-In and Prism for my WPF infrastructure (what each is intended
for). Where things being to blurr is in the dependency injection arena because you could technically use either (MEF/Unity).

As for developers - if they have the mindset of MEF, Unity and/or Prism they'll get it.

The problem is getting developers to this mindset which is why we need to be careful not to poision the water for them.

We have a huge project coming up and we are planning on using SL4. I'm working on the architecture and want to do it right. I've got the MVVM pattern down and have trained everyone on it along with pros/cons etc. This has been received with great enthusiasm.
It seems to get MVVM working thou you have to steal bits and pieces from all over. Things like Commanding for all elements not just buttons, MockDomainContexts to unit test RIA services, CustomPagedCollectionView that actually works and more heh. This
mix has been retrived from mostly Microsoft people and blogs and all mashed together and "fixed" by us. Now enter MEF and Prism. We have frameworks that load multiple pages and don't wants giant .XAPs. MEF is in the framework
v4, Prism thou seems behind the times and requires a hack to get working for SL4. Prism4 seems a ways off and we won't be able to wait for it to be done whenever they get to it so MEF will mostly likely be considered. One of my devs thou just says use .aspx
pages to host a different SL control for each page and then you don't need all this garbage and its easier to maintain. I'd love to hear any thoughts anyone has on this.

Sounds like you guys got some pretty cool stuff going on. In my
http://EHR.CodePlex.com project I'm actually going to investigate the "use .aspx pages to host a different SL control". In this project I recently setup an MVC2 website (with Unity) and am in the process of plugging in MEF Preview
9 / Prism so that I can use
multi-targeting.

Note: I added a MVC2 page, tied to a silverlight master page, which automagically passes in InitParams from the ASP.NET.
The Silverlight page's menu is dynamically generated from the Web.Config. This way I can have the best of 2 worlds - ASP.NET MVC2 and Silverlight. Both share a single configuration file (Web.Config) using stock security. Not sure what to
think about it yet...

Please let me know how it goes. I'm reading on your site now so I can see where your coming from. I'm going to Vegas for Mix and hopefully can get some more information there as well seeing as there are several MVVM discussions going on. Don't forget to
throw RIA services in the MIX :)

I will probably take you up on that suggestion, I
dabbled in RIA when it first released and am curious where it has come since then.

Wish I was going to MIX.... I'm particularly interested in the new development tools they are going to release for Windows Mobile 7. In the
http://Mobile.CodePlex.com they introduced a DI container that outperforms even Unity - this opened the door for me to multi-target WPF, Silverlight as well as Mobile infrastructural code. I'm just frustrated that
VS2010 doesn't have the mobile development platform (yet) but now I suspect I know why; they are pushing pre-mobile 7.0 off the cliff - which is fine, I'll turn my brand new HTC tilt 2 into a paperweight and get a new Mobile 7 phone but
not everyone shares my enthusiasm for moving forward without looking back....

I'd definately be interested in hearing about any cool MVVM magic upon your return...

In your example MEF does "all of the above." My blog contains several examples of this. What I'm reading is that you want to compose applications dynamically. While earlier versions of MEF did not support this, the latest previews and what will
be released in the framework do. Currently the DeploymentCatalog satisfies this need.

Therefore, if your concerns are Dependency Injection and dynamic module loading, MEF does those fine and out-of-the-box. I also feel MEF does a much better job of DI than Unity. I don't need all of the fine-grained control that Unity provides, I'm just looking
to satisfy a contract and perhaps manage the lifetime (new instance each time or singleton). MEF does this for me and it does it easily - I don't have to bootstrap the container, I can just export/import and I'm done. MEF also makes it very easy for me to
add meta-data. This way I may export an implementation for test and production and filter based on a debug flag or something similar - again, very easy. If I wrap the MEF loaded in a factory for example, it can do an import many and filter to the instance
I really want.

The other main reason I see people using PRISM is for region management. That is very easily done in MEF and I've blogged examples on that as well.

I disagree that "If I'm writing line of business, I would use PRISM." MEF can easily satisfy, I've used both and find MEF far easier to use. I'll still pull pieces from PRISM - for example, the DelegateCommand is great - but that's what is nice
about PRISM. People confuse it with an add-on, but PRISM itself is really a guidance. It's a set of patterns and practices, and the library is a reference implementation, meant to demonstrate how it could be done but not requiring that you use it. So if you
want to use the command from it, go ahead, and leave the rest - or you could pull in region management but use MEF, etc. Lots of possibilities.

Hope this helps. This is a link of all of my MEF-related blog posts, I'm part of the MEFContrib team and we're focused on pulling all of these scattered bits and pieces together into a single place with quickstarts and reference projects to make it easy
for people to grok in the future.

The name is Managed Extensibility Framework and we are a Microsoft project. We better be because we are shipping in a future verison of .NET :)

Hello Glen, I've been reading a lot about MEF these days but still a bit unsure about the product roadmap. I see MEF is currently at Preview 9 and I'm wondering when / if MEF will be changing its status away from "preview". Can we expect or have parts
of MEF already been added to NET 4.0 ?

Yes! MEF ships in the box as part of .NET 4.0 and Silverlight 4. Our codeplex bits are for community evaluation though they can also be used as-is on .NET 3.5 / SL 3.0. If you download .NET 4.0 / SL 4 you will see MEF is there.

Which version of MEF shipped with .NET 4.0? The reason I ask is that I have a project that requires MEF but must use .NET 3.5. I'd like to pick the version that most closely matches the .NET 4.0 version to reduce migration issues when we move to .NET 4.0.

Preview 9 is what shipped in .Net 4.0, however keep in mind the codeplex drop builds against .Net 3.5 and does have some #ifdefs because there are some .Net 4.0 features that are missing in .Net 3.5 so we need to workaround them. However the public API should
be exactly the same.