Well, it's not THAT bad yet. :) But I do have questions after Reed has pointed me at MEF as a potential alternative to IoC (and so far it does look pretty good).
Consider the following model:
As you can see, I have an App, and this app uses Plugins (whoops, missed that association!). Both the App and Plugins require usage of an object of type CandySettings, which is found in yet another assembly.
I first tried to use the ComposeParts method in MEF, but the only way I could get this to work was to do something like this in the plugin code.
var container = new CompositionContainer();
container.ComposeParts(this, new CandySettings());
But this doesn't make any sense, because why would I want to create the instance of CandySettings in the plugin? It should be in the App. But if I put it in the App code, then the Plugin doesn't magically figure out how to get at ICandySettings, even though I am using [Import] in the plugin, and [Export] in CandySettings.
The way I did it was to use MEF's DirectoryCatalog, because this allows the plugin, when constructed, to scan all of the assemblies in the current folder and automagically import everything that is marked with the [Import] attribute. So it looks like this, and potentially in every plugin:
var catalog = new DirectoryCatalog( ".");
var container = new CompositionContainer( catalog);
container.ComposeParts( this);
This totally works great, but I can't help but think that this is not how MEF was intended to be used?
