Should I reference Microsoft.Extensions.DependencyInjection in modules I create for Sitecore 8.2+?

Question

So I'm in the process of upgrading various modules to Sitecore 8.2. Among other things this involves getting rid of IoC container project references and getting on board with the Sitecore one.

And herein lies my question.

It seems to me that if I just add a reference to Microsoft.Extensions.DependencyInjection I am really just replacing one DI reference with another one. Also; what if the main project that my module will plug into, has that container replaced - like with SimpleInjector or Unity or such?

Reading through Kam's post on DI in 8.2 it seems to me that the best approach for a module would be to use Direct Registration. Like so:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
        <services>
            <register 
                serviceType="Type.IName, Assembly" 
                implementationType="Type.Name, Assembly" 
                lifetime="Transient" />
        </services>
    </sitecore>
</configuration>

Doing it like this is agnostic towards the actual container in use; saves me a project reference to any container. Seems like a win/win. But is it?

1. When Sitecore gets reconfigured to use another container; will that container also be used to resolve these <register /> entries? (as opposed to what Kam suggests; resolve these via Reflection)

2. Am I really not saving anything because Sitecore already references Microsoft.Extensions.DependencyInjection and one more reference from a module will make no difference at all?

Answer 1

When Sitecore gets reconfigured to use another container; will that container also be used to resolve these entries?

It depends on how that other container gets configured, exactly. If you use the approach of patching the <serviceProviderBuilder>, then the container gets replaced completely and there's only one DI implementation. This would be my recommendation, as it seamlessly integrates your container into Sitecore. This way, the services that you configure with <services> –> <register> will be handled by your container of choice.

On the other hand, if you only replace the MVC dependency resolver, then there will be two containers: one used in Sitecore, and another in your application. Sure, you can manually copy all Sitecore service registrations into your container, but there will still be two containers running side-by-side.

Am I really not saving anything because Sitecore already references Microsoft.Extensions.DependencyInjection and one more reference from a module will make no difference at all?

That's how I see it as well. The assembly will be loaded into memory anyway by Sitecore, so referencing it from your modules won't make anything worse.

The decision of whether to use code or XML configuration to register your services is a matter of personal preference.

Doing it like this is agnostic towards the actual container in use; saves me a project reference to any container. Seems like a win/win. But is it?

Well, it will be agnostic to the container, but instead it will be tied to Sitecore's XML registration format, which has even fewer features than IServiceProvider. If that works for you, then by all means, go ahead with it.

Just keep in mind that this way you won't have an option to do things like mass-registration. E.g. with Autofac:

builder
    .RegisterAssemblyTypes(AppDomain.CurrentDomain.GetAssemblies())
    .Where(t =>t.GetInterfaces().Any(i => i.IsAssignableFrom(typeof(IService))))
    .AsImplementedInterfaces()
    .InstancePerLifetimeScope();