Untitled

Today we will see the modularity concept of Prism. Probably the best part of it, as it will allow us to build a real plug-and-play application where the main Shell won’t know anything about the modules.

Discover and load the module.

What does it mean? As we saw in the previous article, we have declared a reference in our Shell for the hello world module. In this way we force the Shell to be compiled including in the shell project a reference to the Hello World module. Fine, but what happen if we want to replace this module with a new version? We need to change the reference in the project and recompile it … Pretty ugly for a modular application doesn’t it?

The basic concept in Prism is that we can discover on fly the available modules and load them … This is the workflow process of discovering and loading a module in Prism.

 

There are different ways to load a module. As we saw in the previous article, the easiest way is to add a direct reference to the module in the Shell and load it in the bootstrapper:

  1: ModuleCatalog catalog = new ModuleCatalog()
  2:    .AddModule(typeof(HelloWorldModule.HelloWorldModule));

The second way is to add the module reference in the app.config and REMOVE the code in the bootstrapper. In this way we won’t need to recompile the module each time we will run the application in Visual Studio and we won’t need a direct reference to it. Let’s see the code below. I have a added an app.config file in my shell project:

  1: <?xml version="1.0" encoding="utf-8" ?>
  2: <configuration>
  3:   <configSections>
  4:     <section name="modules"
  5:              type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  6:   </configSections>
  7:   <modules>
  8:     <module 
  9:       assemblyFile="Modules/HelloWorldModule.dll" 
 10:       moduleType="HelloWorldModule.HelloWorldModule, HelloWorldModule" 
 11:       moduleName="HelloWorldModule"/>
 12:   </modules>
 13: </configuration>

I am using the composite section in the app.config file to load a specific module. Now, in order to make this ‘runnable’ we need to:

  • remove the reference in the Shell project
  • clean-up the code in the bootstrapper that loads the module

The shell project will use this code now to load the Module catalog:

  1: ModuleCatalog catalog = new ConfigurationModuleCatalog();

As you can see we are telling to Prism to look in the app.config and load the modules available there. In order to make the module available in the modules folder inside the bin folder of the shell you can play with MSBuild or a post-event action in VS. I copied this code from MSDN and added to the post event build action in the HelloWorldModule project properties:

  1: xcopy "$(TargetDir)*.*" 
  2: "$(SolutionDir)Shellbin$(ConfigurationName)Modules" /Y

Leave a comment

Your email address will not be published. Required fields are marked *