Adding Module Dependency

Topics: Prism v4 - WPF 4
Oct 15, 2012 at 10:07 PM
Edited Oct 17, 2012 at 10:24 AM

Adding Module Dependency and addressing

The Project contains some Modules and a Domain
Here I'm using Unity DirectoryModuleCatalog.

We Need ModuleX (Entity Data) to be a dependency of Domain Module.
The first strategy I've used is Registering Modules via Directory.
Don't know whether should I change it or not:

Code :

        protected override IModuleCatalog CreateModuleCatalog()
            var moduleCatalog = new DirectoryModuleCatalog();

            string stPathStartup = Environment.CurrentDirectory; // Shell Project Dir
            string stPathModules = Directory.GetParent(stPathStartup).Parent.Parent.Parent.FullName + "\\Build\\Modules";

            moduleCatalog.ModulePath = stPathModules;
            return moduleCatalog;


Not sure but as an alternative to solve this via App.Config :

    <module assemblyFile="../Modules/Xz.Domain.dll" moduleType="Xz.Domain,Xz.Domain"
        <dependency moduleName="Xz.Data" />

Is it the only solution ?
Did I do it right ?
Yet I didn't remove the "CreateModuleCatalog".
Assembly Name and Namespace : Xz.Domain   
Project Name shown in the Solution List : Domain

Questions :
        How can I Set the Domain Module's Dependency to ModuleX ?
        And be sure the ModuleX were loaded before the Domain Module.

The Folder and Project structure is as below:

Modules > ModuleX
Domain --> The App.Xaml shown is here
The Build Folder is one Level up from these
The solution file (sln) is 3 Levels up from these

Thanks for any help.

Oct 16, 2012 at 3:59 PM
Edited Oct 16, 2012 at 4:00 PM


Based on my understanding if you want to ensure that you modules are loaded and initialized in the right order, you should define the corresponding Module Dependencies, which will depend on which approach you used to registered your modules.

In my opinion using the Registering Modules Using a Configuration File approach seems to suit best your needs, as you could define the different specific locations of each of the modules there and also the corresponding dependencies for each of the defined modules. This way similarly like in the App.Config you posted you could also define the additional modules you have with its corresponding location and dependencies.

Regarding the code you posted, one thing I found in your posted App.Config file, is that when defining the AssemblyQualifiedName for the Xz.Domain module in the moduleType  your defined only the module namespace (Xz.Domain) and you should also define the class of the module or you will receive a moduleType exception, for example this could be changed to:


On the other hand, as far as I know using the Discovering Modules in a Directory approach, will portray the limitation that your modules may have to be placed in the same folder location defined when creating the DirectoryModuleCatalog, when following this approach dependencies can be defined by using declarative attributes.

Finally the other approach provided by Prism for registering your modules, is to do this directly in code, which requires having a reference to them by the application instead of being loaded at run time.

For more information and examples about this different approaches you could check the following resources provided with Prism:

I hope you find this handy,

Agustin Adami

Oct 18, 2012 at 8:19 PM
Edited Oct 18, 2012 at 8:30 PM

Thanks for the info it could be  a good general answer on it.

I solved it earlier and my problem could be a bit different, I want to share it and get your consulting on it.

hopefully get helped.