Is SetLocatorProvider a risk in multi-component applications that depend on DI?

Jan 7, 2011 at 4:20 PM
Edited Jan 7, 2011 at 6:07 PM

I was redirected to this forum from my post below <Link from Prism Forum>

I am wondering about the potential danger of other developers calling SetLocatorProvider after a main container is already established.

The context I am pondering relates to Prism, but it seems to apply to the general ServiceLocator pattern as I was recommended. 

The jist of the question is: should you rely on other developers playing nicely in their code and hope they don't call "ServiceLocator.SetLocatorProvider" in their code while they use Dependency Injection,  or is there a way to prevent something like that from happening.  In the context of Prism, which relies on calls to ServiceLocator.Current, you can imagine the effects if someone "redirected" the service locator by accident or ignorance.

If there's a common way to deal with this, or a way such that other components can use DI and ServiceLocator without messing up the app domain application's static ServiceLocator.Current, I'd like to know.  If there is no solution, I'd like to know that as well.  The problem stems from multiple components all wishing to use the DI/ServiceLocator pattern and how to deal with the singleton instance of ServiceLocator with different implementations / registrations, amongst those components.  Thank you.