Module loading error (Unable to locate the module with type ...)

Topics: Prism v4 - Silverlight 4
Feb 23, 2011 at 3:19 PM
Edited Feb 23, 2011 at 3:20 PM


In the early age of Prism I remember that if we didn't specify the correct version, culture and token of the module type in the module catalog it wasn't working.

Now, I can remove the version and the other part and it is working perfectly.


Did someone change the behvior in the last release?




Adrien Pellegrini.

Feb 23, 2011 at 5:49 PM

Hi Adrien,

I have tested both RemoteModuleLoading QuickStart from Prism v2.2 and the Prism Modularity QuickStarts from Prism v4 by modifying the ModuleType from the Modularity:ModuleInfo element in the ModulesCatalog.xaml file.

In Prism v2, you need to specify the Version in ModuleType for each ModuleInfo, but there is no need for PublicKeyToken and Culture.

On the other hand, Prism v4, you need to specify Version, Culture and PublicKeyToken in ModuleInfo.

However, it could be possible that you are referring ModuleCatalogBuilder class, which has been replaced with the ModuleCatalog class, for loading modules from xaml files.

Additionally, you can read more about modularity in Prism here.


Miguel Bronzovic

Feb 24, 2011 at 4:59 AM
I got the modules to load correctly when I recompiled the modules and readded them to the main project.

From: [email removed]
To: [email removed]
Date: Wed, 23 Feb 2011 08:19:28 -0800
Subject: Module loading [CompositeWPF:247248]

From: apellegrini
In the early age of Prism I remember that if we didn't specify the correct version, culture in the module type in the module catalog and token it wasn't working.
Now, I can remove the version and the other part and it is working perfectly.

Did someone change the behvior in the last release?

Adrien Pellegrini.
Read the full discussion online.
To add a post to this discussion, reply to this email (
To start a new discussion for this project, email
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at
Feb 24, 2011 at 6:18 AM

My application is working perfectly since the beginning of Prism. It is not an issue with module loading or something else. In both cases (with or without the version etc.) it works well.


I'm not using any custom code for this test (no custom ModuleInitializer, not custom ModuleManager, etc) and neither the ModuleCatalogBuilder. But I can remove the version and others parts without any troubles and change the version of the assembly as well.

This behavior is not what I want and I do not know why I have it. Could you please help me to debug this? (I will not be able to give a sample application of course...)

Feb 25, 2011 at 10:21 AM
Edited Feb 25, 2011 at 12:23 PM

Ok I find some issue with the code.

I'm using MEF and not Unity. It seems that MEF is not aware of the version of the file and need only the moduleName to work. If I remove the moduleName I got the error "Unable to locate the module with type ...". (I signed my assembly and add the full moduleType line).

I got the same behavior in the Modularity with MEF Quickstart - SIlverlight.

Is MEF really don't care of the version?

Feb 25, 2011 at 2:17 PM


We’ve conducted some research and reached to the same results as yours. We’ve found that the difference is in the MefModuleInitializer class (which overrides some methods from the ModuleInitializer class), specifically in the CreateModule method.

The ModuleInitializer.CreateModule method obtains the IModule by calling ServiceLocator.GetInstance, passing the module’s type as a parameter. Since Unity is able to resolve a type even if it’s not registered in the container, this works when Unity is used as the dependency injection container. To illustrate this:

 protected virtual IModule CreateModule(string typeName)
      Type moduleType = Type.GetType(typeName);
      if (moduleType == null)
         throw new ModuleInitializeException(string.Format(CultureInfo.CurrentCulture, Properties.Resources.FailedToGetType, typeName));
      return (IModule)this.serviceLocator.GetInstance(moduleType);

The MefModuleInitializer.CreateModule, on the other hand, relies on the ModuleExport attribute. The MefModuleInitializer class holds a field of type IEnumerable<Lazy<IModule, IModuleExport>>, and the aforementioned method queries it to find the IModule that has the same name as the ModuleInfo provided. Therefore, there is no need to specify the type of the IModule in the ModuleInfo in order for the CreateModule method to obtain the IModule. To illustrate this:

protected override IModule CreateModule(ModuleInfo moduleInfo)
     // If there is a catalog that needs to be integrated with the AggregateCatalog as part of initialization, I add it to the container's catalog.
    ComposablePartCatalog partCatalog;
    if (this.downloadedPartCatalogs.TryGet(moduleInfo, out partCatalog))
        if (!this.aggregateCatalog.Catalogs.Contains(partCatalog))
     if (this.ImportedModules != null && this.ImportedModules.Count() != 0)
         Lazy<IModule, IModuleExport> lazyModule =
                   this.ImportedModules.FirstOrDefault(x => (x.Metadata.ModuleName == moduleInfo.ModuleName));
         if (lazyModule != null)
              return lazyModule.Value;
           // This does not fall back to the base implementation because the type must be in the MEF container and not just in the application domain.
           throw new ModuleInitializeException(
               string.Format(CultureInfo.CurrentCulture, Properties.Resources.FailedToGetType, moduleInfo.ModuleType));

For more information on how MEF catalogs work, you might find better support in MEF´s Codeplex forum and also in MSDN forum.

I hope you find this information useful.


Miguel Bronzovic


Feb 25, 2011 at 9:15 PM
Edited Feb 25, 2011 at 9:15 PM

Finally, I updated my custom module initializer and add this simple line of code:


Type type = Type.GetType(moduleInfo.ModuleType, false, true);


If the module version is not the same as the assembly version, the type will be null. After we can check it and throw our exception if we want this behavior.


Thanks for answers.


Feb 28, 2011 at 1:44 PM

Hi Adrien,

Thank you for sharing your insight with the rest of the community, as other users might find your approach useful in case they face similar concerns.

Guido Leandro Maliandi