Aug 5, 2011 at 6:46 PM
Edited Aug 5, 2011 at 6:49 PM
I'll answer your concerns by parts:
1. By design, the load order of the modules that are marked to be loaded when available (such as the modules in the Stock Trader Reference Implementation) should not influence the functionality exposed by them. Therefore, while the order in which their assemblies
are added to the aggregate catalog is the one specified in that method, you should not rely on that for the design of your application, and it's not guaranteed that it will be the order in which the initialization of your modules is performed.
2. In the ConfigureAggregateCatalog method inside the
StockTraderRIBootstrapper, AssemblyCatalogs are added to the
AggregateCatalog, which are formed by Assemblies
(that is, instances of the System.Reflection.Assembly class). In order to obtain a reference to that class, you need to refer to the
Assembly property of the type of a class that belongs to that assembly. Therefore, since the
StockTraderRICommands class belongs to the StockTraderRI.Infrastructure project, the expression
will return the System.Reflection.Assembly corresponding to the StockTraderRI.Infrastructure project.
3. The container internally controls the order of the exports that other exports need as dependencies, so as long as you decorate the necessary parts with the
Export attribute, and you don't have circular references, the parts (such as shared services) are likely to be imported correctly.
4. As explained in the second answer, adding the assembly that contains the MarketModule (which is done through obtaining the
System.Reflection.Assembly associated to any of the elements of that assembly, in this case the empty
MarketModule class) makes all the views and services declared in that assembly to be exported into the MEF container. Therefore, even though no initialization logic is needed (and thus, the
MarketModule class is left empty), you need to add that assembly to the aggregate catalog.
I hope you find this helpful.
Guido Leandro Maliandi