Analyze MEF Assemblies from the Command Line

In MEF Preview 6 we shipped a sample assembly called Microsoft.ComponentModel.Composition.Diagnostics, demonstrating the kinds of things that can be determined by (semi-) statically analyzing MEF catalogs.

With Preview 7 we added a utility that makes use of the diagnostics routines to print information about parts directly from the command-line.

C:\Users\…\CompositionDiagnostics> mefx /?


      Print usage.


      List root causes – parts with errors not related to the rejection of other parts.


      Specify directories to search for parts.


      List exporters of the given contract.


      Find exported contracts.


      Specify assemblies to search for parts.


      List importers of the given contract.


      Find imported contracts.


      List all parts found in the source assemblies.


      List all rejected parts.


      Print details of the given part type.


      Print verbose information on each part.

The /parts switch list all parts in a composition:

C:\Users\…\CompositionDiagnostics> mefx /dir:..\MefStudio /parts




While the /rejected and /causes switches will print information about rejected parts and suspected root causes respectively.

By specifying the /verbose switch, detailed information about parts can be retrieved:

C:\Users\…\CompositionDiagnostics> mefx /dir:..\MefStudio /type:Designers.BasicComponentFactory /verbose

[Part] Designers.BasicComponentFactory from: DirectoryCatalog (Path="..\MefStudio")

  [Export] Designers.BasicComponentFactory (ContractName="Contracts.HostSurfaceFactory")

  [Import] Contracts.HostSurfaceFactory.propertyGrid (ContractName="Contracts.IPropertyGrid")

    [Actual] ToolWindows.PropertyGridWindow (ContractName="Contracts.IPropertyGrid") from: ToolWindows.PropertyGridWindow from: DirectoryCatalog (Path="..\MefStudio")

  [Import] Contracts.HostSurfaceFactory.Commands (ContractName="System.Void(Contracts.HostSurface)")

    [Actual] Designers.CSharp.Commands.Cut (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

    [Actual] Designers.CSharp.Commands.Copy (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

    [Actual] Designers.CSharp.Commands.Paste (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

There are a few more goodies in there for the curious.

It is important to realise that the utility can only analyze MEF assemblies built against a compatible version of MEF; for example, mefx.exe built against the CodePlex drops will not be able to analyze assemblies built against the signed .NET Framework version of MEF, and vice-versa.

We call these “samples” right because they’re for the purpose of our own exploration. Some experience with applying these techniques will hopefully lead to some great production-quality tools in a future milestone.

One particular direction I’d like to venture is towards tooling suitable for continuous integration (CI), for example, a build task capable of validating component status.

If you have ideas for improvement or an opportunity to try mefx, we’d love to hear from you.

Comments (6)

  1. Great idea.

    Here are just some more thoughts:

    1. Remember Autofac IoC inspector I’ve been toying with?

    Similar thing could be implemented for MEF (and also built as example of MEF studio/extensibility). Since IoC graphs are getting more and more complex these days, a way to visualize the dependencies somehow might be helpful.

    2. Re CI integration, AFAIK StructureMap had some validation mode.

    3. MEFProfiler (to look for inefficient resolution scenarios and just some patterns)?

    Keep up the great work!

  2. niblumha says:

    @Rinat – yes, I do remember the Autofac/xLim inspector.. Unfortunately my GUI design skills are no match for yours 🙂

    Since the MEF inspection routines are separate from the console app, I hope someone in the community will take a shot at a GUI version.



  3. Re design skills – I simply "cheated" by using DXperience UI component suite and IconExperience icon set))

    Re overall MEF – are there any long-term plans around this direction? Like creating deeper development ecosystem around the extensibility framework (i.e.: pushing the research, gathering around practices, tools and various development adapters (like CC.NET validation bits) etc)? Or is it going to end at the CodePlex and BCL?


  4. niblumha says:

    The Visual Studio/MEF scenarios will probably drive a lot of tooling, both design-time and ‘community’ features like the existing Template Gallery.

    How much of this will get into the mainstream developer workflow is unclear right now – but in any case, MEF is very tooling-friendly and a lot of third-party support is likely to show up.


  5. Glenn Block says:

    Hi Rinat

    We’re looking into providing a much richer design-time experience post .NET 4.0. It’s preliminary right now, but it’s high on our priority list.

  6. OK, well, never mind my last comment about mefx not recursing subdirectories. I realized it was my calling code recursing subdirectories. If that got lost on moderation, perhaps this one will too 🙂