MEF Wiki & Documentation Rss Feed

New Comment on "Documentation"

TomyTeo — Thu, 10 Jan 2013 10:05:55 GMT

Hello, this is a really fascinating web blog and I have loved reading several of the articles and posts contained upon the site, sustain the great work and hope to read a lot more exciting articles in the time to come. Thank you so much. <a href="http://vienne.co/tui-xach-thoi-trang" rel="dofollow">tui xach thoi trang</a>

New Comment on "Documentation"

TomyTeo — Thu, 10 Jan 2013 10:04:17 GMT

Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. If possible, as you gain expertise, would you mind updating your blog with more information? It is extremely helpful for me...thanks http://verchini.com/that-lung

New Comment on "Microsoft.Composition FAQ"

caiqixian — Fri, 21 Dec 2012 01:03:54 GMT

Can I Use MEF in my WinForm applications?

New Comment on "DeploymentCatalog"

mokdes — Tue, 27 Nov 2012 21:13:49 GMT

I'm getting this issue when I try to reload a xap file using DeploymentCatalog, the file is reloaded successfully but the re-composition seems to use the old version of the xap file. Here is the situation: I have a module called ModuleA.xap that is loaded when a button is clicked on UI. after the ModuleA.xap is loaded using DeploymentCatalog a list is populated with data that comes from a service defined within ModuleA.xap. the service has property called Version [String] that's shows on UI. A updated Module.xap package and assigned a new value for Version property. I clicked the button to reload ModuleA.xap. After recomposition I still see the old value for Version property. !!!!!! Through Chrome I see that a request is made and the updated version of ModuleA.xap is loaded. but when I change the assembly version re-composition fails !!!!!!! -Hamid

New Comment on "Exports and Metadata"

mchurchill — Tue, 30 Oct 2012 01:42:23 GMT

If you allow multiple custom export attributes, keep in mind that in the case of your MyExportWithMetadata { string Metadata {g;s} }, your matching metadata view interface will look like: IMyMetaView { string[] { g; } }.

Updated Wiki: Documentation

alokshriram — Thu, 18 Oct 2012 22:28:12 GMT

Microsoft.Composition

Documentation for MEF in web and .NET for Windows Store apps on this site:

What is Microsoft.Composition?
Sharing and lifetime in Microsoft.Composition
Extending Microsoft.Composition with alternative programming models
Avoiding reference (memory) leaks in Microsoft.Composition
Unit Testing Microsoft.Composition
Creating a Standalone Web API dependency resolver using Microsoft.Composition
To move code from MEF in the .NET Framework from 4.0 see the migration guide
Microsoft.Composition FAQ

MEF in the .NET Framework (from 4.0)

Please see the introductory and reference documentation on MSDN (more).

Updated Wiki: Documentation

alokshriram — Thu, 18 Oct 2012 22:26:40 GMT

Microsoft.Composition

Documentation for MEF in web and .NET for Windows Store apps on this site:

What is Microsoft.Composition?
Sharing and lifetime in Microsoft.Composition
Extending Microsoft.Composition with alternative programming models
Avoiding reference (memory) leaks in Microsoft.Composition
Unit Testing Microsoft.Composition
Creating a Standalone Web API dependency resolver using Microsoft.Composition
To move code from MEF in the .NET Framework from 4.0 see the migration guide
Microsoft.Composition FAQ

MEF in the .NET Framework (from 4.0)

Please see the introductory and reference documentation on MSDN (more).

Updated Wiki: Documentation

alokshriram — Thu, 18 Oct 2012 18:33:53 GMT

Microsoft.Composition

Documentation for MEF in web and .NET for Windows Store apps on this site:

What is Microsoft.Composition?
Sharing and lifetime in Microsoft.Composition
Extending Microsoft.Composition with alternative programming models
Avoiding reference (memory) leaks in Microsoft.Composition
Unit Testing Microsoft.Composition
Creating a Standalone Web API dependency resolver using Microsoft.Composition
To move code from MEF in the .NET Framework from 4.0 see the migration guide
Microsoft.Composition FAQ

MEF in the .NET Framework (from 4.0)

Please see the introductory and reference documentation on MSDN (more).

Updated Wiki: MetroChanges

alokshriram — Thu, 18 Oct 2012 18:33:34 GMT

MEF for Windows 8 Windows Store apps

In .NET 4.5 Beta, Windows 8 Windows Store apps could use a subset of MEF functionality from the full .NET Framework. To better align with the goals and scenarios of Windows Store apps, in .NET 4.5 RC MEF for Windows Store apps is consumed by installing the Microsoft.Composition package.

The MEF implementation in Microsoft.Composition is not code-compatible with the MEF functionality in .NET 4.5 Beta.

For most applications, a few simple steps will be required to move to the new MEF version. These are outlined step-by-step below. A full list of changes follows.

Project-level changes

Referencing the new assemblies

The new assemblies are referenced using the Visual Studio Package Manager dialog.

Right-click on your Windows Store application project
Select “Manage NuGet Packages”
Select “Include Prerelease Packages”
Search for Microsoft.Composition
Click “Install”

Alternatively, the Package Manager Console can be used:

Install-Package Microsoft.Composition –Pre

Delivering MEF as a NuGet package enables a more responsive development process.

Namespace change

Use Visuals Studio’s Find and Replace in Files dialog to replace the text:

System.ComponentModel.Composition

with:

System.Composition

Rationale: MEF for Windows Store apps is optimized for this model and therefore makes changes to some fundamental MEF types like [Import] and [Export]. Changing the namespace ensures that types can be uniquely identified and correct information can be found more easily.

Part-level changes

Import/Export visibility

Imported and exported members must be publicly visible in order for them to be composed. For example:

    [Import]
    private ILogger Logger { get; set; }

Must be updated to:

    [Import]
    public ILogger Logger { get; set; }

The same is true of importing constructors and property exports.

Rationale: Requiring that imports and exports are public ensures that parts behave consistently on all platforms, and that code generation techniques can be used to improve throughput.

Unsupported features

Field exports and imports are not supported – use property imports and exports instead.

Rationale: Due to the requirement for public imports and exports, fields are less useful for this purpose. Ignoring them improves startup time for the composition engine.

Part creation policy

[PartCreationPolicy(CreationPolicy.NonShared)] is no longer required, as parts are non-shared by default.

Parts that need to be shared are marked with the [Shared] attribute.

Rationale: The default creation policy was previously CreationPolicy.Any, making it confusing to determine the scope in which a part could be used. Sharing and lifetime have been streamlined so that the sharing scope of a part is always explicitly visible – a part marked [Shared] will always be globally shared; a part marked [Shared("vm")] will always be shared within the named boundary “vm”, parts without an annotation are always non-shared. See also: [SharingBoundary] and ExportFactory<T>.

IPartImportsSatisfiedNotification

This interface has been replaced with the OnImportsSatisfied attribute.

For example, the following part:

    [Export]
    public class APart : IPartImportsSatisfiedNotification
    {
        public void OnImportsSatisfied() { }
    }

Can be rewritten as:

    [Export]
    public class APart 
    {
        [OnImportsSatisfied]
        public void OnImportsSatisfied() { }
    }

Rationale: MEF’s convention support is based on attributes. By marking the OnImportsSatisfied() method with an attribute, conventions can select this method. This was not possible with the interface-based approach.

Format of Metadata Views

Metadata views must be concrete types rather than interfaces. For example, the metadata view:

    public interface INamed
    {
        string Name { get; set; }
    }

Can be rewritten as:

    public class Named
    {
        public string Name { get; set; }
    }

Rationale: This requirement arises from the absence of the System.Reflection.Emit namespace in .NET for Windows Store apps. Without the functionality in this namespace, metadata views based on interfaces cannot be generated.

Hosting changes

Container configuration

On the hosting side, a smaller API with fewer configuration points is presented. Assemblies and part types are added to a ContainerConfiguration (rather than a catalog) and from there a container can be created and exports requested.

    var configuration = new ContainerConfiguration()
                        .WithAssembly(typeof(App).GetTypeInfo().Assembly);

    using (var container = configuration.CreateContainer())
    {
        var handler = container.GetExport<IMessageHandler>();
        handler.Handle(message);
    }

The ContainerConfiguration class provides a method-chaining API to add types and assemblies to the container. There is no catalog concept, nor composition batches, nor any “container hierarchy” or composition scoping APIs.

Rationale: The hosting APIs used in MEF in the full .NET Framework are designed to support open, extensible applications. This functionality is not required in Windows Store apps, and so the developer experience is simplified.

Conventions and RegistrationBuilder

In .NET 4.5 MEF introduces the RegistrationBuilder class. On Windows Store apps the same functionality is available via ConventionBuilder.

Rationale: ConventionBuilder is expected to evolve significantly in conjunction with the MEF implementation for Windows Store apps. Retaining the RegistrationBuilder name would make these differences confusing.

MEF in Windows Store apps vs. .NET Framework

The table below summarizes high-level feature compatibility across MEF for Windows Store apps and the full framework.

Functionality	Windows Store apps	Full
Catalogs	No	Yes
Recomposition	No	Yes
Rejection	No	Yes
Instance Exports	Yes	Yes
Static Exports	No	Yes
Property Exports	Yes	Yes
Field Exports	No	Yes
Importing Constructors	Yes	Yes
Property Imports	Yes	Yes
Field Imports	No	Yes
Method Exports	No	Yes
Internal Part Types	Yes	Yes
Non Public Imports/Exports	No	Yes
Export Metadata	Yes	Yes
Import Metadata Views	Yes	Yes
Part Metadata	Yes	Yes
Nested Containers	No	Yes
Composition Scope Definition	No	Yes
Lazy Imports	Yes	Yes
ExportFactory Imports	Yes	Yes
Import Many	Yes	Yes
Import Custom Collections	No	Yes
Contract Names	Yes	Yes
Import Sources	No	Yes
Cyclic Dependencies	Yes	Yes
Open Generics	Yes	Yes
IPartImportsSatisfiedNotification	No	Yes
Import Required Creation Policy	No	Yes
Interface Metadata Views	No	Yes
Concrete Metadata View s	Yes	Yes
Missing Metadata Ignored	No	Yes
Inherited Exports	No	Yes
PartCreationPolicyAttribute	No	Yes
CatalogReflectionContextAttribute	No	Yes
MetadataAttributeAttribute	Yes	Yes
PartNotDiscoverableAttribute	Yes	Yes
ICompositionService	No	Yes
CompositionOptions	No	Yes

Updated Wiki: Changes

alokshriram — Thu, 18 Oct 2012 18:33:27 GMT

MEF for Windows 8 Windows Store apps

Project-level changes

Referencing the new assemblies

The new assemblies are referenced using the Visual Studio Package Manager dialog.

Right-click on your Windows Store application project
Select “Manage NuGet Packages”
Select “Include Prerelease Packages”
Search for Microsoft.Composition
Click “Install”

Alternatively, the Package Manager Console can be used:

Install-Package Microsoft.Composition –Pre

Delivering MEF as a NuGet package enables a more responsive development process.

Namespace change

Part-level changes

Import/Export visibility

Imported and exported members must be publicly visible in order for them to be composed. For example:

    [Import]
    private ILogger Logger { get; set; }

Must be updated to:

    [Import]
    public ILogger Logger { get; set; }

Unsupported features

Part creation policy

IPartImportsSatisfiedNotification

This interface has been replaced with the OnImportsSatisfied attribute.

For example, the following part:

    [Export]
    public class APart : IPartImportsSatisfiedNotification
    {
        public void OnImportsSatisfied() { }
    }

Can be rewritten as:

    [Export]
    public class APart 
    {
        [OnImportsSatisfied]
        public void OnImportsSatisfied() { }
    }

Format of Metadata Views

Metadata views must be concrete types rather than interfaces. For example, the metadata view:

    public interface INamed
    {
        string Name { get; set; }
    }

Can be rewritten as:

    public class Named
    {
        public string Name { get; set; }
    }

Hosting changes

Container configuration

    var configuration = new ContainerConfiguration()
                        .WithAssembly(typeof(App).GetTypeInfo().Assembly);

    using (var container = configuration.CreateContainer())
    {
        var handler = container.GetExport<IMessageHandler>();
        handler.Handle(message);
    }

Conventions and RegistrationBuilder

MEF in Windows Store apps vs. .NET Framework

The table below summarizes high-level feature compatibility across MEF for Windows Store apps and the full framework.

Functionality	Windows Store apps	Full
Catalogs	No	Yes
Recomposition	No	Yes
Rejection	No	Yes
Instance Exports	Yes	Yes
Static Exports	No	Yes
Property Exports	Yes	Yes
Field Exports	No	Yes
Importing Constructors	Yes	Yes
Property Imports	Yes	Yes
Field Imports	No	Yes
Method Exports	No	Yes
Internal Part Types	Yes	Yes
Non Public Imports/Exports	No	Yes
Export Metadata	Yes	Yes
Import Metadata Views	Yes	Yes
Part Metadata	Yes	Yes
Nested Containers	No	Yes
Composition Scope Definition	No	Yes
Lazy Imports	Yes	Yes
ExportFactory Imports	Yes	Yes
Import Many	Yes	Yes
Import Custom Collections	No	Yes
Contract Names	Yes	Yes
Import Sources	No	Yes
Cyclic Dependencies	Yes	Yes
Open Generics	Yes	Yes
IPartImportsSatisfiedNotification	No	Yes
Import Required Creation Policy	No	Yes
Interface Metadata Views	No	Yes
Concrete Metadata View s	Yes	Yes
Missing Metadata Ignored	No	Yes
Inherited Exports	No	Yes
PartCreationPolicyAttribute	No	Yes
CatalogReflectionContextAttribute	No	Yes
MetadataAttributeAttribute	Yes	Yes
PartNotDiscoverableAttribute	Yes	Yes
ICompositionService	No	Yes
CompositionOptions	No	Yes

Updated Wiki: Avoiding reference (memory) leaks in MEF for Metro style apps

alokshriram — Thu, 18 Oct 2012 18:29:51 GMT

All versions of MEF implement some level of tracking of the parts that the composition engine creates. In MEF for Windows Store apps (System.Composition namespaces) this is for the purpose of ensuring that disposable parts can be released properly.

To avoid holding on to part instances for longer than is required, the following guidance applies.

Where multiple instances of a part need to be created, use an ExportFactory<T> rather than calling GetExports() multiple times on the container.

This code may leak memory.

// Within the class declaration of a part
CompositionContext _container = ...;


// If page objects have disposable dependencies,
// they will be tracked by _container.
public Page CreatePage()
{
    _container.GetExport<Page>();
}

Creating a page: this code does not leak.

// Within the class declaration of a part

[Import]
public ExportFactory<Page> PageFactory { get; set; }

public Page CreatePage()
{
   return PageFactory.CreateExport().Value;
}

If the Export<T> instance is garbage collected, all collectible parts will also be free for collection (regardless of whether or not Dispose() is called).

The Export<T> instance returned from the CreateExport() method can be disposed in order to dispose related parts:

public void ShowPage()
{
   using (var page = PageFactory.CreateExport())
   {
      // Outside the using block, the page and its dependencies
      // will be disposed.
      page.Value.Show();
   }
}

If you need to use CompositionContext (rather than ExportFactory<T>) for some reason, e.g. to implement a service locator, then use ExportFactory<CompositionContext> to create a new CompositionContext for each unit of work.

This applies when using CompositionContext.SatisfyImports() as well.

Updated Wiki: Avoiding reference (memory) leaks in MEF for .Net 4.5 and Windows Store Apps

alokshriram — Thu, 18 Oct 2012 18:29:25 GMT

// Within the class declaration of a part
CompositionContext _container = ...;


// If page objects have disposable dependencies,
// they will be tracked by _container.
public Page CreatePage()
{
    _container.GetExport<Page>();
}

Creating a page: this code does not leak.

// Within the class declaration of a part

[Import]
public ExportFactory<Page> PageFactory { get; set; }

public Page CreatePage()
{
   return PageFactory.CreateExport().Value;
}

public void ShowPage()
{
   using (var page = PageFactory.CreateExport())
   {
      // Outside the using block, the page and its dependencies
      // will be disposed.
      page.Value.Show();
   }
}

Updated Wiki: Standalone Web API dependency resolver using Microsoft.Composition

alokshriram — Thu, 18 Oct 2012 18:24:05 GMT

Creating a self-host dependency resolver for ASP.NET Web API using Microsoft.Composition

ASP.NET Web API’s IDependencyResolver interface allows IHttpControllers to accept dependencies using dependency injection. By plugging in MEF via this interface, controllers can import their dependencies using the familiar techniques of constructor and property injection.

This page describes the creation and usage of an IDependencyResolver based on the Microsoft.Composition NuGet package. Source code from the example is in the /oob/src/System.Composition.Web.Http folder in the source code repository on this site.

IDependencyScope

Web API requests exports (which it calls 'services') from an IDependencyScope. The dependency scope can be used to control sharing on a per-API-call basis, and allows parts to be disposed when no longer required by Web API.

We call this a “standalone” dependency resolver because it is intended for use in self-hosting scenarios; when using Web API with ASP.NET MVC it may be preferable to bridge the Web API dependency resolver across to the MVC one.

    public class StandaloneDependencyScope : IDependencyScope
    {

MEF for web and Windows Store apps uses composition contexts to represent scopes. To allow the scope to be disposed when no longer required by Web API, an Export<CompositionContext> is used:

        readonly Export<CompositionContext> _compositionScope;

        public StandaloneDependencyScope(Export<CompositionContext> compositionScope)
        {
            if (compositionScope == null) throw new ArgumentNullException("compositionScope");
            _compositionScope = compositionScope;
        }

        protected CompositionContext CompositionScope { get { return _compositionScope.Value; } }

        public void Dispose()
        {
            Dispose(true);
        }

        protected void Dispose(bool disposing)
        {
            if (disposing)
                _compositionScope.Dispose();
        }

Web API uses two methods – GetService() and GetServices() – to request exports from the scope. Rather than throwing on failure, Web API requires that we return null if a service is unavailable:

        public object GetService(Type serviceType)
        {
            if (serviceType == null) throw new ArgumentNullException("serviceType");

            object result;
            CompositionScope.TryGetExport(serviceType, null, out result);
            return result;
        }

        public IEnumerable<object> GetServices(Type serviceType)
        {
            if (serviceType == null) throw new ArgumentNullException("serviceType");

            return CompositionScope.GetExports(serviceType, null);
        }
    }

IDependencyResolver

IDependencyResolver serves two purposes:

It is used by WebAPI to create an IDependencyScope for each incoming API call
It is itself an IDependencyScope used by Web API to access services that are required for the duration of the application’s lifetime

First, to provide the required dependency scope behavior, the dependency resolver derives from the dependency scope type:

    public class StandaloneDependencyResolver : StandaloneDependencyScope, IDependencyResolver
    {

The dependency resolver is initialized using a CompositionHost object; this is wrapped in an Export<CompositionContext> so that it can satisfy the base class constructor requirements:

        readonly ExportFactory<CompositionContext> _requestScopeFactory;

        public StandaloneDependencyResolver(CompositionHost rootCompositionScope)
            : base(new Export<CompositionContext>(rootCompositionScope, rootCompositionScope.Dispose))
        {
            if (rootCompositionScope == null) throw new ArgumentNullException();
            var factoryContract = new CompositionContract(typeof(ExportFactory<CompositionContext>), null, new Dictionary<string, object> {
                { "SharingBoundaryNames", new[] { "HttpRequest" } }
            });

            _requestScopeFactory = (ExportFactory<CompositionContext>)rootCompositionScope.GetExport(factoryContract);
        }

        public IDependencyScope BeginScope()
        {
            return new StandaloneDependencyScope(_requestScopeFactory.CreateExport());
        }
    }

The dependency resolver creates new dependency scopes whenever the BeginScope() method is called. By setting up the _requestScopeFactory as a sharing boundary, parts can be shared within the scope of an API call. An example of a shared part is shown below:

        [Shared("HttpRequest")]
        public class EFRepository : IRepository { }

Parts like the EFRepository class are placed in a /Parts folder and namespace by convention – see below.

It is recommended that string constants (rather than literals like “HttpRequest” as the example shows) are used for sharing boundary names.

Initialization

The dependency resolver needs to be registered with Web API when the application starts up. Here, we create a convention for parts, so that any classes in the /Parts namespace within the application assembly will be used as parts for composition, in addition to API controllers:

    private static void InitializeDependencyResolver(Assembly[] appAssemblies)
    {
        var conventions = new ConventionBuilder();

        conventions.ForTypesDerivedFrom<IHttpController>()
            .Export();

        conventions.ForTypesMatching(t => t.Namespace != null &&
                  (t.Namespace.EndsWith(".Parts") || t.Namespace.Contains(".Parts.")))
            .Export()
            .ExportInterfaces();

        var container = new ContainerConfiguration()
            .WithAssemblies(appAssemblies, conventions)
            .CreateContainer();

        System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver = new StandaloneDependencyResolver(container);
    }

Usage

Once the dependency resolver has been initialized, API controllers can accept constructor dependencies, for example the IRepository interface provided by the EFRepository:

    // Constructor on a controller class
    public ContactsController(IRepository repository) { }

Updated Wiki: Documentation

alokshriram — Thu, 18 Oct 2012 18:23:41 GMT

Microsoft.Composition

Documentation for MEF in web and .NET for Windows Store apps on this site:

What is Microsoft.Composition?
Sharing and lifetime in Microsoft.Composition
Extending Microsoft.Composition with alternative programming models
Avoiding reference (memory) leaks in Microsoft.Composition
Unit Testing Microsoft.Composition
Creating a Standalone Web API dependency resolver using Microsoft.Composition
To move code from MEF in the .NET Framework from 4.0 see the migration guide
Microsoft.Composition FAQ

MEF in the .NET Framework (from 4.0)

Please see the introductory and reference documentation on MSDN (more).

Updated Wiki: MetroChanges

alokshriram — Thu, 18 Oct 2012 18:22:20 GMT

MEF for Windows 8 Windows Store apps

Project-level changes

Referencing the new assemblies

The new assemblies are referenced using the Visual Studio Package Manager dialog.

Right-click on your Windows Store application project
Select “Manage NuGet Packages”
Select “Include Prerelease Packages”
Search for Microsoft.Composition
Click “Install”

Alternatively, the Package Manager Console can be used:

Install-Package Microsoft.Composition –Pre

Delivering MEF as a NuGet package enables a more responsive development process.

Namespace change

Part-level changes

Import/Export visibility

Imported and exported members must be publicly visible in order for them to be composed. For example:

    [Import]
    private ILogger Logger { get; set; }

Must be updated to:

    [Import]
    public ILogger Logger { get; set; }

Unsupported features

Part creation policy

IPartImportsSatisfiedNotification

This interface has been replaced with the OnImportsSatisfied attribute.

For example, the following part:

    [Export]
    public class APart : IPartImportsSatisfiedNotification
    {
        public void OnImportsSatisfied() { }
    }

Can be rewritten as:

    [Export]
    public class APart 
    {
        [OnImportsSatisfied]
        public void OnImportsSatisfied() { }
    }

Format of Metadata Views

Metadata views must be concrete types rather than interfaces. For example, the metadata view:

    public interface INamed
    {
        string Name { get; set; }
    }

Can be rewritten as:

    public class Named
    {
        public string Name { get; set; }
    }

Hosting changes

Container configuration

    var configuration = new ContainerConfiguration()
                        .WithAssembly(typeof(App).GetTypeInfo().Assembly);

    using (var container = configuration.CreateContainer())
    {
        var handler = container.GetExport<IMessageHandler>();
        handler.Handle(message);
    }

Conventions and RegistrationBuilder

MEF in Windows Store apps vs. .NET Framework

The table below summarizes high-level feature compatibility across MEF for Windows Store apps and the full framework.

Functionality	Windows Store apps	Full
Catalogs	No	Yes
Recomposition	No	Yes
Rejection	No	Yes
Instance Exports	Yes	Yes
Static Exports	No	Yes
Property Exports	Yes	Yes
Field Exports	No	Yes
Importing Constructors	Yes	Yes
Property Imports	Yes	Yes
Field Imports	No	Yes
Method Exports	No	Yes
Internal Part Types	Yes	Yes
Non Public Imports/Exports	No	Yes
Export Metadata	Yes	Yes
Import Metadata Views	Yes	Yes
Part Metadata	Yes	Yes
Nested Containers	No	Yes
Composition Scope Definition	No	Yes
Lazy Imports	Yes	Yes
ExportFactory Imports	Yes	Yes
Import Many	Yes	Yes
Import Custom Collections	No	Yes
Contract Names	Yes	Yes
Import Sources	No	Yes
Cyclic Dependencies	Yes	Yes
Open Generics	Yes	Yes
IPartImportsSatisfiedNotification	No	Yes
Import Required Creation Policy	No	Yes
Interface Metadata Views	No	Yes
Concrete Metadata View s	Yes	Yes
Missing Metadata Ignored	No	Yes
Inherited Exports	No	Yes
PartCreationPolicyAttribute	No	Yes
CatalogReflectionContextAttribute	No	Yes
MetadataAttributeAttribute	Yes	Yes
PartNotDiscoverableAttribute	Yes	Yes
ICompositionService	No	Yes
CompositionOptions	No	Yes

Updated Wiki: Avoiding reference (memory) leaks in MEF for Metro style apps

alokshriram — Thu, 18 Oct 2012 18:19:12 GMT

// Within the class declaration of a part
CompositionContext _container = ...;


// If page objects have disposable dependencies,
// they will be tracked by _container.
public Page CreatePage()
{
    _container.GetExport<Page>();
}

Creating a page: this code does not leak.

// Within the class declaration of a part

[Import]
public ExportFactory<Page> PageFactory { get; set; }

public Page CreatePage()
{
   return PageFactory.CreateExport().Value;
}

public void ShowPage()
{
   using (var page = PageFactory.CreateExport())
   {
      // Outside the using block, the page and its dependencies
      // will be disposed.
      page.Value.Show();
   }
}

Updated Wiki: ProgrammingModelExtensions

alokshriram — Thu, 18 Oct 2012 18:18:23 GMT

Extending Microsoft.Composition with Alternative Programming Models

MEF for web and Windows Store apps (aka the Microsoft.Composition NuGet package) set out with the design goal to ship a lean core composition engine that can be richly extended. Most IoC containers follow this philosophy, so to be a bit more specific about our goals:

Most simple extensions should be simple to write and explain
Extensions should provide the same performance, robustness and diagnostics as the core features
A few broad extension points are preferable to many narrow ones

To keep complexity at a minimum it was also our intention to implement as many container features as possible as ‘extensions’, even if they ship in the core package.

In this page we’ll walk through one simple scenario, examine the container extension points that support it, and discuss a few other ways in which these extension points can be put to use.

What is a Programming Model?

The programming model determines how parts are described for the container. Out of the box, Microsoft.Composition supports the familiar MEF Attributed Programming Model in which parts are regular .NET classes marked up with Import and Export attributes.

[Export(typeof(IAmusement))]
public class Rollercoaster : IAmusement
{
    [Import]
    public ITrack Track { get; set; }
}

The Attributed Programming Model is quite flexible and provides support for custom attribute types and for rule-based conventions, but all of these build on the basic programming model foundation for using exports from class-based parts. There are many other ways that values can be supplied for composition.

Using Web.config Settings as Exports

Let’s consider parts that need to be configured with settings from an App.config or Web.config file. Here we’ve created a custom Setting attribute that specifies the key for the setting:

[Export]
public class Downloader
{
    readonly string _url;

    [ImportingConstructor]
    public Downloader([Setting("serverUrl")] string url)
    {
        _url = url;
    }

    public void Download()
    {
        Console.WriteLine("Downloading from {0}...", _url);
    }
}

This hypothetical part, in addition to whatever other imports it has, needs to be configured with the URL of a server. Our container extension is going to enable the serverUrl parameter to be read from the application configuration file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="serverUrl" value="http://mef.codeplex.com" />
  </appSettings>
</configuration>

This effectively turns XML app configuration into a programming model for the container; once it is enabled, appSettings entries specify exports that other parts can consume.

Some might suggest that this is too much coupling between the importing part and the configuration file; this is a reasonable viewpoint, but the model does have some benefits, for example settings used by an application are declaratively discoverable. Like everything, the technique has pros and cons; as an example it covers a lot of the container extension API so let’s run with it here.

Composition Contracts

Microsoft.Composition matches exports to imports based on contracts. A contract is a familiar MEF construct:

In order for an import to match an export, they must share the same contract type, have the same contract name (if any) and have compatible metadata constraints. We write out contracts in the following format:

ContractType "contractName" { ConstraintName = value, ...}

Whenever the container encounters an import for a new contract, it queries the available extensions to see if they can supply a matching export. We’re going to take advantage of this feature to supply a value whenever a part imports an app setting. The first step of that is to determine what the contract for a Setting import will look like.

Constraining the Imported Contract

If we return to the constructor of the Downloader part, without our custom Setting attribute, it looks like this:

    [ImportingConstructor]
    public Downloader(string url)

This makes url into a vanilla MEF import, with a contract that looks simply like:

System.String

This isn’t a great contract – it is so broad that any string will match, there’s no way to match this up with a specific setting value.

We want to ensure that settings are only supplied a very specific value, and the mechanism for doing that is Metadata Constraints. Each constraint comprises a name and a value:

System.String { SettingKey = "serverUrl" }

The rules of contracts require that constraints match exactly, so this contract will no longer be satisfied by just any old string: perfect for our purposes. To specify a metadata constraint on an import, we can use the standard ImportMetadataConstraint attribute:

    [ImportingConstructor]
    public Downloader([ImportMetadataConstraint("SettingKey", "serverUrl")] string url)

This works but is a bit verbose to use frequently. MEF allows the creation of custom attributes to specify export metadata, and the same attributes can be applied to imports to specify metadata constraints. The Setting attribute is such an attribute:

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Parameter)]
[MetadataAttribute]
public class SettingAttribute : Attribute
{
    readonly string _key;

    public SettingAttribute(string key)
    {
        _key = key;
    }

    public string SettingKey { get { return _key; } }
}

We can now use our desired syntax to import settings:

    [ImportingConstructor]
    public Downloader([Setting("serverUrl")] string url)

Using the Setting attribute on an appropriate export will match the import:

    [Export, Setting("serverUrl")]
    public string Url { get { return ... } }

That isn’t our goal here however. The other side of our extension is going to match these constraints and supply exports from the configuration file.

Plugging in an ExportDescriptorProvider

We can plug support for settings into the container as an ExportDescriptorProvider when the container is configured:

var configuration = new ContainerConfiguration()
    .WithAssembly(typeof(Program).Assembly)
    .WithProvider(new AppSettingsExportDescriptorProvider());

The AppSettingsExportDescriptorProvider will be queried whenever the container encounters a new contract. If the contract has a SettingKey constraint, and the value exists in the App.config file, then the provider will return an ExportDescriptor that the container can later use to retrieve the value. We’ll show the complete listing for the provider, then break down each of the steps involved:

public class AppSettingsExportDescriptorProvider : ExportDescriptorProvider
{
    static readonly Type[] SupportedSettingTypes = new[] { typeof(string), typeof(int), typeof(double), typeof(DateTime), typeof(TimeSpan) };


    public override IEnumerable<ExportDescriptorPromise> GetExportDescriptors(
        CompositionContract contract, DependencyAccessor dependencyAccessor)
    {
        string key;
        CompositionContract unwrapped;

        if (!contract.TryUnwrapMetadataConstraint("SettingKey", out key, out unwrapped))
            return NoExportDescriptors;

        if (!unwrapped.Equals(new CompositionContract(unwrapped.ContractType)))
            return NoExportDescriptors;

        if (!SupportedSettingTypes.Contains(unwrapped.ContractType))
            return NoExportDescriptors;

        var value = ConfigurationManager.AppSettings.Get(key);
        if (value == null)
            return NoExportDescriptors;

        var converted = Convert.ChangeType(value, contract.ContractType);

        return new[] {
            new ExportDescriptorPromise(
                contract,
                "Application Configuration",
                true,
                NoDependencies,
                _ => ExportDescriptor.Create((c, o) => converted, NoMetadata)) };
    }
}

The provider implements one method, GetExportDescriptors(), that takes a CompositionContract and returns a list of ExportDescriptorPromises. The DependencyAccessor parameter isn’t used in this example.

The first step in implementing the provider is determining whether the contract has a SettingKey constraint applied. If not, then the request isn’t for an app setting, so the provider returns an empty list:

        string key;
        CompositionContract unwrapped;

        if (!contract.TryUnwrapMetadataConstraint("SettingKey", out key, out unwrapped))
            return NoExportDescriptors;

If the check succeeds, then key will hold the setting key, for example “serverUrl”, and unwrapped will contain the remainder of the contract with the constraint removed. So, in the downloader example, the contract is:

System.String { SettingKey = "serverUrl" }

This will be unwrapped into:

System.String

The next check in the provider makes sure that no name or additional constraints are applied to the contract:

        if (!unwrapped.Equals(new CompositionContract(unwrapped.ContractType)))
            return NoExportDescriptors;

If there are additional constraints that this provider does not understand, or if there’s a contract name applied, then we return nothing. It is very important that providers only match contracts that they understand completely.

For the same reason, the provider checks that the type is a supported setting type. Doing so ensures that the code will properly support Lazy<T> and other relationship types for settings:

        if (!SupportedSettingTypes.Contains(unwrapped.ContractType))
            return NoExportDescriptors;

The next step checks to see if there is a matching value in the application configuration store. If not, perhaps the contract will be supplied another way, so the provider returns an empty list:

        var value = ConfigurationManager.AppSettings.Get(key);
        if (value == null)
            return NoExportDescriptors;

Now that we’re sure the contract is for an app setting, and the key exists in the configuration file, we change the type of the value to match the requested contract type.

        var converted = Convert.ChangeType(value, contract.ContractType);

In this implementation we simply throw an exception if the conversion fails, a better implementation would test for assignability and return an empty list if the types could not be matched.

Now that we have a setting value to match the requested contract, the final step provides the composition engine with all the information it needs to:

Validate the dependency graph
Supply good error messages to the user if necessary
Quickly access the exported value during composition

This information is all wrapped up in the ExportDescriptorPromise that we return:

        return new[] {
            new ExportDescriptorPromise(
                contract,
                "Application Configuration",
                true,
                NoDependencies,
                _ => ExportDescriptor.Create((c, o) => converted, NoMetadata)) };

The “Application Configuration” string describes where the value came from, in case it is needed in an error message. An example could be the case where the same setting is provided elsewhere in the composition:

Only one export for the contract 'String { SettingKey = "serverUrl" }' is allowed, but the following parts: 'Application Configuration', 'SomeOtherPart' export it.
 -> required by import 'serverUrl' of part 'Downloader'

The other more mysterious parameter here is simply ‘true’. This indicates to the composition engine that the resulting instance is shared, and in conjunction with the dependency information returned can be used to check for dependency cycles and so on.

What else is Possible?

There are a number of sample extensions in the MEF CodePlex source repository built using plugged-in ExportDescriptorProviders. These can be found in the /oob/demo subfolder.

Extension	Description
App Settings	The topic of this post. Use <appSetting> values as exports.
Instances	Use an existing instance as an export.
Delegates	Use a supplied delegate to create exported instances on the fly.
Resolve any Concrete Type	“Automatically” supply any concrete type with a parameterless constructor as an export.
Dictionary Imports	Import a dictionary keyed by an export metadata value.
Ordered ImportMany	Order an imported collection using a value from metadata.
Default-only Exports	Specify that an export is a default that is used only when no other export exists for the same contract.

Within the container itself, the Attributed Programming Model is plugged in this way via the TypedPartExportDescriptorProvider, and the technique is used so that the container can supply the current CompositionContext to parts as an import as well. Support for ImportMany, Lazy<T>, ExportFactory<T>, metadata view providers are all plugged in this way.

It is feasible that this extension point could be used to implement an “auto-mocking” container, where the exports are generated on the fly by a mocking framework. It is also conceivable that this extension point might be used to implement a completely different type-based programming model from the attributed one supplied in the box, perhaps mimicking that of another composition framework.

Updated Wiki: What is Microsoft.Composition?

alokshriram — Thu, 18 Oct 2012 18:17:48 GMT

Microsoft.Composition is an update for MEF that is optimized for web and Windows 8 Store apps. It is distributed as a NuGet package compatible with the .NET 4.5 Framework and .NET for Windows Store apps.

These environments do not emphasize in-place third party extensibility, and so composition in these environments can be simplified and streamlined.

Microsoft.Composition includes a lifetime model oriented towards the 'unit of work' patterns that appear in server-side and MVVM-style applications.

Throughput under server workloads is several orders of magnitude higher than what can be achieved with CompositionContainer, and with almost zero contention.

Getting Started

First, install the Microsoft.Composition NuGet package using the Manage NuGet Packages dialog in Visual Studio, or from the Package Manager Console:

PM> Install-Package Microsoft.Composition -Pre

This will add a number of assemblies to the project.

Parts for Microsoft.Composition use the familiar MEF attributes, found in the System.Composition namespace.

[Export(typeof(IMessageHandler))]
public class MessageHandler : IMessageHandler
{
    [ImportingConstructor]
    public MessageHandler(IDatabaseConnection connection)
    {
    }
}

The container is created using a simple ContainerConfiguration class.

var configuration = new ContainerConfiguration()
    .WithAssembly(typeof(MessageHandler).Assembly);

using (var container = configuration.CreateContainer())
{
    var greeter = container.GetExport<IMessageHandler>();
    greeter.Greet();
}

ContainerConfiguration provides the methods WithPart() and WithAssembly() as well as the WithProvider() method for plugging in container extensions.

Conventions are defined in Microsoft.Composition using ConventionBuilder:

var conventions = new ConventionBuilder();
conventions.ForTypesDerivedFrom<IMessageHandler>().Export();

The WithPart() and WithAssembly() configuration methods accept conventions as parameters:

configuration.WithPart<MessageHandler>(conventions);

ConventionBuilder supports the same syntax and rules as RegistrationBuilder does in the full-framework version of MEF. The BCL Team Blog discusses how to define and override conventions.

If you are familiar with MEF in the .NET Framework 4.0 and onwards, see the migration guide for further information.

Updated Wiki: Documentation

alokshriram — Thu, 18 Oct 2012 18:16:49 GMT

Microsoft.Composition

Documentation for MEF in web and .NET for Windows Store apps on this site:

What is Microsoft.Composition?
Sharing and lifetime in Microsoft.Composition
Extending Microsoft.Composition with alternative programming models
Avoiding reference (memory) leaks in Microsoft.Composition
Unit Testing Microsoft.Composition
Creating a Standalone Web API dependency resolver using Microsoft.Composition
To move code from MEF in the .NET Framework from 4.0 see the migration guide
Microsoft.Composition FAQ

MEF in the .NET Framework (from 4.0)

Please see the introductory and reference documentation on MSDN (more).

Updated Wiki: Home

alokshriram — Thu, 18 Oct 2012 18:15:49 GMT

Welcome to the MEF Community Site

Important: this site hosts source code for unsupported, pre-release versions of MEF. If you want to use MEF in production, you should strongly consider using the supported versions included in the .NET Framework and Silverlight.

.NET 4.5 and Windows 8 Store apps can now install the fully-supported, lightweight Microsoft.Composition package from NuGet.

What is it?

The Managed Extensibility Framework (MEF) is a composition layer for .NET that improves the flexibility, maintainability and testability of large applications. MEF can be used for third-party plugin extensibility, or it can bring the benefits of a loosely-coupled plugin-like architecture to regular applications.

Status

MEF is a part of the Microsoft .NET Framework, with types primarily under the System.ComponentModel.Composition.* namespaces.

MEF has shipped with .NET 4.0 and Silverlight 4
MEF 2 is under development
- New features are available in pre-release versions of the .NET Framework 4.5
- Windows 8 Store apps are supported via NuGet