Getting module instance

Oct 27, 2008 at 11:34 AM
How can I get an instance of the module, which has been initiated inside the Shell application?


Oct 28, 2008 at 2:07 PM



If you are overriding the InitializeModules() method, you could register the instance of the module and give a name to  it, so that you can get it via the Container as follows:

//Creating the module

IModule myModule = myContainer.Resolve<MyModule>();

myContainer.RegisterInstance<IModule>("MyModule", myModule);


If you are using any of the module enumerators together with the module loader, you may follow this approach registering the instance of the module inside the constructor of the module. I.e:

public MyModule(IUnityContainer container)


    container.RegisterInstance<IModule>("MyModule", this);



Then, to retrieve the right instance of the IModule class you could use the container in the following way:

//Retrieving the module

IModule myModule = myContainer.Resolve<IModule>("MyModule");


If these are not your scenario, please provide more information about it.


Hope it helps.


Ignacio Baumann Fonay

Oct 29, 2008 at 8:13 AM


Thank you very much for the explanation. I began to look at composite WPF this week and as I can see, there is much to learn. I began with the HelloWorld hands on and I wanted to send a click event from the module to the shell and close the whole application by calling Close inside the shell, but I stuck on how I can get hold on the right instance of the module. Now I’m going thru all the quick start and I’m looking into EventAggregation.

I tried your way, but some how I couldn’t get the correct container inside the shell(I think). I used the following code inside the Shell.


IUnityContainer myContainer = new UnityContainer();

IModule myModule = myContainer.Resolve<IModule>("MyModule");


But this always end up with the exception

IModule, is an interface and cannot be constructed. Are you missing a type mapping? (Strategy type Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy, index 2)”


I tried to use the module type as well with the same result. Anyway I will change my way of thinking and try to use the framework instead for passing the events.


Thank you so much for your time.


Best Regards


Oct 29, 2008 at 3:26 PM



The exception you are getting happens as you are creating a new container and, when the container tries to resolve the IModule interface, it doesn’t find any instance registered with that interface so it tries to build the interface.


If you are trying to send events between modules and shell, you should use the EventAggregator service (as you are looking into the Event Aggregation QuickStart now). Perhaps, you may find helpful the following articles:

·         How to: Create and Publish Events.

·         How to: Subscribe and Unsubscribe to Events.


If you want to perform logic behind the Shell, I recommend you to provide the Shell with a Presenter (as shown in the StockTrader Reference Implementation) or with a Presentation Model (as shown in Presentation Model with DataTemplates in CompositeWPF (Prism) Sample; this is a little more advanced topic). Then, for example, when resolving the presenter, you can get the container via the constructor, as follows:


public ShellPresenter(IShellView view, IUnityContainer container)


    View = view;

    Container = container;



public IShellView View { get; private set; }

public IUnityContainer Container { get; private set; }


NOTE: The IShellView is an interface you provide to register and get the Shell window, as shown in the StockTrader Reference Implementation.


However, you must take into account that the Shell is created before the modules are loaded, so you must find a way to notify the presenter (or the PM) when these have finished loading. One possible approach would be to override the InitializeModules() method in the Bootstrapper and, after calling base.InitializeModules(), notify the presenter:

protected override void InitializeModules()




    //notify via the EventAggregator or the interface



Moreover, if you have only one Shell window, you may retrieve it as follows:

Window mainWindow = Application.Current.MainWindow;


Please, let me know if this helps.


Ignacio Baumann Fonay

Oct 29, 2008 at 6:22 PM
Thanks a lot, and yes, it helped a great deal. I followed the quick starts and managed to create an EventService for my application. Now it is totally possible to publish and subscribe to event using EventService in both directions, Shell to Modules and Modules to Shell. I did actually used presenter and interface for Shell, which made the communication more easy to implement and understand. Thank you again for the great support.

Best Regards
Oct 20, 2011 at 7:25 AM

I know this post is already really old but I'm trying to get exactly the same, just with MEF.

I loaded a module of a specific interface (ILoginModule), which provides eventhandler-methods. After loading the module I need to register the event handler with the specific event (from the WebContext.Current.Authentication).

Trying to resolve the container in the initializeMethod() like  Container.GetExportedValue<ILoginModule>() doesn't work. But the element is surely inside the container, because I can see it by debugging the project inside the Container.Catalog.Parts-Attribute.


Any suggestions how I could reach the ILoginModule-instance in order to register the eventhandlers automatically?

Oct 20, 2011 at 12:49 PM


In my opinion, it would be better to place the logic for your component in a shared service rather than the module class itself. Module classes (those that implement the IModule interface) are usually used just to perform initialization logic for the module's components, i.e. to export views to regions and services to the container, and perhaps a little configuration stuff, but not the actual logic.

You could have for example a login service, exported to the container using an ILoginService interface as the contract type, and thus retrieved by other dependent components in the form of an import, using constructor injection, the service locator, or any other way you find most comfortable from retrieving it from the container.

You can find more about shared services in the following section from the Communication Chapter in the Prism MSDN Documentation:

Shared Services

I hope you find this helpful.

Guido Leandro Maliandi

Oct 20, 2011 at 1:21 PM
Edited Oct 20, 2011 at 1:23 PM

Thank you for your reply! :)

But I'm not sure how a service could solve the "problem"?
Maybe I should provide some more informations...

I have an Interface ILogiModule, which has for instance 2 methods:

 void LoggedIn();
 void LoggedOut();

Additionally I'm using for a Silverlight-Application the Authentication-Service from ASP.NET via WCF RIA Services.

Currently I register the eventhandler in the Initialize-Methods for each ILoginModule-implementation. For instance in the FormsLoginModule : IloginModule inside the Initialize() Method:


        public void Initialize()
            WebContext.Current.Authentication.LoggedIn += this.LoggedIn;
            WebContext.Current.Authentication.LoggedOut += this.LoggedOut;
and also the same for a WindowsLoginModule : ILoginModule.
Because I'm planing to give other developers the possibility to program against the ILoginModule-Interface would it be cool, to move this code snipped above into the bootstrapper,
so that an ILoginModule-programer could trust the application, that it calls the LoggedIn()/LoggedOut() methods without caring about when or how they are callen.
With a service I still need to register each module inside in the module to the events - either for the ASP.NET-Authentication event's (as above) or to the events of a service (like shown in your link). 
I hope I could make it a little bit more clear and that I haven't overlooked anything in your posted article, which would solve my plans better.
Oct 20, 2011 at 2:18 PM


You could place the methods and events that you're currently defining in your ILoginModule interface on a service that implements its own interface. The interface for that service could be placed on an infrastructure project, which would be then referenced throughout all your modules, and the module containing that service will only be concerned with exporting this particular implementation of that service in the container, so that other components (possibly placed in other modules that do not reference the module that defines the implementation) can consume it only knowing the interface.

To understand this, it's important to know that modules are mainly intended to group a set of functionality in the form of services and views; the IModule interface in this context is just a useful way to make sure that an Initialize method will be called as soon as the module project is loaded, so as to define a safe place to put all the initialization logic. While in theory your IModule class could contain authentication logic, it would be, in my opinion, mixing the responsibilities of your objects (as your module class would be responsible for both authenticating, and initializing miscellaneous views and services).

In your case, you could abstract the precise details of the Authentication-Service from ASP.NET that you consume through WCF Ria Services inside your service, and only expose it through an interface, so that other programmers do not need to be aware of the internals of your solution for authenticating; they will just have a notion of what it is to "log in" and to "log out" using a service retrieved from the container.

You might find the following blog post useful, which shows a possible scenario where the aforementioned approach is implemented:

Authentication and role based authorization in Prism v4 (even though the blog post shows an example using a mocked services, the idea should be the same for a real one using WCF Ria Services)

I hope you find this helpful.

Guido Leandro Maliandi