ServiceLocator reliance : is there a danger of Container reference wipeout?

Topics: Prism v4 - WPF 4
Jan 7, 2011 at 3:09 PM

I am wondering if the following is a practical or realistic problem.

When using Prism (CAL) to build an application, it is possible and likely the component being plugged in or discovered also uses DI with a UnityContainer (or any other DI container they use).  If that component has initialization code to ServiceLocator.SetLocationProvider( () => someDelegate), wouldn't that wipeout the IServiceLocator reference used within Prism itself, or at least the calls to ServiceLocator.Current would now return an object whose container is from the plug-in component.  Thus, your references, and everything Prism set up on initialization, are no longer accessible from ServiceLocator.Current.

There are many parts of Prism source code that call ServiceLocator.Current.  This is the concern.

I'm probably missing something obvious here, but other than hoping the component is playing nicely, it seems possible to accidentally or intentionally mess up the DI container. 

Could someone explain if I am correct or not, and if I am, is there any way to protect against this?

Thank you.


Jan 7, 2011 at 4:45 PM

Hi Jason,

As you're mentioning, Prism internally uses the Service Locator in many components, so you should avoid calling ServiceLocator.SetLocationProvider in your components. You might find better support on Service Location in the Common Service Locator Codeplex forum.


Guido Leandro Maliandi

Jan 7, 2011 at 7:26 PM
Edited Jan 7, 2011 at 7:40 PM

Thanks.  I made a post there, but as it relates to prism, I wonder why prism specifically calls out to ServiceLocator.Current. 

From an older posting here --, it seems that someone else had the same concern I had, and I would have hoped the prism library would hold on to IServiceLocatorReferences rather than calling out to ServiceLocator.Current.

There are 3 or 4 classes in the prism library which call out to ServiceLocator.Current.  Either it was an oversight or it was absolutely essential. To me, it seems risky.  I do agree, calling SetLocatorProvider should be handled delicately, but it does have to be called.

I would suggest some of this code be reviewed or refactored, or if you could explain that the sections of code it is in is not risky if another container is injected, I'd be happy to know that.  I am a proponent of the library, I'm just asking for clarification on a key detail of pluggable components.

The classes I see with this reference are

Bootstrapper - this one probably has to be there.
and some extensions class.

Jan 10, 2011 at 2:29 PM

Hi Jason,

You could add this as a work item in the Issue Tracker, for it to be considered in future releases.

Thanks for your feedback,

Guido Leandro Maliandi