MEF Configuration Section/Element Support

Dec 22, 2008 at 7:06 PM
Edited Dec 22, 2008 at 7:21 PM
I am trying to work on my own implementation of MEF configuration support for an application framework I am currently trying to rapid prototype. I have read all about how extensible MEF is with the ability to derive your own custom catalogs, etc, and I am wanting to be able to define container/catalog/part relationships using App.Config files. Is this currently on your todo list or do you not have plans to implement this feature? I would very much not like to put in the time in coming up with a solution if it will soon be replaced by native functionality.

Here is an overview of my idea.
Within the projects App class (or Application in mine, dropping the inheritance bit since it is a partial class), I would like there to be a Composition property that contains all the configuration section/element data defined within the App.config file. In the App.config file, you should be able to define containers and their content, such as parts and catalogs. Eventually, I would like to define imports/exports in this manner without the use of attributes.

Something to this effect.

<?xml version="1.0" encoding="utf-8" ?>
part type="MyApp.Application, MyApp" />
catalog assembly="MyApp.Base" />
catalog assembly="MyApp.Base.Logging" />

At the current time, I have a simple configuration mechanism up and running that just allows you to define assemblies which are to be loaded as catalogs into my monolithic container. I don't like the approach of my current design and wish that there was a way that provides a higher level of granularity when it comes to defining the structure of composition itself.
Dec 22, 2008 at 7:34 PM
We have done a few similar exercises internally, but I dont think we're planning to ship anything similar to that for V1. Let us know if you bump into any problem.
Dec 22, 2008 at 8:08 PM
Edited Dec 22, 2008 at 8:12 PM
But isn't the whole idea of MEF is discovery based on dlls and folders. Why should we then go back in telling the application which assemblies to be cataloged?

If we are taking the xml route then we could simply do Many of MEF function with reflection , a cache and a filewatcher to watch changes in a catalog.
I did do a prototype and came up with a prototype of  something like MEF but using reflection alone.  In one of my many prev posts I had put in my approach as a diagram.

Dec 22, 2008 at 8:16 PM
I dont think this is an accurate statement. MEF is about extensibility, but it's not forced to work on folders. The host application tells MEF what is the discoverable set - could be a folder, could be an assembly, types or a something else.

That being said, some parts of MEF are general purpose enough to be used for different scenarios, with different value propositions. What the original poster described is what we call explicit wiring. We dont support this currently, but we are planning to for V.Next.

Dec 23, 2008 at 1:25 PM
I am interested in a more controlled state of extension, rather than a 'load everything that is available' solution. I don't like the idea that everything in a folder will be loaded just because it is there. How do you know what is being loaded? I like the declarative aspect of using XML to define the composition. What happens when you want to disable a specific assembly from being loaded; delete it? In my opinion, having to resort to that is unacceptable.
Dec 23, 2008 at 1:39 PM
that was something I had debated in some earlier posts. In fact MEF looks more geared towards desktop applications than an enterprise wide applications. I had, if you had looked at my MEF diagram,  a way to cache the MEF object and also have a method to describe what and where the dlls are. 

I would agree with you on the point, that an application has the right to say which dlls / assemblies/ classes it needs. The xml approach is what I used with my application. But with the xml configuration per application around, I think MEF's purpose takes a rearseat.

Having said that how will you support nested links and dependant links in the configuration. How will an application know what all dlls it needs from an MEF repository?
Dec 23, 2008 at 4:19 PM
I have been reading some of your posts and noticed that you are working in an enterprise environment. However, not all of us are so lucky to be in that position. I have been trying for a while to get our development team to move more towards smart-client technologies, etc., that you find in enterprise environments. For the time being, our MEF repository is nothing more than a folder, but I want to move to a custom catalog that feeds off a service to acquire assemblies. I need to be able to know what is loaded, version, dependencies, etc, so that if an update occurs in the repository, the parts will be able to be updated either via a application restart or in-memory replacement. We travel all over the world holding various conferences with upper echelon military leaders from various countries. At any given conference, we have about 300-400 participants (fat clients currently) that engage in title-10 wargames using our software. We have several developers on-site to take care of any bugs that might arise. Majority of our solutions use services provided by AGIs STK product and our extensions are primarily focused on either providing an interface to some STK functionality or providing adjudication for after-action reports.

As for how I will model my MEF configuration functionality, I am not quite sure at this time. My main goal is to replace our monolithic solutions with a more component oriented application framework that will allow us to reuse components across solutions. Some of our solutions come close to 150K+ lines of code and I believe that we can drastically reduce that number with reusable components.

I haven't gotten that far yet. How does yours?
Dec 23, 2008 at 4:52 PM
Hi ganesh

> In fact MEF looks more geared towards desktop applications than an enterprise wide applications

What makes you think that?

Dec 23, 2008 at 6:27 PM
the lack of what jeffery is talking about in one of the reasons. A HR department console and a Finance department console should load only those it wants to in an MEF supported environment. For that to happen there needs to be rules and configurations set up.IMO MEF by itself does not support that.It does need a lot more shell code to give rights to already loaded /instantiated classes.This would make all applications look bloated. What is needed is a way in which the application gets the class it needs from a cached catalog of objects my MEF diagram(utopian dream perhaps)
Dec 23, 2008 at 6:34 PM

@ganesh I believe MEF can support what you are asking. Our new Export Providers are the place where you can apply custom policy to which Exports the container will instantiate / return. You can create a custom Export Provider that filters out for example based on role, configuration, or some other mechanism. The providers can be passed in when the container is constructed. I'll be doing an upcoming series of posts on EPs which will show how to do this.


Dec 23, 2008 at 7:47 PM
@ganesh - Some of what you described was addressed by our lifetime work (we are now able to mark parts and filter catalogs so you can achieve what you're describing). Configuration per-se is not supported out of box but as Glenn pointed out, is also doable. If you share your scenario - feel free to drop us a line - we would be able to take more things in consideration for this or next versions.

Dec 23, 2008 at 9:10 PM
thanks to you both.
will wait for those examples/writeups

Thanks for that info. My thousghts, a configuration file or a mechanism that would support configuring without recompilation and deployment is what a config file can easily achieve. And a filewatcher on the config file would save a lot of deployment headaches.
Dec 31, 2008 at 1:19 PM
jeffreyschultz I have a working test for config composition running where you define parts, imports and exports as elements in a config section. I'll be making the source code available in a couple of weeks, I need to finalise the implementation and then clean up the code a bit.