Partager via

Using the Configuration Module Enumerator

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Prerequisites

This topic assumes that you have a solution based on the Composite Application Library with a module:

Steps

The following procedure describes how to set up dynamic module loading using the configuration module loading mechanism (you do this only once).

To set up the configuration module loading mechanism

  1. If your Shell project does not contain an application configuration file, add a new one.

  2. In the application configuration file of the Shell project define a new configuration section named modules as shown in the following code (you do this only once).

    <configSections>
  <section name="modules" type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
</configSections>
<modules>
</modules>

  3. Update the Bootstrapper class of your application to load and initialize modules with the ConfigurationModuleEnumerator class. To do this, you typically override the Bootstrapper class’ GetModuleEnumerator template method. In this method, perform the following tasks:

    • Create a new instance of the ConfigurationStore class. This class is responsible for retrieving a valid instance of the modules configuration section from a configuration file.
    • Create a new instance of the ConfigurationModuleEnumerator class passing the ConfigurationStore instance in the constructor parameter. This class is responsible for reading the configuration for modules from a modules configuration section.
    • Return the ConfigurationModuleEnumerator instance. By returning the instance, the base class will register it with the Unity container.

    The following code, extracted from the Dynamic Modularity (Configuration) QuickStart, shows the overridden method GetModuleEnumerator. This method is invoked when the application starts and demonstrates how to set up the ConfigurationModuleEnumerator module enumerator.

    protected override IModuleEnumerator GetModuleEnumerator()
{
    ConfigurationStore store = new ConfigurationStore();
    return new ConfigurationModuleEnumerator(store);
}

    Note

    Module retrieval and module initialization is automatically handled by the bootstrapper's InitializeModules base method. When customization is needed, the InitializeModules method can be overridden to adjust it to your needs.

The following procedure describes how to configure a module to be loaded with the configuration module loading mechanism.

To configure a module to be loaded with the configuration module loading mechanism

  1. (Optional) Add a post-build event to the module's project to copy the module's assembly to a common folder for module assemblies (a common folder for modules is recommended to simplify the deployment of the application). To do this, open the properties for the module's project, go to the Build Events tab, and then insert a command in Post-build event command line text box. You can use a command similar to the following, which was extracted from the Configuration Modularity QuickStart.

    xcopy "$(TargetDir)*.*" "$(SolutionDir)ConfigurationModularity\bin\$(ConfigurationName)\Modules\" /Y

  2. Open the application configuration file of the Shell project.

  3. Within the modules configuration section, define your module. To do this, add a module XML element. This element has the following attributes:

    • assemblyFile. This attribute specifies the location of the module's assembly. This attribute is required.
    • moduleType. This attribute specifies the type within the module's assembly that implements the IModule interface. This attribute is required.
    • moduleName. This attribute specifies the module's name. This attribute is required.
    • startupLoaded. This attribute specifies whether the module is loaded at startup. If its value is true (this is the default value), the module should be loaded at startup. If its value is false, the module should not be loaded at startup; instead, it should be loaded on demand. This attribute is not required.

    To specify module dependencies, add a dependencies child node to the module element. In this node, add a dependency element with a moduleName property for each module that the module depends on.

    The following code shows the configuration file of the Dynamic Modularity (Configuration) QuickStart.

    <?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules" type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  </configSections>
  <modules>
    <module assemblyFile="Modules/ModuleD.dll" moduleType="ModuleD.ModuleD" moduleName="ModuleD">
      <dependencies>
        <dependency moduleName="ModuleB"/>
      </dependencies>
    </module>
    <module assemblyFile="Modules/ModuleB.dll" moduleType="ModuleB.ModuleB" moduleName="ModuleB"/>
    <module assemblyFile="Modules/ModuleA.dll" moduleType="ModuleA.ModuleA" moduleName="ModuleA">
      <dependencies>
        <dependency moduleName="ModuleD"/>
      </dependencies>
    </module>
    <module assemblyFile="Modules/ModuleC.dll" moduleType="ModuleC.ModuleC" moduleName="ModuleC" startupLoaded="false"/>
  </modules>
</configuration>

Outcome

Your module gets loaded when the application starts.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.