$30 off During Our Annual Pro Sale. View Details »

Diagnosing MEF Failures

Jim Counts
January 30, 2012

Diagnosing MEF Failures

While the Managed Extensibility Framework (MEF) makes it easy to write extensible applications, it brings new types of failures that can be difficult to diagnose. This session will provide background information on why MEF can fail, and then dive into some examples of failed MEF composition and resolution. We'll look at the tools available in MEF by default, two open source alternatives, and new diagnostic features coming in MEF 2.0. Finally we'll see how to use the ApprovalTest library to create an automated integration tests that takes advantage of MEF diagnostics. Also see: http://wp.me/p1HYUa-1n

Jim Counts

January 30, 2012
Tweet

More Decks by Jim Counts

Other Decks in Technology

Transcript

  1. Why care?  Diagnosing composition failure can be tricky at

    first.  Root cause often misidentified by exceptions and tracing.  Better tools are available now.  Better exception and tracing are coming in MEF 2.
  2. What do we already know about MEF?  Hopefully most

    of you have seen Karl’s introduction to MEF.  Key points:  MEF is used to compose parts.  A motor is part of a car.  MEF will reject a part if any required nested part is missing.  To MEF, no such thing as a “car without a motor”.  Or, if its not usable, it doesn’t exist.  Not all parts are required, you can have options  Sun roof is optional, car works without it, but you can only have one.  Cup holders are optional, but you can have many.
  3. What does MEF failure look like?  Composition exception –

    your module explodes and is unusable.  You see this when you ask MEF for a part it can’t provide.  The fact that there are no wheels available for the car is fine… until someone orders a car.  Wrong behavior – Composition succeeds, but desired plugins/services are not loaded.  You see this when asking for a part that has optional parts which MEF can’t provide.  Car still works without cup holders… but customer wont accept the car without them.
  4. Pizza Factory  Pizza Kitchen would have been a better

    name  Wants to import Pizza Makers (recipes)  It wont ever be rejected  But it might not know how to make the pizza the customer orders.  Lets look at some diagnostics [Export(typeof(IPizzaFactory))] public class PizzaFactory : IPizzaFactory { [ImportMany] public IEnumerable<IPizzaMaker> PizzaMakers { get; set; } public IPizza MakePizza(string pizzaType) { // ... } }
  5. Debugger Inspection Pros  Easy way to diagnose simple scenarios.

     You can see what made it into the catalog.  If the catalog is small, you can probably figure out what’s missing.  Comes in the box. Cons  Requires debugger, source code, symbols  Hard to read.  Large catalogs harder to navigate.  Limited use when dealing with a “collection of unknowns”.  No analysis.
  6. Trace Messages Pros  Logs rejected parts.  Does not

    require a debugger.  Comes in the box. Cons  Logs the last cause of failure, not the root cause.  Tells lies.  TMI  No analysis.
  7. MEF Explorer (MEFx) Pros  Cool name  Separate EXE

    provides static analysis for (almost) any MEF application.  Open Source (MS-PL) Cons  Trouble with type load exceptions.  Command line parameters don’t respect the working directory.  Output can be hard to read in command window.
  8. Visual MEFx Pros  Cooler name, has “Visual” in it.

     GUI  Easier to read.  Easier to play with “what-if” scenarios.  Open Source (mefcontrib-tools, MS- PL) Cons  Beware of type load exceptions  GUI
  9. Composition Diagnostics API Pros  Same library used by MEFx

    and VMEFx  Easy to integrate with tests  ApprovalTests can “read” the output for you.  Works with CI when you know what the composition should look like.  Open Source (MS-PL) Cons  Integration tests less useful in “true” plug-in scenario.  Test/Production catalogs must be kept in sync.
  10. MEF 2 The part “FunnySubtitle” was rejected because the part

    “FunnySpeaker” could not be satisfied.
  11. Diagnostics in MEF 2  Better exceptions  Improved formatting

     Root cause is shown (for real this time)  Unstable composition  Container option.  Causes exception to be thrown for any part that would have been rejected.  Great for applications that just use MEF for composition, and not for extensibility.
  12. Satisfaction Checklist  Do your parts have the [Export] attribute?

     Are your matching parts missing from the catalog?  Are there too many matching parts in the catalog?  Did you forget to export using the part’s interface name?  Do your contract names match?  Does each import meta data key exist on the export?  Does the type of the meta data on the import match the type of the meta data on the export (1 != “1”)  Are your parts using the right creation policy?
  13. Satisfaction Checklist  Can your container satisfy all nested imports?

     Did the container reject your change during recomposition?  Do your parts reference unavailable assemblies?  Are there conflicts between different versions of the same assembly?  Do your assemblies target the expected CPU?  Are your assemblies available in your current load context?  Do you have any other type load issues?
  14. References How to Debug and Diagnose MEF Failures, Daniel Plaisted's

    Blog http://blogs.msdn.com/b/dsplaisted/archi ve/2010/07/13/how-to-debug-and- diagnose-mef-failures.aspx Diagnosing Composition Problems, mef.codeplex.com http://mef.codeplex.com/wikipage?title=D ebugging%20and%20Diagnostics&referrin gTitle=Guide
  15. Outline  Why should you care about MEF diagnostics? 

    What do we already know about MEF?  How might MEF fail?  How might we diagnose MEF failures?