Exporting types from a 3rd party assembly

Sep 17, 2009 at 11:14 PM

I need to import all types implementing certain interface from an assembly. How can I do this without modifying this assembly? I do not have the luxury of decorating every one of these types with the export attribute, so I was wondering what would be the kosher way to export it 'externally' - without touching the original assembly

Sep 17, 2009 at 11:25 PM

If you own the interface, you can put an Export attribute on the interface.

If you don't own the interface, you will need to use a custom programming model (implementation of ComposablePartCatalog). MEFContrib can very likely help you out too.

Nick

Sep 18, 2009 at 12:12 AM

MEF Contrib would be a good source. Alternatively you can consider the approach I outlined here: http://codebetter.com/blogs/glenn.block/archive/2009/04/27/poco-mef-and-custom-type-systems-are-you-ready-to-take-the-red-pill.aspx, though proceed with caution ;-)

Sep 19, 2009 at 3:19 PM

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?

Sep 19, 2009 at 3:27 PM
nblumhardt wrote:

If you own the interface, you can put an Export attribute on the interface.

If you don't own the interface, you will need to use a custom programming model (implementation of ComposablePartCatalog). MEFContrib can very likely help you out too.

Nick

 On the first pass I completely missed your suggestion - decorate the interface rather than the classes implementing it. I will have to think more about it