Well, I spent some time digging and it seems to me that all I need here is plain ol' reflection. As exciting and interesting all of these approaches are - they do not buy much in my specific situation.
I am building NDjango rendering engine. It is extensible - you can add your own tags and filters. Tags and filters are implemented as classes implementing their respective interfaces - ITag and ISimpleFilter. When the
engine instance is initialized all 3rd party filters and tags have to be registered. There are at least 2 scenarios of how it is supposed to be done. The first one: initialization code manually feeds the tags/classes to the engine. This scenario
gives of the engine user full control on what tags will be registered with what instance of the engine.
The second one - automatic tags/filter discovery. This scenario is for easy integration of various 3rd part tag/filter libraries. The behavior I would like to see is for the engine to scan the directory of the engine dll for dlls with the names ending in
NDjangoExtension.dll. All such dlls should then be scanned for tag/filter classes.
The way it is implemented now is that the engine implements a series of "with" methods (withFilter(s), withTag(s) and expects some external entity to call them to do the registration. I was considering replacing it with some dependency injection
mechanism - like StructureMap or MEF. The problem here is choosing which one. I already wrote an ASP.MVC integration project which uses StructureMap. A week later I received a question: "what shlould I do? I do not use StructureMap, I use NInject".
What I am looking for here is a solution wich does not introduce a dependency on anything which is not a part of core .Net. Even though MEF is supposed to become a part of .Net 4.0, but it is not released yet and even when it will be I do not want to
limit my user base to those brave hearts who will jump on it right a way. Also it seems that even if I would take MEF as my solution, I still need to do majority of the work myself - directory scanning, assembly scanning, building type proxies (Glenn,
great idea BTW. I knew the Type type is abstract, I played with it a bit, but it never occured to me to use it this way).
So where does it leave me? Reflection? What do you guys think?