I have a host application that controls various factory classes which produce implementations of a common data contract. Also, all the factories derive from a particular factory contract. The factories may need particular implementations of the data contract to generate their own objects… so the host can generically pass data via a function in the factory contract that has one argument of the data contract type. The factories then try to cast it to the type they are interested in… ignoring it if it doesn’t match. This all works ok so far.
I wanted to extend this to allow users to create add-in factories using the .NET add-in framework, but I’m concerned about the isolation boundaries… For instance, if a factory produces an IData instance, can another factory cast objects produced by the add-in to the shared concrete implementation type? It looks like the need for adaptors in the add-in pipeline may screw this up?
For instance, in the diagram below, the concrete class DataA would be shared between PluginA and PluginB, and the concrete class DataB would be shared between PluginB and PluginC.
Edit:
So far I only knew about the System.Addin functionality for creating add-ins… and the older methods involving direct reflection. I’ve just discovered MEF, which supposedly doesn’t concern itself with the isolation boundaries that are core to the System.Addin stuff. Does anyone with experience with MEF know how this might impact my scenario?
So after some experimentation, I’ve found MEF can solve these problems. The isolation barriers created by System.Addins seem to make it impossible to retrieve the actual concrete implementation… MEF allows me to cast back discovered add-ins to their concrete types from addins that are aware of the specific implementations.