Modules Loaded on Demand Preventing Application Exit?

I'm evaluating Composite WPF by developing a test application. I would like to load some modules on demand, from a module catalog populated by a configuration file. However after implementing this behavior, my application does not exit. When I close the
main window, the window disappears, but the application is still running (Visual Studio is still in debugging mode).

I was able to reproduce the error you mention (Thanks for posting the code) and found the issue.

The problem is in the following code (theline in bold and commented):

protectedoverridevoid InitializeModules()

{

base.InitializeModules();

Shell shell =
this.Container.Resolve<Shell>();
// This line creates a new instance of the shell

IModuleManager module_manager = Container.Resolve<ModuleManager>();

shell.InitializeModules(module_manager);

return;

}

As you are creating a new instance of the shell (but not showing it), when you close the visible instance of the shell, the application
keeps running.

Workarround

A possible and simple workaround is not to use the shell in the
InitializeModules method moving the Shell.InitializeModules method to the
Bootstrapper as follows:

publicclassBootstrapper :
UnityBootstrapper

{

protectedoverride DependencyObject CreateShell()

{

...

}

protectedoverride IModuleCatalog GetModuleCatalog()

{

...

}

protectedoverridevoid InitializeModules()

{

base.InitializeModules();

//Shell shell = this.Container.Resolve<Shell>(); // This line creates a new instance of the shell

IModuleManager module_manager = Container.Resolve<ModuleManager>();

this.InitializeModules(module_manager);

return;

}

publicvoid InitializeModules(IModuleManager moduleManager)

{

moduleManager.LoadModule("BModule");

moduleManager.LoadModule("AModule");

return;

}

}

If your scenario forces you to
load the modules in the
Shell class, you can both:

1.Keep a reference to the shell created in the
CreateShell Method as a private filed in the bootstrapper.

2.Register the shell as Singleton in the container (this is good only if need to access the shell instance from several places, if not the first option is better).
You might check How to: Register and Use Services