Share via

MEF features for v.next – feedback request

  • Article

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

  • Anonymous
    June 11, 2010
    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.

  • Anonymous
    June 11, 2010
    I vote for "AOP/Interceptors"

  • Anonymous
    June 13, 2010
    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

  • Anonymous
    June 13, 2010
    Some kind of dependency assembly isolation when using xap partitioning. mef.codeplex.com/.../View.aspx

  • Anonymous
    June 15, 2010
    Everything that windsor does. Should be easy for you :P

  • Anonymous
    June 19, 2010
    My vote AOP/interception

  • Anonymous
    August 29, 2010
    Can I Unit test MEF?

  • Anonymous
    August 31, 2010
    The comment has been removed

  • Anonymous
    September 07, 2010
    Generics are important to me.

  • Anonymous
    September 23, 2010
    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.

  • Anonymous
    October 28, 2010
    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)

  • Anonymous
    January 11, 2011
    I vote for AOP/Interceptors & custom lifetime managers. Basically I would like to replace Unity and policy injection with it. Grz, Kris.