I divided my problem into a short and a long version for the people with little time at hand.
Short version:
I need some architecture for a system with provider and consumer plugins. Providers should implement interface IProvider and consumers should implement IConsumer. The executing application should only be aware of IProvider and IConsumer. A consumer implementation can ask the executing assembly (using a ServiceProcessor) which providers implement InterfaceX and gets a List back. These IProvider objects should be cast to InterfaceX (in the consumer) to be able to hook the consumer onto some events InterfaceX defines. This will fail because the executing assembly somehow doesn't know this InterfaceX type (cast fails). The solution would be to include InterfaceX into some assembly that both the plugins and the executing assembly reference, but this should mean a recompile for every new provider/consumer pair and is highly undesirable.
Any suggestions?
Long version:
I'm developing some sort of generic service that will use plugins to achieve a higher level of re-usability. The service consists of some sort of Observer pattern implementation using Providers and Consumers. Both providers and Consumers should be plugins for the main application. First, let me explain how the service works by listing the projects I have in my solution.
Project A: A Windows Service project for hosting all plugins and basic functionality. A TestGUI Windows Forms project is used for easier debugging. An instance of the ServiceProcessor class from Project B is doing the plugin-related stuff. The subfolders "Consumers" and "Providers" of this project contain subfolders where every subfolder holds a consumer or provider plugin assembly respectively.
Project B: A Class library holding the ServiceProcessor class (that does all plugin loading and dispatching between plugins, etc), IConsumer, and IProvider.
Project C