Replacing the Default DI Container in Sitecore 8.2

Since Sitecore has become DI-aware, its internals have undergone significant rewiring, allowing for a more seamless implementation swapping — not only for its internal components, but even for some parts of its infrastructure.

So you already have a dependency injection container coming with Sitecore. Why would you want to substitute it with something else? Well, your reasons could be many:

I do believe that using one of the leading DI libraries will provide an overall better development experience, compared to using the default container.

If you wanted to use a Dependency Injection container with Sitecore 8.1, there was, essentially, one best way of doing that:

If you look at the Sitecore.config included with 8.2, you’ll see a new configuration node added at the very bottom:

This node references the class that will return an implementation of IServiceProvider. That service provider instance will then be used everywhere throughout the application, including Sitecore’s internal components.

Let’s make our own service provider builder using the class below.

Inheriting from Sitecore.DependencyInjection.BaseServiceProviderBuilder ensures that Sitecore's internal service configurators are utilized.

Notice the use of builder.Populate(serviceCollection)—this is an extension method included in Autofac.Extensions.DependencyInjection. It goes through all existing services (registered so far by Sitecore) and registers them in Autofac, which makes them available in your DI container. If Sitecore registers more services later on, they will be registered in Autofac through the IServiceProvider adaptor we returned from BuildServiceProvider().

And this is it! No need for custom controller factories, or chained dependency resolvers.

An attentive reader may have already noticed that we din’t even have to touch DependencyResolver.Current. This is because Sitecore's MVC dependency resolver will internally use IServiceProvider—the one we provided when we overrode the <serviceProviderBuilder>.

By the way, you can see all service registrations on a new administrative page: /sitecore/admin/ShowServicesConfig.aspx. It will list all available services — registered either by you and by Sitecore.

There’s a bonus: since we’ve completely replaced the default container, we can now use Sitecore XML configuration to register services in our DI container:

This syntax has even fewer features than IServiceProvider’s API, but still, XML configuration may work for simple cases — if that’s something you’re into.

The approach defined above is very clean and straightforward. The way in which Sitecore allows to swap its internal dependency resolution is definitely a big step forward. Your custom services, along with Sitecore’s internal services, are now easily accessible, replaceable and injectable through your DI container of choice. All with minimal code and configuration.

Related posts:

With the final few days of Hacktoberfest coming up, I’ve managed to complete a few pull requests as I was scrounging the Hacktoberfest labelled issues. I’ve ended up contributing to 3 repositories in…

I was listening to a podcast (Mastermind, Part 1: Winning the War in Your Mind) that explained it as neuro pathways that we create in our minds. Imagine walking over the same patch of grass…

I love the energy in the room. “Thank You For The Invite” is published by Tyqo.