Based on my understanding when using the "Discovering modules in a directory" approach, you should not require the dependent
dlls of the modules to be in the same directory as your shell application.
For example, I tried to reproduce the scenario you mentioned using the
ModularityWithMef Quickstart as a starting point. Then I added a reference to a custom library to each of the modules discovered by inspecting a directory (Module B and
Module D). Also I override the ConfigureAggregateCatalog method to register the directories like in the following code snippet:
protected override void ConfigureAggregateCatalog()
DirectoryCatalog catalog1 = new DirectoryCatalog("D:\\ModuleB");
DirectoryCatalog catalog2 = new DirectoryCatalog("D:\\ModuleD");
Note that I placed each module in a different directory, in my case I used absolute paths but this can also be done using relative paths.
After rebuilding the solution, I ensure that each module folder also contained the corresponding referenced assemblies for each module.
This way I could run the application without having the module dependent
dlls in the shell application directory.
Perhaps in your case one of those dlls is also being referenced by your shell project.
Please let us know if we have misunderstood your scenario,