MEF & Silverlight 4 Beta - Part 1, Introduction

Play MEF & Silverlight 4 Beta - Part 1, Introduction
Sign in to queue


Part 1 of a series of screencasts looking at the new Managed Extensibility Framework (MEF) in the Silverlight 4 beta.

MEF is a framework that simplifies the design of extensible applications and components. It can flexibly and dynamically discover a set of loosely coupled components and analyse their dependencies in order to compose them together at run time.

In this screencast, we talk briefly around the idea of components having imports and exports and then we drop into Visual Studio 2010 and do a quick, "magic" demo of how MEF can plug together a couple of components for us. In later videos, we'll attempt to dig deeper into what MEF is doing and how we can take more control of it.

Tips for viewing:

  • Each video in this series has a 3.5 minute standard introductory "header" on it so once you have seen that header you may like to skip it on subsequent videos
  • For the time pressured - I find that I speak so slowly that you can speed me up to approximately 1.5-2.0 times normal speed and still listen comfortably.

I'm working to get together a Live Meeting in early 2010 with people from the MEF team in order that people can chat more about MEF in Silverlight. Stay tuned.

The next screencast in this series is here.



Right click to download this episode

The Discussion

  • User profile image
    Ben Hayat

    Mike, you're such a great teacher! Smiley

  • User profile image

    Mike, I have a different question.


    I realize these are simple examples, but my question is why use MEF if I already have access to the types?  You have a reference to WordProcessor, etc., so why the extra code for MEF?


    Even if the the assembly is delay loaded, and even if you need polymorphic text engines, you still have a reference to these items.  What "value add" do you get from MEF(which is my seminal question).


    BTW, I do agree with Ben Hayat, you are a great teacher, I loved your series on Unity... awesome!

  • User profile image

    Great video!  I was waiting for such guideline for PRISM and MEF integration.  Good job, Mike.



  • User profile image



    Yes, good point but this is the first video Smiley and just provides a very quick intro rather than walking through all that MEF can do for you. I appreciate it can feel a little "over the top" when all the types are in the same assembly - by video 3 or 4 we'll have them in separate assemblies and then in separate XAPs so that may help make it feel a bit more real.


    However, sticking to the example in this video which has an Application type, a WordProcessor type & a TextEngine type...


    What I can do is to implement my Application by coding to an IWordProcessor interface and, in turn, I can implement my WordProcessor by coding to an ITextEngine interface.


    That way, I can implement my slices of functionality without having to worry about how other pieces of functionality are implemented and I can also test that functionality in isolation from those other pieces. That is - I can test the WordProcessor with a mocked-up TextEngine that implements ITextEngine.


    I can do that with/without MEF and with/without a format Inversion of Control container like Unity.


    But what MEF gives me is the ability for the WordProcessor to state its "requirement for a TextEngine" and to satisfy that requirement in a range of different ways without the WordProcessor having to do anything explicit or take any dependencies other than to attribute itself up and call PartInitializer.SatifsyImports().


    The WordProcessor expresses a contract for what it needs to import ( a TextEngine ) - the contract specifies that it is a TextEngine that's needed, how many engines are needed, whether they are optional, whether there are any requirements around lifetime, whether it is ok for the implementation to change over the lifetime of the application. ( that all happens in the next video ).


    The WordProcessor doesn't know or care where the TextEngine comes from. MEF will sort that out and will do the right thing around safely matching the import requirements of the WordProcessor to any export contracts it finds for implementations of TextEngines.  MEF has built in and extensible facilities for locating TextEngine candidates in lots of different places - the same assembly, the same XAP, another assembly, another XAP, etc.


    The flip-side of what MEF brings is that the TextEngine ( the exporter ) does not have to "know very much either". It does not have to go through some "registration step" in order to introduce itself to MEF. It simply gets discovered wherever it happens to live.


    I hope that helps a little.



  • User profile image

    Thanks Mike.


    There's an old statement in politics:  It's the ECONOMY STUPID!


    In this case:  It's COMPOSITION STUPID!  Now I get it!


    That's the value add, along with the sweetness of having an IOC in the process.  Glenn Block has stated this a lot, but I guess I read it, but didn't internalize it... now I have.



  • User profile image

    I created an example very similiar to yours. One change I made was to have the object being created in the main page scoped as being private and not public. When I did this I get an error message


     "Attempt by method 'System.ComponentModel.Composition.ReflectionModel.ReflectionProperty.SetValue(System.Object, System.Object)' to access method 'MEFTest.MainPage.set_mypanel(MEFTest.Panel)' failed.


    When I change it to public it works. Why does the scope change cause this error message?


    I have gone through all of the videos and they have really helped me make sense of this whole MEF concept better. I have tried to follow some other discussions of this and I ended up almost lost.


    Thanks again.

  • User profile image



    I think I mention this in one of the videos - your properties/fields do need to be public in order that MEF can use reflection to set the values. As far as I know, in Silverlight, reflection cannot changed private members.



  • User profile image

    Hi Mike,


    Yes I did catch that bit after I asked the question. Thanks.

  • User profile image

    Wow, this is one great video.  The concepts are very well explained. I am going to see the rest of the videos from Mike. Keep up the great job, Mike.

  • User profile image

    Mike - 


    I was wondering if you had any plans for a write-up contrasting MEF and Unity/Prism? It would be helpful to understand the differences and similarities so one can make an informed decision in choosing the right framework.

  • User profile image



    I don't have a plan to try and do that. Unity's a stand alone framework for Inversion of Control. PRISM is (in my mind) a higher level beast that adds things like catalogs, eventing, UI regions based on Unity ( or A.N.Other IoC container ) and so adds value with those things that it brings.


    MEF can be viewed as IoC but it's really (to me) more about extensible apps that discover parts and support the idea of parts changing over time so it has some overlap with Unity and some overlap with bits of PRISM but then also has its own unique capabilities. You could use MEF to build another PRISM ( as noted in David's post over here ).



  • User profile image



    You are GURU for MVVM.

    Flow, delivery and presentation is great.

    I learned PRISM from your 10 Video series.

    I have watched your PRISM 10 videos 3 times.

    Now learning MEF.

    Great video.

  • User profile image
    Thundar Viking

    I just followed the example that Mike Taulty demonstrates in this video. The example works great, besides one little code line that seems to have to be changed to make it work, at least that is what I experienced:



    With: CompositionInitializer.SatisfyImports(this);



    The class resides in System.ComponentModel.Composition and the line goes into the place where the PartInitializer is being used (constructor of MainPage).


    -= The somewhat civilized Barbarian =-

  • User profile image
    Thundar Viking

    Very fun to observe how MEF uses its automatic "type inference magic" to discover classes exporting themselves or interfaces. The way one could implement a pluggable, extensible environment for an application seems like a clear path for me. Are there hidden challenges along the way, i.e. if one would implement an application with several plugins perhaps using [ImportMany] of a given interface, it all looks very tempting to follow that tracks, but are there some things one should avoid while going down that path or is MEF just plain simple, elegant and wonderful ? (rhetoric there at the end Big Smile )

Add Your 2 Cents