Use of PRISM with Silverlight Application Execution Services (AES)

Topics: Prism v4 - Silverlight 4
Dec 9, 2010 at 10:05 AM

Until now I've used Silverlight Application Execution Services (AES) for any client-side services (eg Logging, Dialog Management) with MEF metadata for modularity and region placement. I'm now moving into an environment where use of PRISM is mandated.

Unfortunately PRISM makes no mention at all of AES.

I like the AES approach of service configuration through App.xaml but PRISM seems to preclude use of these. It relies on the bootstrapper class to do two different things (a) initialise the container needed to support direct injection and (b) set the root visual. An AES needs (a) to have been done (so concrete service implementations it wraps can be injected) but (b) to not have been done (because services start up before the Application_Startup code executes.   

I thought that maybe an AES could create the container such that the bootstrapper ConfigureContainer method could somehow retrieve that container that an already-running AES has initialized rather than call base.ConfigureContainer, but I suspect this will break the underlying PRISM code which assumes it has created the container and has complete control of it.

Should I just give up on the idea of using Silverlight AES with PRISM? Was it deliberately avoided from the documentation because there was a realisation the two wouldn't play well together?

Dec 9, 2010 at 5:17 PM
Edited Dec 9, 2010 at 5:17 PM


There is no guidance on Prism regarding the services that you are mentioning, nor there are any known issues about them.

In case you need to use those kind of services, you should make some changes to your application's bootstrapper. The approach you are mentioning seems valid, but you should take into account that the ConfigureContainer method in the MefBootstrapper registers some core services that could be needed throughout your Prism application. You can find more information about this in this chapter from the Prism MSDN documentation, under the section "Creating and Configuring the Container in the MefBootstrapper".

I hope you find this helpful.

Guido Leandro Maliandi

Dec 13, 2010 at 4:27 PM

Thanks Guido.

Since AES services start up before the Application "Startup" event which is where the bootstrapper is started (and the Unity container configured) I think using them with PRISM is likely to create more problems than it solves. You can see part of the sort of issues likely to arise with the PRISM logger used in the MVVM "Modularity Quickstart" where the Bootstrapper needs a concrete instance of the CallbackLogger class before the ConfigureContainer method is called and any IoC container is available. The ConfigureContainer method in that quickstart has to use Resolve with the specific instance that has already been created rather than use RegisterType because of the timings of the bootstrapper.

I am going to use just one AES - an "ApplicationConfigurationManager" whose sole job is to keep the App.xaml.cs code clean in making run-time parameters globally available. So for logging (which in the quickstart is "all or nothing" which is not granular enough in my view) a TraceLevel=xxxxx querystring/initParams parameter is "read" by the ApplicationConfigurationManager and used to control the level of logging that takes place client-side and also to instantiate either an EmptyLogger (if TraceLevel=None or unspecified) or a CallbackLogger (for any other value) in the container that resolves IMyLogger to the appropriate class. The ApplicationConfigurationManager "TraceLevel" parameter can also be used to determine if the Shell needs to "on demand" load a "LogViewer" module that displays all captured log entries to the requested level so I think this is a nice use of AES with PRISM. Any other services should just use the PRISM container.


Dec 13, 2010 at 6:02 PM

Hi Ian,

Thank you for sharing your insights with the rest of the community, as you might help users experiencing a similar scenario.

Guido Leandro Maliandi