Customer Question – Does MEF allow injection without using attributes?
Peter Richie asks:
“MEF allows decoupling of TypeA's dependency on TypeB, but now TypeA and TypeB have an assembly-level dependency on the MEF assemblies. If I have a specific restriction on deployment of the assemblies required by TypeB such that they must be signed with a specific key, for example, using attributes is out of the question because I can't deploy the assemblies that contain the Attribute classes.
As well, if I have a type in an existing assembly with a property that I could "export", if that's a 3rd party assembly where I don't have the source to add an Export attribute, how can I wire up that type+member to be used as a component?
Please offer a way to define the logical relationships of types without having introduce new dependencies and modify existing source code. Ideally this would include both a way to do it with XML configuration and in code. This is very common for other IoC and DI containers.”
Using the [Import] and [Export] attributes to define your inputs and outputs is what we are calling the 'default' programming model. That is, if you were in a green field scenario, and were starting from scratch, then this is the model we would encourage most applications adopt. In fact this model is exactly what Visual Studio and a few other applications coming out of Microsoft will be using as the basis of their extensibility models going forward.
Brown field scenarios, or where you just want to use Plain Old CLR Objects (POCO) and avoid 'dirtying' your types with attributes, is a scenario that we plan on supporting. We know that today, we are not exactly where we want to be in six months with regards to extensibility. However, in saying that, we do already provide some hooks to support this today in the CompositionContainer.
For example, customers can create their own custom resolver (by deriving ValueResolver), which probes a configuration file for available components, and feeds instances of a ComponentBinder (which provides the mechanism for providing exports and for setting imports from a component) into the CompositionContainer. The CompositionContainer has a constructor that takes a resolver as an argument - simply pass the custom resolver via that.
We don't yet provide any samples that do this, but expect some to appear on the team members blogs in the coming weeks (see the Managed Extensibility Framework Blogs and Resources announcement at the top of the forum for links).
We're also looking at what scenarios we will support out of the box; we've already heard from the community a lot that the external manifest (whether that be a configuration file, database, code or some other form) is something that they want to see supported, and as such, is something that is definitely on our radar.