Defining Composable Parts and Contracts

Composable Parts

A Composable Part is a composable unit within MEF. Composable Parts export services that other Composable Parts need, and import services from other Composable Parts. In the MEF programming model, Composable Parts are attributed with the System.ComponentModel.Composition.Import and [System.ComponentModel.Composition.Export] attribute in order to declare their exports and imports. A Composable Part should contain at least one export. Composable Parts are either added to the container explicity or created through the use of catalogs. The default catalogs that MEF ship with identify Composable Parts through the presence of an export attribute.


Composable Parts do not directly depend on one another, instead they depend on a contract, which is a string identifier. Every export has a contract, and every import declares the contract it needs. The container uses the contract information to match up imports to exports. If no contract is specified, MEF will implicitly use the fully qualified name of the type as the contract. If a type is passed, it will also use the fully qualified name.

Note: By default a type should be passed for a contract, and not a string. Although contracts can be an arbitrary string this can lead to ambiguity. For example "Sender" might overlap with another implementation of "Sender" in a different library. For this reason if you do need to specify a string constract, it is recommend that contract names should be qualified with a namespace that includes the Company Name for example "Contoso.Exports.Sender".

In the code snippet below, all export contracts are equivalent.

namespace MEFSample 
  public class Exporter {...}

  public class Exporter1 {...}

  public class Exporter2 {...}
Namespace MEFSample
    Public Class Exporter
    End Class
    Public Class Exporter1
    End Class
    Public Class Exporter2
    End Class
End Namespace

Interface / Abstract contracts

A common pattern is for a Composable Part to export an interface or an abstract type contract rather than a concrete type. This allows the importer to be completely decoupled from the specific implementation of the export it is importing resulting in a separation of concerns. For example below you can see there are two sender implementations that both export IMessageSender. The Notifier class imports a collection of IMessageSender which it invokes in its Send() method. New message senders can now easily be added to the system.

  public class EmailSender : IMessageSender {

  public class TCPSender : IMessageSender {

  public class Notifier {
    public IEnumerable<IMessageSender> Senders {get; set;}
    public void Notify(string message) {
      foreach(IMessageSender sender in Senders) 

Public Class EmailSender
    Implements IMessageSender
End Class

Public Class TCPSender
    Implements IMessageSender
End Class

Public Class Notifier
    Public Property Senders() As IEnumerable(Of IMessageSender) 
    Public Sub Notify(ByVal message As String) 
        For Each sender As IMessageSender In Senders
        Next sender
    End Sub
End Class

Contract Assemblies

A common pattern when building extensible applications with MEF is to deploy a contract assembly. A contract assembly is simply an assembly which contains contract types that extenders can use for extending your app. Commonly these will be interfaces, but they may be abstract classes. Additonally contract assemblies will likely contain metadata view interfaces that importers will use, as well as any custom MEF export attributes.
Note: You must specify the specific interface type (IMessageSender) being exported otherwise the type (EmailSender) itself will be exported.

Last edited Aug 9, 2010 at 5:09 PM by haveriss, version 34


ajay555 Apr 22, 2010 at 4:46 AM 
Migrated my blog to WordPress. You can find the MEF example on below mentioned URL:
Part I:
Part II:

Happy Blogging !!!

ajay555 Apr 10, 2010 at 11:27 AM 
One of the comment posted in my earlier example of MEF was what if we have two implementations of the same interface and we need to decide at run time which implementation to use. I have posted another blog which gives the example of usage of ExportMetadata for handing this scenario.

gblock Mar 27, 2010 at 10:16 PM 
@dolan COM requires registration and hangs stuff around in the registry. MEF however has zero registration and automatically discovers implementations. It's also far easier to use ;-)

dolan Mar 23, 2010 at 5:11 PM 
This all appears to be like COM done in all managed code.

ArielBH Aug 30, 2009 at 6:54 PM 
[Export(typeof(IMessageSender)] => missing ')'
public class TCPSender() : IMessageSender => unnecessary "()"

nblumhardt Jul 30, 2009 at 11:00 PM 
Thanks @Bidou for the correction.

Bidou Jul 28, 2009 at 9:08 AM 
In the Notifier class, the [Import] attribute must be replaced with [ImportMany(typeof(IMessageSender))], otherwise an error is raised at runtime...

Seagirta Jan 28, 2009 at 10:11 PM 
You can use ExportMetadata to set any additional info about your IMessageSender. Based on the ExportMetadata you can query the exports and to use the one you need at the moment. See this article:

ronaldwidha Jan 25, 2009 at 1:46 PM 
That's the job of the catalog. The boundaries can be assembly-wide (execute all implementation in the executing assembly), directory-wide, etc.

andreir Dec 1, 2008 at 1:58 PM 
What if I want to have available all the IMessageSender implementations (which BTW would reside in different assemblies such as MyProject.Senders.Tcp and MyProject.Senders.Smtp for example) but only to use one at a moment?

I would have a configuration file setting which would act as a switch to select which sender would be used at runtime.

How do you accomplish this with MEF? I see the IEnumerable<IMessageSender> member in the last snippet but how do I select the desired one? Foreach / LINQ to objects over it?