Hanselminutes is a weekly audio talk show with noted web developer and technologist Scott Hanselman and hosted by Carl Franklin. Scott discusses utilities and tools, gives practical how-to advice, and discusses ASP.NET or Windows issues and workarounds. Text transcript of show #148 MEF - Managed Extensibility Framework with Glenn Block There's been lots of talk about MEF lately, but what the heck is it? Is it an Open Source Project or is it part of the.net Framework? Is it both? Is it an IOC Container or something new? Glenn Block sets Scott straight in this interview recorded on the Microsoft Campus. (Transcription services provided by PWOP Productions) Our Sponsors http://www.telerik.com http://www.nsoftware.com http://dotnet.sys-con.com Copyright PWOP Productions Inc. Page 1 of 8
Lawrence Ryan: From hanselminutes.com, it's Hanselminutes, a weekly discussion with web developer and technologist, Scott Hanselman, hosted by Carl Franklin. This is Lawrence Ryan, announcing show #148, recorded live Wednesday, January 28, 2009. Support for Hanselminutes is provided by Telerik RadControls, the most comprehensive suite of components for Windows Forms and ASP.NET web applications, online at www.telerik.com, and by.net Developers Journal, the world's leading.net developer magazine, online at www.sys-con.com. In this episode, Scott talks about MEF, the managed extensibility framework, with Glenn Block. Hi, this is Scott Hanselman and this is another episode of Hanselminutes. I got a cold today, I hope that won't be too distracting, but I'm sitting down here in Building 36 with Glenn Block, a program manager from MEF. It's fun to work on a project called MEF. Glenn, what is MEF? Why does it have a silly name? Well, you know, we like to come up with silly names which we change before the time we actually ship. What is MEF? That's a good question. Really what MEF is, is a technology to enable customers to build applications that have an open set of extensions where what I mean by extensions is that after an application have been deployed someone can come along and create some kind of custom addition to that application, but the difference being that with MEF you don't have to design the application to know what the finite set of things will be. It actually does kind of a discovery process to find things, and where that really becomes ideal and why we call it the Managed Extensibility Framework is, you know, if I'm developing a third party application like the CRM system and I want to have an ecosystem of different vendors that could be creating add-ons to that, you know, with MEF, they pretty much just deploy their functionality into the bin folder and the app just discovers that it's available and it shows up. Now in all of Microsoft's marketing speech right there, I didn't hear plug-ins. Is it safe to paraphrase for me to kind of take what you just said in my brain and put it back out and say MEF makes it really easy to write apps that support plugins? MEF does make it easy to write. Yes, it is a plug-in architecture. It goes a little bit further than that because when we talk about how MEF does what it does, it's actually a compositional engine. So what I'd like to compare that to is if I was going to build a traditional application where I would add in extensibility, it tends to be a model where I have a host and then there is some extensions that maybe are in a bin folder or somewhere else and might have a configuration file. With MEF, because it is a compositional model, those extensions themselves actually can be further extended all the way down the line and because it is also where the composition comes in is to provide those extensions the things they need. There's a principle in software design called Dependency Injection and we've had a whole bunch of conversations with folks that have compared MEF to something known particularly in the Open Source community as a Dependency Injection Container, but the idea of Dependency Injection is that you have a component that is not responsible for getting its dependencies. Those dependencies are pushed in. Primarily folks use Dependency Injection Containers for decoupling their systems and for testability. In the case of MEF where we're using Dependency Injection in terms of the principle, is to say that I'm an extension that's loading up. That extension is going to need some things coming from the host, or even if my extension is being extended so to speak, so we use Inversion of Control and Dependency Injection, these principles, but we use them for solving a very specific problem which is how do these third party extensions that are getting added to the system get what they need. Okay. So Dependency Injection is the idea that the object has some dependency. It needs it and it's being injected into the object as opposed to the object going off and being in control of looking for it itself. Yes. That's why we call it Inversion of Control because suddenly the core object is no longer responsible for finding its wheels, it just shows up and wheels are on it and it doesn't know where they came from. Well, and the thing that's interesting about Inversion of Control is it really relates to a thing called the Hollywood Principle which means don't call us, we'll call you. The problem, and Fowler identified this in Patterns of Enterprise Architecture, his great tome, was that almost any framework that's out there does Inversion of Control. It almost has no meaning because it's like think of it like this, I create a Win Forms application, I drop a user control on that Win Forms app. Am I responsible for calling that control, or does the framework do it? So that's the idea of Inversion of Control, but the difference I think between using things like DI Containers and such to achieve Inversion of Control versus when it's like baked in to the.net framework is you're solving problems that traditionally you would solve through imperative coding. Like with Win Forms, I never had to manually create the control and add it. It always did it for me, but it's taking these things like this Inversion of Control containers and saying, okay, well now, instead of me imperatively calling all my code, I can actually wire up something else to do it for me, and by doing that that means that I can replace in a test environment, for example, Page 2 of 8
which things it wires up because anytime I write imperative code that says A = new B, well, unless I happen to be in like a dynamic language where I actually can at the language level replace that, I'm always going to get a B. But if I go to an Inversion Control container and saying resolve B, what I get might not be a B at all. I mean, I may go ask for an IB which is an interface. Yeah. And then I don't know or care actually what the concrete implementation is because when I'm doing IoC I'm just working through contracts, and that is a parallel like in MEF when you work with these extensions, we call them parts. It's a very simple concept in MEF that you build up your app, your app consists of a set of parts, those parts have exports which are things they give off and imports things they take in. We use this notion of contract there as well because if I'm going to import something, how do I know what the thing that I'm going to import looks like or what it's called. We call that thing a contract that defines what that is. Okay. So is MEF an IoC Container or not? What I would say to that is that when you say that question it's a very overloaded question. What I take that to mean, and I used to work in the Patterns and Practices team where we build Unity, that I would say yes, that is an IoC. So Unity, let me familiarize people. Unity may not be familiar to them. Sure. Unity is an IoC Container. Unity is an IoC Container and it was built to be an IoC Container, but again, when you say what that does mean, what I take that to mean when somebody says to me is MEF an IoC Container, it's I solve a set of problems using this thing I call an IoC Container. Can MEF solve those problems? My IoC Container was built to solve those problems in a very specific way. What I would say about MEF is MEF was really harvested. We did not look at what other people were doing with IoC Containers and say, hey, let's go build one of those. What we did is we had a set of problems around this space of getting these apps to be extensible and we basically said, hey, this principle of using Inversion of Control is a great way to solve that. So what I would say is that if you look around a scenario by scenario basis, there are some things we do that overlap with what IoC Containers do and how we do it may be very different but it's really about the end goal of what we build it for. Okay. So if someone's out there already and they have tried a number of IoC Containers and maybe they're trying Auto-Fact and they've looked to Unity and they've played with the StructureMap, would they also want to put MEF in their app and why, or wouldn't they just implement MEF-like structures in their own existing container that makes them happy? So one of the things that's interesting about that is because MEF does a very specific set of things, we actually think that there's a world we both live together and we've been prototyping on that. What that means is it's not a true container solution. What MEF really has is an abstract way of defining in general components and their dependencies, and so you can imagine taking an IoC Container and MEF enabling it. That means that that IoC Container still works the way that it works, but what it also does is it now understands MEF's component language so that it can automatically also take in things from MEF. So the other day, Nick Blumhardt, who is the author of Auto-Fact, and we've got some really passionate guys from the IoC space on the MEF team, Nick Blumhardt authored Auto- Fact, he and I were with Chris Tavares... Who wrote Unity. Who wrote Unity, and we were doing some spiking around integration between the two which is where I have an IoC Container and I'm using MEF for that third party extensibility. The way I basically position it though, the difference between the two, is that IoC Containers are really about managing unknown set of things in different environments, like I want a logger in my disk environment, I want a mock logger in my test environment. So MEF is really about managing an unknown set of things and what that boils down to is that in an IoC Container I tend to do either a convention-based or a registration, specific registration mechanism, to say here's what logger means, here's what this means, here's what that means. MEF uses the code and a discovery mechanism and annotations on the code, which are attributes, where whatever shows up in the system, that's what's there. So again, taking it to a higher level, it's about you use MEF to really manage a set of unknown things, you use IoC Containers to manage a set of known things. That last sentence is about the clearest explanation leverage so far and I wonder why is it that it's so confusing. I mean, it seems a lot of people are confused. Sure. So then, I think that the next kind of question that would come up would be why isn't there an IoC Container, or what I get people call Page 3 of 8
a microkernel, baked into the.net Framework and is that holding aspects of design on the framework path? Sure. Because the thing I get confused about is that people who seem to know what they're talking about always say here is an IoC Container of 14 lines. Why isn't Microsoft just shove that in System.DLL and go on with their lives. Sure. I think sometimes there too much focus. I personally believe, and I'm a big fan of IoC Containers, IoC Containers are a means to an end. The end is really about decoupling. Decoupling systems is really kind of the primary goal of using IoC. So I think we do get hauled up on the idea of I must have a thing called an IoC Container. Having decoupling in the framework and having mechanisms to do that, MEF is certainly, again if you go to a higher level, MEF is certainly a mechanism for decoupling different components. MEF has two aspects too, and I don't want to get into this too much because it will confuse people. There's a layer in MEF that has to do with exactly how things manifest in this attribute and model, and there's a layer of MEF that has absolutely nothing to do with that. So when you talk about the microkernel, almost like a microcon kernel. That functionality is something that we're going to be looking a bit deeper and deeper in the framework. So I would say that we certainly hope that MEF is that technology. We've done a lot of work in the last year to evolve it to be that technology that could provide that general decoupling in the platform going forward. Do we need something else? Well, that remains to be seen. I mean, Unity certainly is very much like an IoC, like Castle Windsor, and these other things. Right. It is certainly something though that is important to the.net framework and we want to support these more decoupled-type designs both for applications built on top of the framework and even within the framework components itself. Hi, this is Scott coming at you from another place in time. Are you looking for an Object Relational Mapping Tool for mission critical projects using LINQ and.net? I want to share with you Genome, it's specifically designed for developing.net Enterprise Applications. Genome is a mature LINQ integrated ORM tool. It has been employed in numerous large scale projects in the last six years. Genome was created for the.net platform as oppose to being a port from Java and it's derived from platform innovations since.net 1.0. Genome has LINQ since its CTP release in May of 2006. It offers several unique features such as encapsulation and reuse of LINQ Query and Expressions. You can really and fully harness the power of LINQ while benefiting from your database platform's unique features, compose complex LINQ Query, decompose the Query logic in your domain model. LINQ supports all the major database platforms you find in enterprise environments like SQL Server and also Oracle and IBM DB2. You can find out more about how Genome integrates tightly with Visual Studio and what tools Genome offers to reduce irrelevant time at tinyurl.com/trygenome, G-E-N-O-M-E, where you can also download a free and fully functional trial version. I hope you enjoy it. There are two interesting things about MEF that have struck me in a couple, four, five days that I have been hanging out here in the campus. The first one is that it keeps coming up in conversations and I don't mean that in a light complimentary or flattery sense, I'm just telling you the truth like I go into a group and I like just interviewed one of the guys that worked on the WPF Editor for Dev 10. He goes, oh yeah, we use MEF in there. People say, oh yeah, we use MEF for that, oh yeah, we're using it. So you successfully sold this thing internally. Honestly, the reason it evolved was because of that. There were about five or six different efforts within the company that were trying to solve this problem of decoupling and also the extensibility problem. If you look at it in the.net framework, we haven't really had a good story around general extensibility. We've had the managed add-in framework but that was really built more around solving a problem of isolation and security and versioning, but it also... And it was hard. It was hard, it imposes a lot. I've actually been looking at MEF, MEF integration, now so I'm dealing with that right now, but it didn't have those compositional aspects and yes, it impose a lot on the type of types, you know, the types that it dealt with making sure they're more suitable or that they can pass or cross the wire because it uses remoting app domains. MEF was built to be very simple but we don't have, other than the reflection API, a simple way to say I've got an app, I want to build the set of extensions for it, I want it to work. In a lot of my talks on MEF, I've talked about how there a lot of these very specific APIs that work with a very specific technology like ASP.NET has the provider model. Well, that's great, but what if I'm not on a web server and Office has a great set of extensibility APIs. But what if I'm not in Office, do I want to bind my clients so they have to develop in Office. So it was a common need coming from multiple different angles that made us say, you know what, we need to solve this problem and we've worked with a lot of internal partners to solve it and so it's like yeah, this is the answer we've been waiting for. So they've jumped on the board and it's been groups like the Connected Page 4 of 8
Systems Division with the Oslo Editor for example which is actually using Python which exposes another aspect of MEF which is that it's not bound to types. Most IoC Containers, all the ones I know, are really very heavily bound on the thing that comes in is a type. MEF can actually work with dynamic languages and other kinds of things. I guess that's a long answer to a short question. job. That wasn't very long. Good It is that it's solving a very common problem that we haven't had a good answer for in the framework... Well, it sounds like, at least with Microsoft, it solved exactly the right problem because it's an idea virus and it's spreading appropriately. So the second thing that I think is interesting about MEF that I've noticed internally is that no one seems to care that is Open Source and you're developing it in a very open way. It's an MSPL, right. MSPL, yes. It was another license at one point but we're MSPL now. that a little? Do you want to speak about Sure. The interesting thing about that whole thing was like when I join the MEF thing, I was really hot on we need to get this out there, and there were a bunch of reasons why I wanted to get out to CodePlex. You know, we have been accused as a company of developing things kind of in a cave sometimes like they were the only ones, and I won't mention examples, that have solved this problem and I knew, especially coming from PMP and I have been very involved with like the ALT.NET community and stuff like that, that you know, this problem has been solved before. We maybe addressing it in a different way but I wanted to make sure that the people that were solving that problem knew that, hey, we're not trying to knock you out of the box, we're looking to solve a very specific thing, but also that we allow that mind share to pour in and say, look, we've been in this space, why don't you do this this way. One great example of what I benefited with MEF is the idea of Constructor Injection. We initially were only supporting Property Injection which is what most of our partners were using and there was feedback, very loud and clear on Chris' blog, hey, you guys should have Constructor Injection. We added it only because the community said we really want this. So I wanted to get it out to CodePlex. Coming from PMP, I saw a real value in having that visibility out there, and in doing it we had some parts of MEF that came from other places and so we had some issues around, you know, can we put all the code out there and because of that we ended up going out with a more restrictive license initially, but the goal was all good. We wanted to get the code out there and be visible and I got slammed pretty hard by that. It was Miguel de Icaza actually that slammed us because he said, you know... Founder of the Mono. Creator of the Mono. Because he said, well, now we can't use MEF on Mono when we're not looking to write MEF. But of course, in this particular instance, it was an innocent, an ignorant mistake and you fix it quickly and it works. So now MSPL and that means it's all of it that... But some people are still brooding, like I still see posts that say, ha, ha, ha, don't use MEF because it's poison and it's LPL, or people say that I was trying some kind of marketing thing of watering down Open Source. I'm a big fan. I think they give you too much credit. No, but it's MSPL, so what does that mean to us? I mean, what does that mean to our listeners who are using MEF and maybe they put it in their enterprise? So that means that you're free to take the code, you can modify it. It gives the Mono guys, for example Miguel who already got MEF to compile on Mono, in doing that he had to make a slight change because there was a read, write lock, there was some kind of lock that we were using internally that was not supported on Mono 2.0 yet, which they were planning to support, but the point was that, and he didn't actually do this, but he could make that change and put that out there and people can use it if they want to just like they use other Open Source. Now, when we say it s Open Source, I mean we're still owning the code. source opened. So you're not taking Commits. We're not taking Commits. So it's not Open Source, it's Well, but because it s MSPL, if somebody wanted to, they could take the entire MEF codebase and copy it into the MEF contrib and the community could start branching it if they wanted to. We wouldn't pull that back though probably. What kinds of things have you seen people do? Has anyone made any major changes to MEF? The biggest one right now if I call out is a guy who has Twitter, he is the Code Page 5 of 8
Junkie. His name is Andres. I forgot his last name now for some reason. He has built a program. So MEF has these programming models and on one of them we have this attributed model. I'm subscribing that, and because we've decoupled it in the way we have, you can write your own entirely new model like for Python it doesn't support attributes. Well, he has gone and built a model that's completely configuration driven because he wants to use MEF. MEF has a bunch of capabilities beyond just the traditional of I get a type of thing. Like I can add metadata, I can Lazy instantiate and Lazy Load and this is all because we're trying to support these scenarios like Visual Studio and such like that. Well, so he wants to leverage that within his app but he wants to have control over the set of finite things that are getting created and he doesn't want to have to put attributes on there. He wants to be pure POCO. So he built his own model. objects? POCO meaning plain old CLR Plain, old CLR objects. He build his own model which is about to go live in MEF contrib. which will allow customers to go and configure MEF completely through configuration. All right. So I still feel a little bit like we've been talking in abstracts and we may have actually lost people so if there is anyone who is still actually listening at this point, why don't we talk about what we did with Baby Smash demo. I need to get that code out. It was a demo that we did at PDC and if you go and Google around for TL 49, you'll see my talk at PDC and I have a little MEF bit in the beginning. Do you remember your code for your talk at PDC? TL 33, I believe. TL 33 and you'll see Glenn's very good talk on MEF. So one of the things that we did and it took, I think, maybe four hours because I just spend a little quick prototype of Baby Smash. Baby Smash is my little toddler game that lets kids slap on the keyboard and put shapes on the screen, and the idea was that Jason Olson, who is a Microsoft employee and a MEF fan, and I would basically swap out the shapes and everything was hard coded. I was newing up the shapes, I had a rudimentary shape factory that made random shapes and he wanted to be able to change those to an entirely different shape. So kind of walk me through the process here. So as we mentioned before, MEF has a concept of parts, imports and exports. What you guys did is you created a thing called Smash Packs. So if you start off and say, okay, I've got an app, that app wants to be able to get Smash Packs. So immediately that's going to throw a MEF perspective, it's going to say, okay, somebody in the app is going to be importing Smash Packs. I think in your case, you did an ismash Pack provider or something... We ended up doing just at the shape level and the goal is to go and MEF-afy everything. Sure. We're going to do audio. For the gentlemen, we did just these shapes so basically shape would come from somewhere else. We needed shapes. That was, I think, our import. Yup. So the way MEF works is really easy. You define a contract like in interface and you basically say, okay, I'm going to have a collection property which is a collection of providers and then I'm going to put an import attribute on that. Then what I'm going to have is a set of assemblies that are going to reference that shared contract that are going to say, okay, here's my available Smash Packs or providers or whatever we come up with. Then the thing that brings the glue together is we create a thing called a catalogue. Right. I remember that we created a catalogue and it was important to us that for the demo that we take a DLL, and while the app was still running we drop the DLL into the bin folder. I hate to tell you this but we're actually going to pull that functionality... Oh, you're killing me. Well, the reason is it's great demo where practically... Well, it's dangerous practically. It doesn't work out very well. It has lots of problems and the reason is that functionality depends on the underlying file modification watcher, you know, the file system watcher API which what it does is as soon as the file shows up, it says, oh, it's there, I'll grab it. The problem with that is let's say that you drop an assembly that has a dependency on another assembly. Well now, and almost every time I've demoed this feature, I think you've been the only person I've seen who has successfully demoed it without it failing once and I saw you did the batch file trick, but anyway, yeah, you create a thing called the directory part catalogue and that directory -- we'll actually we're going to call it directory catalogue just to simplify it, you point it at a folder, each streams were assemblies. Now, how is it finding those contracts that you specify? Well, it's not just looking for the type and saying, oh, you use an I thing, I'll just pick it up. We use a declarative language which is Page 6 of 8
essentially that if I want something, I put an import attribute, and if I have something available, I put an export attribute. So in each of those assemblies that represent your Smash Packs, you would have some kind of like my family Smash Pack provider that implements ismash Pack provider and then on top of it it would have an export attribute and that export attribute says ismash Pack provider. The beauty of MEF is that let's say I did that and now it works and suddenly you say, you know what, I want to open up my Smash Pack provider so they can get some additional information back from the app. It's not just the host loads it and it does its thing. Well, now that Smash Pack provider can start adding its own import attributes so pull back and when it's pulling back it doesn't know where it s coming from. It might be coming from an assembly that's sitting right next door that has an extension, or it might be coming from the app. It's really very, very simple. Is that a solution to what might ordinarily be a circular reference or maybe a very...? Well, kind of. I mean, it's not... I mean, not from an assembly perspective. I mean all perspective. Well, because you have a contract, you've removed the circular reference in the sense that, yeah, I don't have a dependency on this guy and he doesn't then have a dependency on me. But the idea is with MEF you've really broken that whole notion of who the provider of the thing is. Right, ignorance is bliss. It's completely bliss. It's like I call a web service. I just call a method and I know that it's going to get more I don't care who is on the other side, I just know that they satisfy the contract. It's the same idea of MEF. That actually means though that MEF apps work well in terms of being designed from a testability aspect. Because I don't know who I'm asking for, that means if it is some mock thing, I don't care. Right. So ultimately, your application is they care about what they care about. They care about what they care about. They don't care about how we get it. actually is. They don't care about what it They don't care about who, how, or where. They care about what. Which actually gets to the SOLID Principles. I hope you saw the show with Uncle Bob. I think about things like single responsibilities. Sure. Dependency Inversion. More and more I'm looking at my objects and I'm saying, "He knows way too much about what's going on." And he knew it a long time ago. And he knew it early on. He knew it with the constructor and just in order for some property to have a tiny little bit of knowledge and suddenly just little bits of perversion have sprinkled its way into my design, so then something like MEF would just kind of remove that, let somebody else be the one that knows too much. Exactly, but I don't want to make it like you should use MEF for every single type, every single thing. I mean it's design to do a very specific thing, use it for what it was built for and when we've had these conversations about kind of integrating with like IoC Containers, like Unity, or Auto-Fact which Nick was the first one who prototype that, it's been under the same context. I'm going to use MEF for what it's good for, I'm going to use these other things for what they're good for. Cool. So where do people get more information on MEF, and more importantly where can they see actual sample code that's going to help it really gel for them. Sure. So if you go to our CodePlex site, codeplex.com/mef, MEF is available with full source. We're committed. Although we actually, just for customers to know, we will be shipping in the.net framework 4.0, but we're committed to keep the source out there and we're going to keep it out there on 3.5 even though we're planning to take some 4.0 specific dependencies and we're doing that for the community so they have access to the code, etc. There are samples there, there is a Wiki. We've not really gone as far with the Wiki as we should, you can ping us and say please add additional and hopefully we'll get off our butts and get it done, but there is enough out there to get the basics like what is an export, what is an import, and you'll find some samples there as well, plus there is a bunch of bloggers that have been blogging about MEF and we have some links to some of those different posts that are out there and I suspect there will be one on your blog very soon. what. Exactly. It focuses on the Yeah, I think it s time to get the Smash Packs finished up. Cool. Well, thanks so much, Glenn Block, project manager on MEF, for Page 7 of 8
talking with me today. This has been another episode of Hanselminutes and I'll see you again next week. Page 8 of 8