MEF features for v.next – feedback request


We’re in planning phase for MEF for quite some time. I believe we have a very decent idea of things that needs improvement, and the priority of those. Of course, our team has limited resources so there are no promises whether we can actually ship any of those in the next MEF release. That said, it would be great if you could weight in and let us know what would you consider more valuable. Pick one or two items that you rather see us not shipping a v.next unless we add those. 🙂

Some ideas of features (feel free to suggest more)

  • – Convention-based discovery catalog
  • – Explicit wiring
  • – Generic instantiation (being able to export IRepository<> and import IRepository<Customer>)
  • – Better diagnostics
  • – AOP/Interceptors
  • – Integration with XAML/WPF
  • – Integration with Azure
  • – Simplification of scoping/container hierarchy
  • – Custom lifetimes (per thread, transactional)

 

Anything I’ve missed?

Comments (12)

  1. Umm please move"Generic instantiation" to the very top of the list, Thanks! 🙂

    Ok I also REALLY want:

    1) The ability to right-click in Visual Studio to set a "MEF Reference" that will automatically note the assemblies in the project that I am adding and set them to copyLocal=False if the parent project already has them

    2) Then it shows me the refrenced projects in a window and I can drag and drop them directly onto the Design surface and it will automatically write all the code.

    3) I can also interact with it in code behind.

    Basically give me the same experience I have with web services.

  2. slamballx says:

    I vote for "AOP/Interceptors"

  3. Martin Bohring says:

    A WS-Discovery based catalog with dynamic recomposition would also by a nice idea.

    It could resolve imports by  sending probe / resolve messages and do dynamic recomposition based on Hello and By messages

  4. Szili says:

    Some kind of dependency assembly isolation when using xap partitioning.

    mef.codeplex.com/…/View.aspx

  5. Chris says:

    Everything that windsor does. Should be easy for you 😛

  6. Paul Linton says:

    My vote

    AOP/interception

  7. Yazid says:

    Can I Unit test MEF?

  8. @Yazid, it's not a goal to be able to unit test the Framework, but it is a goal that your MEF parts/components should be easily unit testable.

  9. User from .Net 2.0 says:

    Generics are important to me.

  10. Morten Mertner says:

    I'd say scoping and lifetime would be the most useful, especially for the use in web projects.

    Most of the other items can be fixed simply by using an(other) IoC container and are therefore less critical, even if they are nice features.

  11. Luc Cluitmans says:

    Apologies for coming late to the party – I only discovered this blog last week 🙂

    One thing I didn't see mentioned but would like to see is a way to get rid of "contract assemblies" – assemblies whose sole function is to hold interfaces (or abstract base classes) to be used as contract interfaces.

    In a typical multi-assembly plugin situation you currently need 3 assemblies: a host, a plugin (there can be many of course) and a glue assembly that allows host and plugin to agree on interface types. It would be nice to find out if there is a way to get rid of that glue assembly.

    One way to do so could be via a "Duck Typing"-like approach.

    Another way would involve tricking the .NET framework and MEF in making it believe that an interface declared separately in both host and plugin is actually one and the same interface. I know there is a system to do the latter, but any mentions of it are hidden well in a niche functionality (COM interop) and it was a bit clumsy to use in practice. (IIRC the feature was called "Type Embedding", it revolves around using a GuidAttribute on interfaces)

  12. XIII says:

    I vote for AOP/Interceptors & custom lifetime managers. Basically I would like to replace Unity and policy injection with it.

    Grz, Kris.