Geeks With Blogs
Jeff Ferguson Irritating other people since 1967

This code won’t work in a Prism bootstrapper:

   1:  protected override IModuleCatalog GetModuleCatalog()
   2:  {
   3:      ModuleCatalog NewModuleCatalog = new ModuleCatalog();
   4:      NewModuleCatalog.AddModule(typeof(JeffFerguson.Narrative.Wpf.Units.Module));
   5:      NewModuleCatalog.AddModule(typeof(JeffFerguson.Narrative.Wpf.XbrlDocumentLoader.Module));
   6:      return NewModuleCatalog;
   7:  }

If you run code like this, Prism will throw an exception of type DuplicateModuleException with a message that reads “A duplicated module with name Module has been found by the loader.”.

The issue is that Prism uses module names to distinguish one module for another, and, by default, the class name is used as the module name when a module name is not specified. Since, according to Prism (and much to my chagrin), only the tail end of the class name is used when constructing module names, there are, according to Prism, two classes named Module in the code snippet above.

Fortunately, this is all easily fixed through the use of a ModuleInfo object, where all of the information about a module can be specified and added to a module catalog as a unit. My bootstrapper code looks (in part) like this:

   1:  protected override IModuleCatalog GetModuleCatalog()
   2:  {
   3:      ModuleCatalog NewModuleCatalog = new ModuleCatalog();
   4:      AddModuleToCatalog(typeof(JeffFerguson.Narrative.Wpf.Units.Module), NewModuleCatalog);
   5:      AddModuleToCatalog(typeof(JeffFerguson.Narrative.Wpf.XbrlDocumentLoader.Module), NewModuleCatalog);
   6:      return NewModuleCatalog;
   7:  }
   9:  private void AddModuleToCatalog(Type ModuleType, ModuleCatalog Catalog)
  10:  {
  11:      ModuleInfo NewModuleInfo = new ModuleInfo();
  12:      NewModuleInfo.ModuleName = ModuleType.AssemblyQualifiedName;
  13:      NewModuleInfo.ModuleType = ModuleType.AssemblyQualifiedName;
  14:      Catalog.AddModule(NewModuleInfo);
  15:  }

This code simply uses the module type’s assembly qualified name, which will be unique throughout the application, as the name of the module.

My rant here is that I believe Prism should be using the value of the module type’s AssemblyQualifiedName property, and not just the Name property, by default as the module’s name. The two types in the original example are uniquely named, since the class’ namespace forms a part of its fully qualified name. If I had to name my two Module classes with unique tail names (like “UnitsModule” and “XbrlDocumentLoaderModule”, for example), then I wouldn’t have much need for a unique namespace.

OK. Rant over.

Posted on Sunday, July 12, 2009 10:15 PM | Back to top

Comments on this post: Prism and Unique Module Names

# re: Prism and Unique Module Names
Requesting Gravatar...
Yeah, that is kind of dumb. Why not just take the entire fully qualified class name? That's how you load up assemblies when you do Assembly.Load.

I'm doing something pretty cool with Prism: (First, let me say that we are using a module to mean an entire application, not a part of a screen.)

Anyway, you log in and are returned a list of module info objects. These are compared to the dlls you have on your hard-drive and if you are missing one, or if one is out of date, it calls a WCF method and downloads the newest version.

Then, I have a App selection screen which goes through the module data objects and using reflection, gets the IModule type out of the assembly and adds it to the ModuleCatalog. This way, you can have a shell which doesn't have ANY reference to the modules it loads, but you display them to the end user and they pick which one they are going to use.

Pretty sneaky.
Left by Jeffrey T. Whitney on Jul 18, 2009 10:12 AM

# re: Prism and Unique Module Names
Requesting Gravatar...
I like it, Jeff!

I especially like the design that alleviates the need for a strong reference to the modules from the shell. Some of Microsoft's video discussions of Prism install explicit module references into the shell. It's the easiest thing to do from a demo perspective, but it doesn't promote the idea of decoupling that Prism puts forth. Unfortunately, many developers take demo code and run with it, without thinking of a better way. Perhaps I should put up a blog post about using reflection to load Prism modules.

Thanks for reading!
Left by Jeff Ferguson on Jul 18, 2009 10:25 AM

Your comment:
 (will show your gravatar)

Copyright © Jeff Ferguson | Powered by: