This project has moved and is read-only. For the latest updates, please go here.

VS2010/.NET 4.0 build of MEF src+samples available

Jun 30, 2009 at 7:50 PM

I have put together a build of the MEF preview 5 source
using VS2010/.NET 4.0.

Anyone interested can download it from:

See "Building MEF With VS2010.pdf" in the root folder
for some notes about the build.

Hopefully when MEF preview 6 is released on Codeplex (when?)
it will contain a .NET 4.0 build.

- Eamon

Jun 30, 2009 at 11:07 PM

That is a very nice walk-through on converting to .Net 4.0 and VS2010.

We are currently planning the next codeplex release (to be released within a couple weeks) but we currently aren't planning on providing projects/solutions for .Net 4.0 and VS2010. Is there any particular reason that you need a version of MEF that is built against .Net 4.0 that is different then the version installed in the GAC with VS2010?
Is the only reason because you have VS2010 installed and you cannot open the solution?
Would a solution that builds MEF against .Net 3.5 and but works in VS2010 work for your needs?

Jul 1, 2009 at 6:15 PM

The main reason is to allow for experimentation. Obviously for real work, folks should use what is in the GAC.

I wished to modify the internals of MEF and try out a few ideas. e.g. I think CompositionContainer is fine for general purpose usage but there may be also a need for alternatives. For more advanced uses it could be slimmed down to be just a container for export providers and a composition engine,  with no need for special code for catalogs or parts. I think a feature-per-export-provider is a  good idea (e.g. AdaptingExportProvider), but the application developer should be given total control over the layout of the export providers (i.e. manually create the topology of export providers) and use the ComposablePartExportProvider directly to compose parts. This flexibility also comes at the cost of the app developer having to write a little more code, so some will wish to continue using CompositionContainer.

Here is what an alternative might look like:

public class AlternativeContainer : ExportProvider, ICompositionService, IDisposable {

public ExportProvider RootProvider { get; private set; }

private CompositionEngine _compositionEngine = new CompositionEngine ();

public AlternativeContainer(ExportProvider rootProvider){

    RootProvider = rootProvider;

    _compositionEngine.SourceProvider = this;


// GetExportsCore/SatisfyImports/UnregisterForComposition same as CompositionContainer


Jul 2, 2009 at 2:17 AM

While it is awesome that you are experimenting (which is what we are releasing the source for) I don't believe this requires .Net 4.0. So why did you feel the need to go through the process of converting the project to build against .Net 4.0. You can certainly do all these pieces on .Net 3.5, unless of course there is something new in .Net 4.0 you use in your MEF experimentation.

Jul 2, 2009 at 9:00 PM

It is an interesting question - could any of the new features in .NET 4 be useful inside a MEF implementation? The MEF API should be compatible between .NET 3.5SP1 and .NET 4.0, but internally, can/should more use be made of what is new in .NET 4.0? ("What's New in the .NET Framework 4" - )

I'll pick just one area that I think could be of huge benefit - the new .NET 4.0 parallel functionality.

In MEF Preview 5, are CPU-intensive areas of MEF - namely CompositionEngine and the catalogs, optimized for multicore hardware? There is some threading usage in MEF (locks and Thread.MemoryBarrier) but can it be enhanced?

Intel will shortly have its Nehalem-EX 8-core processor on the market, with each core running two threads concurrently, and many boxes will have a pair of these processors - so 32 concurrent threads. These boxes will be expensive at the end of 2009, reasonably priced at the end of 2010 and cheap at the end of 2011.

How will a substantial MEF app (e.g. 50 assemblies, 100,000 classes, with maybe 500 classes having MEF imports/exports) run on such a box? During app startup, will Windows Task Manager show one thread 100% busy and 31 idle, or will there be a more even distribution of the workload?

Are types that use Parallel .NET such as ParallelCompositionEngine and ParallelDirectoryCatalog needed, or should the fact that they work great in a multicore envronment just be in the normal version?