Module Dependencies Issue

Topics: Prism v4 - Silverlight 4
Jul 15, 2010 at 11:14 PM


The scenario is as follows (Silverlight 4 application, PRISM 2.2):

I have 3 modules defined in a XAML based catalog:

1) ModuleMain - set to InitializationMode=WhenAvailable

2) ModuleA - set to InitializationMode=OnDemand and depends on ModuleB and also on ModuleMain

3) ModuleB - set to InitializationMode=OnDemand also depends on ModuleMain

After the bootstrapper kicks in ModuleMain is loaded. Somewhere down the code (in ModuleMain) I load ModuleA (via the IModuleManager interface).

Now from my understanding ModuleA should not be loaded because it depends on ModuleB and ModuleB has not been loaded yet. However the call to IModuleManager.LoadModule("ModuleA") automatically loads ModuleB.

Is this the expected behavior ? Am I missing something ?



Jul 16, 2010 at 12:15 AM

That sounds like the expected behavior.  The module loader will do dependency chaining and pull in the other necessary modules.

Are you looking for a different behavior?

Michael Puleio


Jul 16, 2010 at 3:34 PM

I guess it makes sense...

I thought dependent modules in prism had a different meaning than dependencies of a DI container. 


Jul 16, 2010 at 7:13 PM

Dependencies and dependency chaining do have a slightly different meaning between modules and a DI container.

 I was being a bit terse in my reply above.  Here is the longer, more detailed explanation :

 In the situation you described above, when you ask the module manager to load moduleA a lot of things happen.  the following is from memory w/o looking at the code, but the high level ideas should be close to reality:

  • Module manager looks at moduleA and sees that it is OnDemand and has not been loaded yet
  • Module manager then looks at the dependency list for ModuleA (which points to moduleB)
  • It determines that moduleB has not been loaded and has no dependencies
  • the module manager asks the module type loader to load the ModuleB module type
  • the module type loader determines it needs to download ModuleB, and downloads it
  • The ModuleB type gets loaded
  • the module manager asks the module type loader to load the ModuleA module type
  • the module type loader determines it needs to download ModuleA, and downloads it
  • The ModuleA type gets loaded
  • Then the instances get created via DI dependency chaining.

So basically, the modularity dependency chaining ensures that all the types are available in the app domain for the DI container can do its things.  Of course, the modularity chaining is looking at the module info metadata, not the actual types involved, to determine the assemblies that need to be loaded.

I hope that helps with the confusion,

Michael Puleio

Jul 17, 2010 at 3:20 PM

Got my head straight.

Thank you for the detailed explanation !