MEF has landed in Silverlight 4. We come in the name of extensibility.


UFO over highway B83 by Markusram.


http://www.flickr.com/photos/markusram/3641457838/


At PDC we announced that MEF has is now part of Silverlight 4.


This may sound like alien speak :-), so I’ll break it down for you. It means building maintainable/pluggable RIA apps just got a whole lot easier. 


What is MEF?


The Managed Extensibility Framework (MEF) is a new library in Silverlight 4 for building RIAs that can be incrementally extended. With MEF you extend your apps in a declarative fashion and let MEF do the plumbing rather than writing all the plumbing code yourself.



  • It’s for you and your dev team – You can add and replace functionality to the system without having modify existing code. This means you and your QA team are happy because you don’t have to worry about introducing bugs into the existing code base.

  • It’s for your customers – MEF allows you to design applications and libraries that can be extended by third-parties after they have been deployed.

  • Always there, always ready – In Silverlight, MEF is ready to go whenever and wherever you need it. You don’t have to be an acrobat, or have a masters degree in complexity 🙂 You just do it.

Also available in Silverlight 3


MEF ships as part of Silverlight 4, but we’ve also made a Silverlight compatible version of MEF available on codeplex at MEF.Codeplex.com.


The Basics


THREE concepts, that’s all you need to know to get going.


image



  • Export to tell MEF you are providing a service or capability.

  • Import to tell MEF you need something.

  • Compose It – To tell MEF to go do it!

Below you can see the basics in action for creating a Hello MEF pluggable dashboard. First we create a pluggable widget which in this case is a simple user control.


Export it


To tell MEF it’s available, we simply throw an Export attribute on it and specify the contract (in this case we use a type) you want to export it as. We could choose any type that the Widget implements, but to keep it simple, lets just use UserControl. As you can see, we don’t have to derive from any special base types, or use any interfaces, you use whatever class you would like.


image


Import It  – Import single


Notice our Widget  has a Message property. Let’s let MEF provide that rather than hardcoding it as I want it to be customizable. To tell MEF we need it, we’ll just slap on an [Import] attribute. If we don’t specify a contract for the import, it will just derive the contract as being a string. However, being that we don’t want just ANY string, we want the Message, we can specify a specific contract such as “HelloMEF.Message”.


image


Next let’s create our message which our widget(s) will import. To do this we’ll create an export, but it will use a feature of MEF called a Field Export. This is because we don’t own System.String and can’t derive from it, instead we want to somehow create an instance of a string and export it as our message. With a Field Export we can do just that as can be seen below. If our needs are beyond simply setting a value which we can do in a field, MEF also supports property exports.


image


Import It – Import many


Lastly we need our host app to discover the extensions. To do that we’ll do two things. First, we will create a public collection of type UserControl. Next we’ll add an ImportMany attribute, telling MEF that our MainPage needs all exports of UserControl to be injected into it.


image


Compose It – Satisfy imports


Next we need to somehow tell MEF to go do some work and give it to us. Doing this is very easy, we just drop into the constructor of our MainPage and call the SatisfyImports method. Once we do, our Widgets collection will be loaded up with all available widgets.


image 


Now we can simply loop through that collection and show the widgets, in this case by adding them to an Items control.


image


We’ve just seen the core essentials of MEF in SL4, that’s all it takes to get going! Our dashboard works, but it’s pretty simplistic. This is just the beginning of what is possible with MEF, we’ve literally only scratched the surface, however even with this small set of tools I’ve just given you, you can accomplish a lot! In future posts (on this blog or others 🙂 ) and in our Silverlight documentation you’ll see more about what’s possible. I covered some of this in my talk including lazy instantiation, export metadata, custom exports, dynamic recomposition, and application partitioning.


PDC talk


At PDC, I had the pleasure of delivering a talk on building extensible RIAs which is now available online here. As a highlight I was joined by Ariel Ben-Horesh of Sela, and Jackson Harper of the Moonlight team at Novell


Check out my PDC talk: Building Extensible Rich Internet Applications with the Managed Extensibility Framework. In addition to seeing MEF in action, you’ll see some work around integrating MEF with Prism and even using MEF on Moonlight, the open source Silverlight implementation. More on this in a future post!


You’ll also see how to surgically add extensibility to an existing application, and how to dynamically partition applications such that functionality is delivered on demand at runtime!


Can’t wait, want more?



  • Check out the attached demos (Yes code!) from that talk. (Requires Silverlight 4)

  • Head over to MEF.Codeplex.com and download MEF Preview 8 which contains several Silverlight samples including an extensible DataGrid. These samples work on SL3 or on SL4.

  • Check out Brad Abrams series on MEF and Silverlight

  • Check out Erik Mork’s screencast on MEF and Silverlight.

  • Check out these podcasts on MEF and Silverlight

Also watch for Jesse Liberty and Tim Heuer’s blogs as you’ll likely see some MEF/Silverlight content there VERY soon. 😉

http://cid-f8b2fd72406fb218.skydrive.live.com/self.aspx/blog/PDC09%20Demos.zip

Comments (6)

  1. Erik says:

    Great presentation!

    Where can we find the sample gameeditor application from Ariel Ben-Horesh where mef used together with prism?

    Thanks!

  2. Erik, I’ll talk to Ariel and see how he wants to get it out there. Or you can just ping him on twitter: arielbh 😉

  3. Garry Trinder says:

    You meffing had me at mefflo.

    I’m gonna go mef around with my meffing code.

    Scott Barnes

    Former Product Manager Microsoft

    Former US Netball Team player

    Former Fan of Glenn Block before he Meffed up..  

    heheh

  4. Dude you are hilarious! I miss that.

    How’s the aussie life treating you?

    Glenn

    Current fan of Scott Barnes who has not YET Meffed up 🙂

  5. Zoltan Arvai says:

    Hi Glenn!

    MEF is absolutely amazing, I love it, great job guys! I have some concerns though. For communication between to shell and the part you compose you use string based contracts. I’m refering to [Import("Whatever.Message")].

    However it seem very flexible, in practice (not in demo scenarios) I don’t really see the benefit or the reason to go that way. Why don’t you go with Interface-s? (You are using UserControls in your demos anyway) It’s typesafe, more elegant, and most of all it seems to be more practicle. I know we can go the Interface way I’m just curious why you "promote" to string based contract way?

    Thanks,

    Zoltan

  6. Hi Zoltan

    Thanks for the comments.

    In general we recommend types not strings be passed as the contract, so you are right. If you look at the widget in the example, it is exporting UserControl. It  could have exported IWdiget, but you don’t need to if there is an available interface you can use.

    The purpose of using a string contract is when you are a. exporting sealed types (like string), or b. when you have multiple instances of a particular type thus the type is not sufficent (also string) 🙂

    In the case of "Message", it is very likely there would be more than one string available. Thus using a string contract can be practical.

    Alternatively we could have create a wrapper

    type called Message and have it implement IMessage and expose Message property 🙂 But that seemed like unnecessary extra work for little gain.

    You can also use constants to represent string contracts, which is the general recommendation. Though in this case I wanted to keep it simple, and to illustrate that it was possible to use a string where appropriate.

    In general though I agree with your feedback. Please keep it coming.

    Thanks for the positive comments on MEF 🙂

    Glenn