Click here to Skip to main content
15,667,983 members
Articles / Desktop Programming / WTL
Technical Blog
Posted 19 Aug 2010

Tagged as


11 bookmarked

MEF Architecture in Detail

Rate me:
Please Sign up or sign in to vote.
4.40/5 (4 votes)
19 Aug 2010CPOL6 min read
Let us take a deep dive into the MEF architecture.

Let us take a deep dive into the MEF architecture. We can write sample applications by just going through the MEF knowledge base on the web. But to design an enterprise level of applications, it requires more in depth knowledge of what MEF is trying to solve, what MEF is, where it can be applied and how MEF is architected and designed to solve the existing issues in the software world.

Well, I did not invent MEF, so some of the information present in the blog is from the web. According to me, MEF is an Extensible Framework for composing applications from a set of loosely-coupled parts discovered and evolving at run-time. It is basically a composition framework.

What Does MEF Solve?

  • Managed Extensibility Framework is to solve the old problem of maintaining a piece of statically compiled software that continuously changes and evolves during its lifetime. MEF provides a solution for building reusable applications from reusable components which can be dynamically discovered at runtime by the application itself.
  • MEF offers a solution for extending the application architecture as it evolves.
  • With MEF, we can add additional metadata to the piece of code we write thus facilitating rich querying and filtering.
  • MEF is not a Dependency Injection container. DI is only a part of the solution that MEF tries to bring into the scene.

Why MEF?

From the efforts point of view, we approximately spend 20% to develop the original application and about 80% to maintain it during the years. If we could turn at least a part of that painful 80% to something more useful—for example inventing into creating better business value or user experience, etc.— both the customers and the company would be happier. That is where MEF comes into the picture from business perspective.

MEF Architecture


Figure: Different layers in the Managed Extensions Framework


The namespaces of the different containers are as follows:

image <

Figure: Class Hierarchy of the Containers

CompositionContainer – The composition container, “CompositionContainer”, is present in the namespace System.ComponentModel.Composition.Hosting. The container contains a collection of parts that were either created by the container or added to it by the application. Parts contain a collection of exports (services it offers including itself) and imports (services it consumes) with imports being optional or required. Once a Part has been added to the container, it can be composed. During composition, the container satisfies all of a Part’s imports based on available exports. If a required import cannot be satisfied, then composition will fail.

A CompositionContainer object serves two major purposes in an application. First, it keeps track of which parts are available for composition and what their dependencies are, and serves as the context for any given composition. Second, it provides the methods by which the application can initiate composition, get instances of composed parts, or fill the dependencies of a composable part. Parts can be made available to the container either directly or through the Catalog property. All the parts discoverable in this ComposablePartCatalog are available to the container to fulfill imports, along with any parts added directly.

ComposablePartExportProvider – This provider is responsible for retrieving exports from part catalogs. It contains a collection of parts. However the parts in its collection are created from the PartDefinitions it queries rather than being explicitly added to it. Also, it contains a CompositionEngine for satisfying the imports on its parts.

CatalogExportProvider – Retrieves exports from a catalog.

AggregatingExportProvider – This provider is a composite of other providers that it contains, and is used for providing a topology of EPs. Whenever this provider is queried, it will query the providers within. The internal query behavior varies depending on the cardinality of the ImportDefinition that is passed in. It queries its children. The container uses an AggregatingEP internally which contains a ComposablepartEP, a CatalogEP and/or a custom provider if one was passed in during its construction. AggregatingEPs can also be nested without a problem.


Figure: The chained set of ExportProvider instances in use by a container instance, so they can query each other for exports when satisfying dependencies


Namespace: System.ComponentModel.Composition.Primitives


Figure: Overall view of the primitive classes

The primitives represent component instances capable of being wired together, component definitions with rich meta data and common query interfaces for component catalogs. The role of the Primitives is to specify components that can be wired together to create useful software.

ComposablePart is an instance of live executing software component. The ComposablePart specifies its dependencies and capabilities through import and export respectively. The ComposablePart describes its own imports though ImportDefinition and exports through ExportDefinition.

ExportDefinition is a structure comprising of a string-based ContractName and a dictionary of additional information called metadata. Each ExportDefnition attached to a composablepart describes the individual capability (service offered) of the part. Metadata is useful to perform some additional querying or filtering on the part.

ImportDefinition It describes the dependency of the part. IsRecomposable is useful to indicate whether the import definition can be satisfied multiple times. IsPrerequisite indicates whether the import definition must be satisfied before a part can start producing exported objects.

ComposablePartDefinition describes the kinds of ComposablePart that can be created in a given system. It defines an abstract base class for composable part definitions, which describes and enables the creation of ComposablePart objects. CreatePart method creates a new instance of a part that the ComposablePartDefinition describes.

ComposablePartCatalog The ComposablePartDefinitions are grouped together into ComposablePartCatalogs. Using IQueryable<ComposablePartDefinition> Parts property, we can get the part definitions that are contained in the catalog.

Attributed Programming Model

Namespace: System.ComponentModel.Composition.Hosting


Figure: Class Hierarchy of different types of Catalogs

We can directly use the above mentioned primitives in our applications to perform composition and other tasks, but it is a very laborious task. So there should be a way for the developers to interact with the primitives using some programming model. APM optimizes the task of mapping a class or interface and members to a ComposablePartDefinition with exports and imports.

The primary interfaces to the Attributed Programming Model are:

  • TypeCatalog: Catalog containing discovered types
  • AssemblyCatalog: Catalog containing parts that are discovered in an assembly
  • DirectoryCatalog: Catalog containing parts that are discovered in the directory
  • AggregareCatalog: It holds the collection of Catalogs

Well, that’s the high level view of the MEF internal structure. As mentioned earlier, the developer can use this framework using any programming model. In .NET 4.0, Microsoft provided the Attributed Programming Model to the developers to code the applications using MEF. Primitives are an abstraction layer, so tomorrow you can move from APM to any other model easily.

Watch out for my upcoming blogs for some hands on coding…

Filed under: CodeProject, MEF


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
CEO Astrani Technology Solutions
United States United States
Kishore Babu Gaddam is a Senior Technology Consultant, Technology Evangelist turned Technology Entrepreneur and a regular speaker at national conferences, regional code camps and local user groups with over 14 years of experience in software product development. His experience includes building & managing award-winning software development teams, managing customer relationships, marketing and launching new software products & services. Kishore launched his technology career almost 15 years ago with a Robotics software development startup and has served in multiple roles since including developer, innovation leader, consultant, technology executive and business owner.

A technology specialist in C++, C#, XAML and Azure, he successfully published two applications to Windows store and

Kishore is the author of the popular Microsoft Technologies blog at and his work on Portable Class Library project in Visual Studio 2012– .NET 4.5 was featured on Channel 9 at Kishore enjoys helping people understand technical concepts that may initially seem complex and perform lot of Research & Development on emerging technologies to help solve some of the toughest customer issues. Kishore spends a lot of time teaching and mentoring developers to learn new technologies and to be better developers. He is a speaker at various code camps around Washington DC area, mainly at Microsoft Technology Center for NOVA code camp (, CMAP Code Camp Fall 2012 (, etc. The majority of his software development experience has centered on Microsoft technologies including MFC, COM, COM+, WCF, WPF, winRT, HTML5, RestAPI and SQL Server. You can follow Kishore on Twitter at He can be reached on email at

Comments and Discussions

Questionnice copy and paste article rofl Pin
Member 1093378810-Jul-14 3:22
Member 1093378810-Jul-14 3:22 
GeneralMy vote of 3 Pin
mheskol7-Oct-10 11:16
mheskol7-Oct-10 11:16 
GeneralCOM Component Categories Pin
Nathan Going6-Sep-10 18:07
Nathan Going6-Sep-10 18:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.