One of the key thought that comes up as we scratch the surface of MEF is...So what's new? I can use reflection and do that. It's important to understand that MEF is not a magic wand that can dynamically discover "altogether new" functionalities and dynamically plug it in an app. I don't think the programming world has reached up to that level yet where a program is as powerful as a human mind (which by far is the strongest processing machine to date).

If a human is exposed to new things then he has obvious and predictable actions/reactions. E.g. -

1. If someone gives me a book, I know it's a book, I look at the preface section, I look at the index and then I know whether to read the entire book or some sections inside it or just not read it. However, if someone hands me a book that is written in a language that I don't understand, the least I would know is that "This looks like a book" but that's about it. Full stop.
2. You place a ball in my hand. My mind, perhaps by experience knows whether it's a cricket ball, a soccer ball, a football, a tennis ball, etc. And based on that I will try to discover additional equipment that I might have to actually use that ball. E.g. I might look for a bat or soccer shoes or a tennis racquet.

MEF is pretty much the same thing. The application has to know what interface the new/dynamic component is going to expose. The component by-n-large can tweak the functionality specific to it's existence. The application has to be aware of what it is going to expect and clearly communicate that to the external world. I can't blind-fold you and then expect you to know and recognize which object I am throwing at you and to also know how to use it. :) lol.

So to say:

1. An MEF compliant application doesn't need to know the inner workings of the component that is dynamically going to be discovered. Note the component is discovered, but the interface is already know to the application.
2. An MEF application can be compared to an abstraction or a standard that promotes effective reusability of components.
3. As long as the MEF application is capable of publicly declaring that "I can understand and execute an Interface X with functionality Foo", all is good.

A simple yet great example that Sanjay Vyas (a.k.a Guruji) gave me was: Let's say my MEF application (let's say App A) understands an interface called IPrinter that has a Print method. Then there are several possibilities:

1. The developer can write his component / plug-in (e.g. which Prints to a printer) against this interface without worrying about how the App A will discover, load it and execute it.
2. The same component can be plugged into another app B which also complies to IPrinter interface with Print method.
3. The developer of neither App A or B or the component itself have to write any pieces of complex reflection code or some config file based code to dynamically discover and used the component.
4. Moreover another developer can implement the same interface and write a component that prints to a PDF file and drop the assembly into the path required by the application and the application can there-after dynamically discover this new component. The fact remains that the app will still be able to only call the Print method of the component. If the new component has a "Sing" method, the application will slap you back! (just kidding...no it will not know what to do with it and it won't even discover it).

In short what we are making available is a framework which will promote in-app, cross-app, cross-vendor reusability. It's a solid vision and it will take time to first establish itself as a standard that developers start adopting and adapting to. It's all about simplifying the not-so standard process of dynamically loading a plug-in. We (Microsoft) take care of the framework, you (end-user developer) just focuses on the functionality or the business problem that the component is trying to solve.

I hope that helps to clarify the thought.

My humble thanks to Sanjay for sharing his insight. It's important to understand the problem that exists, before really jumping to using a technology that is created or brought into existence to solve that problem :) [Well, it's another thing to not know that the problem was actually a problem :)]

Cheers!