Managed Extensibility Framework. Working with the Managed Extensibility Framework. Thursday, November 12, 2009 Working with the Managed Extensibility Framework (TOC) This post is simply a table of contents for posts that I'm creating to help others learn about the Managed Extensibility Framework (MEF). As new posts get published, I'll be updating the links to this page. In addition, as I work more with MEF, I'll be adding more entries to this series to hopefully cover a wide range of scenarios while using such.
Posted by James Eggers at 9:50 PM Labels: MEF 4 comments: Colin EberhardtSeptember 30, 2011 at 3:24 AMHi, Just want to say thanks for this blog series, probably one of the best MEF introductions I have found. Load more... Newer PostOlder PostHome. An Introduction to MEF. Have you ever attempted to write an extensible application? You know the kind. The applications where your boss wants to be able to add stuff to it without rewriting the entire application and with minimum costs. Or the type of application you want to release out to the community and provide a way for them to add their own customizations to it. We have all seen these types of applications; however, if you have ever attempted to write such, it is usually a pain to developer the core application or a pain to develop the extensions or plug-ins.
Thankfully the Managed Extensibility Framework (MEF) is available to those of us that have extensibility needs inside of the application. Origins and Model MEF was developed from an initiative within Microsoft in order to simply the creation of building extensible applications. How Does MEF Differ From IoC Containers? You use MEF to manage a set of unknown things. Writing the Hello World Program.cs 1: using System; 4: using System.Reflection; 16: p.Run(); A Deeper Look at MEF's Imports and Exports. In the last article, I provided a very brief introduction to MEF and showed a very simple console application. In this section, we'll be looking at the issues associated with that sample and diving into the various aspects of declaring your Imports and Exports to overcome those issues. The code and samples in this post will still be within a single assembly. Because of this, I'll may use the word Dependencies and Parts interchangeably.
The Issues with the Last Example's Simplicity At the end of the last post, we looked at a simple console application that used MEF to wire our dependencies within the same assembly together. Below is the code for our Program.cs and SimpleMessage.cs classes again. Program.cs 1: using System; 2: using System.ComponentModel.Composition; 3: using System.ComponentModel.Composition.Hosting; 4: using System.Reflection; 6: namespace MEFExample2 8: class Program 10: [Import()] 11: string Message { get; set; } 13: static void Main(string[] args) 15: Program p = new Program(); LINQing to MEF Imports. At the end of the last post, we looked at how we can explicitly manage our imports and exports using a combination of text-based labels and type declarations.
In addition, we began to look at the ImportMany() attribute for importing more than one value in our extensible application. Along with the ImportMany(), we looked at looping through the simple example to display the property of each imported type. This approach isn't bad if the number of imported types are small; however, looping really wouldn't work well if your application loaded a very large amount of applications.
In a way, it's a great problem to have if your application has a large community based plug-in repository (i.e. Wordpress or Firefox). There may come a time when we may need to find a specific plug-in without looping through everything. In order to determine this, there's a couple different ways to handling this. Giving Our Messages a New Property 1: using System.ComponentModel.Composition; 3: namespace MEFExample3. Playing Nice with Other Assemblies using MEF Catalogs. Looking over the previous three posts, we have been working within a single assembly for managing our extensibility parts. While this works well if we want to use MEF more as an IoC container, it really limits the extensibility of our application.
In the single assembly model that we've been using, every update would require a new build of the application. To overcome this limitation, we'll create a new example project that builds on what we've covered and branch it out into multiple assemblies. Building a Console's Help Information In the new example, we'll be creating a new console application whose sole purpose is to output help documentation on various fake commands. Defining Our Project Structure Given the scenario that we are going to be working on, there are a couple of different ways we can structure our solution. For the sake of this example, let's start a new Windows Console application project named MEFExample4. Creating Our Extensibility Contract 1: namespace MEFExample4.Core. Looking Around at Circular References in MEF. In the last post of this series, we created a new example code base used to display help text for various "commands". This was a simple code base that extended previous examples by using external assemblies and different catalogs to identify all of the parts that can be imported and mapped.
This example covers a lot of scenarios when applied beyond the means of console-based text output since each imported "command" could literally be a functional piece of code by itself. However, what happens when the imports require something from our main application? When one object has a dependency with another object of another type; only for the dependent have a dependency towards the initial type; this is called a circular dependency. A Closer Look at Circular Dependencies in General To reiterate what was said a moment ago, a circular dependency is where two objects depend on each other for different things in somewhat of a symbiotic relationship. 1: class ConfigurationManager : IConfig Summary:
Managing Composition Through Lazy Loading Parts. So far in this post series, we've been looking at various aspects of working with MEF in the context of a single level of composition. One interesting thing about MEF is that its composition is recursive based on the assemblies and types identified in the catalogs within the container. What this means is that if one of our parts also has imports defined for parts of its own, the composition container will continue loading parts for the initial type as well as all parts loaded until no more parts are found or all imports are fulfilled. This is a really nice feature since it will ensure everything is ready for you once compose the initial type; however, this eager loading can greatly cause a performance issue if the parts are not constructed properly.
In this post on our ongoing series about MEF, we'll look into the concept of parts of parts and how to apply lazy loading principles towards them. Putting the Pieces of Pieces Together IHelp.cs 1: public interface IHelp ExampleCommand.cs. Managed Extensibility Framework: Part 1. Download source code - 5.64 KB Introduction This article series is intended to provide an introduction to Microsoft's Managed Extensibility Framework. Before showing the code snippets using the MEF framework, I would like to run through a case scenario where the need for MEF can be felt. I feel this will help in identifying the situations where MEF can be used effectively. Background Building reusable code into libraries and using them in applications is normal. In legacy Win32 applications, if a library is linked to an application, a linker is used to add a reference to that library in the PE header.
Resolve all dependenciesload them into memorymap them to respective pointersthen start the main routine But in .NET world, with CLR and JIT compilation in the middle, things are slightly different. Here is how it is defined officially: "The Managed Extensibility Framework (MEF) is a new library in .NET that enables greater reuse of applications and components. Case Scenarios ntdll! Ntdll! 0:003> ! Managed Extensibility Framework: Part 2. Download source code - 166 KB Introduction This is in continuation with my previous post in this series. Part 1 covered the problem MEF tried to solve. In this part, we will see how MEF solves the problem scenario described in Part 1. The example covers the scenario where information flows from application to an extension as well as from an extension to the application. Background At the end of Part 1, I showed a working code that could be used as a managed extension. Example The code for this example is available in three solutions.
Console application which can consume an extensible part Here, we build a console application which can consume an extensible part. Create a console application and call it "meflab1".Add a reference to System.ComponentModel.Composition.dll (from the bin directory of the downloaded zip file).Replace the code in Program.cs with the following snippet: Add a class by name SimpleGreeting and replace the code in SimpleGreeting.cs with the following snippet: Build it! Building an Extensible Application with MEF, WPF, and MVVM. Introduction This article explains how to write a WPF application using the Model-View-ViewModel pattern and make it extensible so you (or third parties) can extend it with additional features. Background Earlier this year, I set out to write an IDE-like application for the home automation space. I had three requirements: It had to be extensible by third parties It had to be WPF using the Model-View-ViewModel pattern (mostly because I wanted to learn it) I was going to release it under the GPL, so all the code had to be GPL compatible When I found the SharpDevelop Core, I was pretty excited.
Tearing SharpDevelop down to the basics was still an option, but I wanted to be thorough. Then, I stumbled on Mono.Addins and the Managed Extensibility Framework (MEF), at roughly the same time. MEF is going to be part of .NET 4.0, and when possible, I prefer to build on existing system libraries as much as possible. SoapBox Core Boring? Building an Application on SoapBox Core Documents and Pads. Hosting MEF within application and libraries. As you start to work with MEF one of the fundamental decisions you have to make is how MEF will be hosted. There are several factors which will impact your decision including whether you are building on Silverlight or the Desktop and whether you are building an application or a library.
The first concern you hit around MEF is how and where composition starts. MEF parts at the end of the day are simply classes (in our attributed model). Simply adding an Export attribute to a class does not cause it to get composed as something has to start the composition. There are several approaches to composition in MEF. The first approach is to pass an existing instance to MEF and ask it to compose it. [Import] public Window MainWindow { get; set; } void App_Startup(object sender, StartupEventArgs e) var catalog = new AssemblyCatalog(typeof(App).Assembly); var container = new CompositionContainer(catalog); container.ComposeParts(this); base.MainWindow = Window; MainWindow.Show(); if (container == null) Update: Creating An Application With Full Plug-in Support. In this article, you'll learn how to create an application with full plug-in support. Introduction It's been a number of months since I released the first version of my Utility Runner application.
Utility Runner makes it possible to run system utilities with as little overhead as possible: Instead of lots of tray icons, numerous EXE's, and the associated memory and startup time overhead, this application manages multiple utilities from one place. To open this solution, you'll need Visual Studio 2008 Express Edition (Visual C# or Visual Basic), at least. If you don't have it yet, you should get it! Working with MEF Little has changed functionally from the last version of the application, beyond some refactoring that's taken place since the new version of MEF was released. Managing Addins My big challenge was figuring out how to implement an addin manager to support multiple utility addins, like in Firefox. There are a number of ways to achieve these goals. Loading Addins Adding an addin.