I’ve been trying to phase out some usage of the static ServiceLocator pattern in our codebase. There are many reasons not to like this, which I won’t go into here:

1

var foo = ServiceLocator.Current.GetInstance();

In order to try and make the changes in small incremental steps, my first plan was to allow the IServiceLocator instance to be injected into classes as a dependency at construction time by Unity. This would allow me to make minimal changes; first I’d register an instance of UnityServiceLocator with the DI container, and then make a few small changes to the classes, just switching calls like the above to something like:

1

var foo = serviceLocator.GetInstance();

This gets rid of the rather horrible “static-ness” of the service locator pattern.

Once verified as working, I’d then proceed to inject the actual dependencies themselves, rather than the service locator.

However, I seem to have stumbled across some rather horrible Unity behaviour. What I’m seeing suggests that Unity treats the UnityServiceLocator (the Unity implementation of IServiceLocator) as a static singleton, even when it is configured otherwise, and this behaviour seems to be particular to UnityServiceLocator.

In the following code, I register an injection factory to create a new instance of UnityServiceLocator. I also scope it with HierarchicalLifetimeManager to give me one instance per child container:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

private static void Main(string[] args)
{
    var container = new UnityContainer();
    container.RegisterType(
        new HierarchicalLifetimeManager(),
        new InjectionFactory(
            c =>
                {
                    Console.WriteLine("InjectionFactory invoked with container: " + c.GetHashCode());
                    return new UnityServiceLocator(c);
                }));
 
    container.Resolve(); // expect to see console output here
    container.Resolve(); // don't expect to see console output here
 
    var child = container.CreateChildContainer();
    child.Resolve(); // expect to see console output here
    container.Resolve(); // don't expect to see console output here
 
    var anotherChildContainer = container.CreateChildContainer();
    anotherChildContainer.Resolve(); // expect to see console output here
    anotherChildContainer.Resolve(); // don't expect to see console output here
}

I would expect the above code to invoke the factory, create the UnityServiceLocator instance and write out console output three times, once for each container. It doesn’t – it does it once, as if I’d registered it as a singleton:

InjectionFactory invoked with container: 20903718

It gets worse:

If I now make my own class implement IServiceLocator (literally, implement the interface, add one constructor which takes IUnityContainer, and have all methods throw NotImplementedException), and swap the line

1

return new UnityServiceLocator(c);

with

1

return new MyUnityServiceLocator(c);

This starts behaving the way I’d expect:

InjectionFactory invoked with container: 20903718 
InjectionFactory invoked with container: 51746094 
InjectionFactory invoked with container: 41215084

I just cannot understand this behaviour unless Unity treats UnityServiceLocator as a special case and always makes it a singleton.

This feels like a bug to me, or possibly some undocumented special behaviour. Either way, it is nasty, and cost me a fair bit of time.

ADDENDUM:

Thanks to user Randy Levy (Enterprise Library Support Engineer) on Codeplex for explaining the reason for this behaviour. The UnityServiceLocator itself registers itself with an ExternallyControlledLifetimeManager lifetime:

public UnityServiceLocator(IUnityContainer container)
{
    this.container = container;
    container.RegisterInstance<IServiceLocator>(this, new ExternallyControlledLifetimeManager());
}

The full discussion can be found here.