Managed Extensibility Framework Preview Available

A few months ago we announced that we are working on a Managed Externality Framework and there was a lot of feedback just on the announcement!   Today we posted the very first CTP of MEF.    I would love to get your feedback on this. 

Many people have noted that the industry has not yet achieved the level of code reuse the Object Oriented Design promised.  One of the reasons for this is the tight coupling that most OO systems tend allow.  Over the last few months (and for some of us, years) we have thought deeply about how we can encourage more reuse.    We believe MEF is part of the solution. 

The MEF provides developers with a framework to easily add extensibility to their applications and with minimal impact on existing code. The application developer can define extension points according to the functionality required of an extension, while the extension developer uses those points to interact with the application.
MEF enables this extensibility to take place without creating a hard dependency in either direction. Applications can be extended at run time without recompilation, and extensions can be used by multiple applications sharing the same extension requirements. MEF also allows an application to delay the loading of an extension while still examining its metadata, enabling efficient traversal of large catalogs of extensions.

There are some great samples included:

HelloWorld: A very simple example to show the concepts.   The Button's Caption is determined at runtime by what component is added.  This can be changed at runtime, and customized based on user, etc.

public MyHelloWorld()
CompositionContainer container =
new CompositionContainer();


//Alternatively, comment the above and
//use the DateStringProvider:

// container.AddComponent<DateStringProvider>(new
// DateStringProvider());


//theButton.Content = "Hello World!";
public String ButtonCaption
get { return theButton.Content.ToString(); }
set { theButton.Content = value; }

DirectoryWatching: a "Hello World" example, using Directory Watching rather than manual component insertion.  You can simply drop a DLL into a directory to enable new functionality in the app

Calculator: a stack-based calculator example..  You can add some "advanced" opperations that happen to be written in VB just by dropping the extension into a directory. 


You gotta have a game right??    Simply open the file menu to load some additional shapes


XFileExplorer: a MEF-based file explorer

Again, we'd love to have your feedback and thoughts on this very, very early preview.

Comments (8)

  1. This sounds like a "plugin-model". What is the difference between System.AddIn and MEF?

  2. BradA says:

    >>This sounds like a "plugin-model". What is the difference between System.AddIn and MEF?

    Robert — someone already asked 😉  see a detailed answer here:

  3. Eisenberg says:

    Here’s another question.  What’s the difference between this and Unity or any other DI container?  Furthermore, haven’t we (the majority of the community that’s been using DI for a while) established that using attributes for injection is not the best approach?  Perhaps I’m missing a nuance of your implementation.

  4. You’ve been kicked (a good thing) – Trackback from

  5. Shaun says:

    I don’t really see what this gives you over just using a DI container

  6. Robert Barth says:

    In a broader sense, reuse is not really a technology problem, IMO, it is a problem of being able to discern the future. What hooks does one permit? Where? You can’t really know until you’ve come in contact with new requirements. You can guess, but that’s all you’d be doing. As long as any framework requires knowledge of the future, it wil fail to deliver the promise of reuse.

    Not that I don’t think this API isn’t a good idea: it delivers a standard way of doing something that is often required in a software solution. However, alone, I’d say it won’t increase reuse one iota. That is the work of smart software architects, who, on their best day, can only make educated guesses about the future.

  7. Eisenberg: I’ve answered your second point here: With regards to your first point, this, not surprisingly, keeps getting raised – I’ll try and get someone to post a blog entry on this.

    Robert: Thanks for the feedback. You are right, its very hard to predict the future but that’s exactly why we are releasing an early look on what we are working on – so that customers can have an impact on where we take MEF. At the same time, we’re also working with some large customers internally at Microsoft (including Visual Studio), to make sure that we not just taking a ‘stab in the dark’ at guessing what customers want.

    The way in that it promotes reuse, is by encouraging loosely coupled architectures. Yes it will be still on the software architects shoulders to get this right, but having MEF in their toolbox, means that its one less thing they need to worry about and they can focus on designing a system that matches their customer’s current and future needs.

  8. Steve Naidamast says:

    Code Reuse is not a problem with technology but has been primarily determined as an organizational problem whereby it is not encouraged in the IT areas.  

    Code Reuse requires repositories at different levels but rarely are they ever part of any IT organization’s infrastructure.  The second major factor here is a lack of discipline that reuse requires as much as repositories.

    Providing a new framework to promote code reuse won’t do much given the current situations within companies, it will simply promote the use of another framework…

Skip to main content