Let’s say I have a class (not a static class), A, that in some way uses plugins. I use MEF to manage those plugins, and add methods for my users to add parts catalogs. Example usage:
var myA = new A();
myA.LoadPlugins(new DirectoryCatalog("path/to/plugins"));
myA.DoStuffWithPlugins();
In the same namespace as A is class B. B also uses MEF to manage plugins, and has its own CompositionContainer. If a user wants to interact with B‘s plugins, she must use B‘s plugin management methods.
B is used just like A is, above.
My question is, is this bad? Should I care that there are two separate places to load plugins in my namespace? If it is bad, what are the alternatives?
Not necessarily. There is no reason you can’t have two completely separate compositions within the same application.
That being said, there’s also no real reason, in most cases, to have more than a single composition. MEF will compose both sets of data at once. In your case, you could compose your importers and your reports with the same composition container, which would have the advantage of allowing somebody who is extending your system to only create a single assembly which extends both portions of your application.
One potential minor red flag here is that these are two separate types within the same namespace, but each of which have their own plugin system. Typically, a framework with a full plugin system is going to be complex enough that I’d question whether they belong in the same namespace – though from going by type names of “A” and “B” it’s impossible to know whether this is truly inappropriate.