I've been working with web services recently, and I keep copying the same stuff to set up Unity for dependency injection, so I thought I'd extract the common stuff into a library. Here's the main class:public static class UnityConfig{    public static IUnityContainer Register(System.Web.Http.HttpConfiguration config, params Action<IUnityContainer>[] registrations)    {        // Defensive programming        if (config == null) throw new ArgumentNullException(nameof(config));        // Set up Unity dependency injection.        var container = new UnityContainer();        foreach (var register in registrations) register(container);        // Switch some of the plumbing to our new Unity setup.        System.Web.Mvc.DependencyResolver.SetResolver(new Microsoft.Practices.Unity.Mvc.UnityDependencyResolver(container));        config.DependencyResolver = new Microsoft.Practices.Unity.WebApi.UnityDependencyResolver(container);        Microsoft.Practices.ServiceLocation.ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(container));        // Grease Web API's inner workings with Unity.        var formatters = config.Formatters.ToList();        config.Formatters.Clear();        foreach (var formatter in formatters) config.Formatters.Add(new UnityFormatter(formatter, container));        config.Services.Insert(typeof(System.Web.Http.ModelBinding.ModelBinderProvider), 0, new UnityModelBinderProvider());        // Send back the container in case of unforeseen needs.        return container;    }}The UnityFormatter and UnityModelBinderProvider classes are custom so it is fine to assume they work.My first concern is the plumbing section. Here we integrate Unity into MVC, Web API, and Microsoft's service locator. The MVC and service locator parts, in particular, add dependencies to my library and there are no guarantee consumers would need the functionality. Should I try to avoid the potentially unused dependencies? Or is it not worth the worry?My second concern is returning the container. I feel like I'd be denying a potential use case by not returning the container and making it a void function (though void is typical in similar configs). On the other hand, I'm exposing another implementation detail and the consumer should have plenty of room to set things up with the registrations parameterMy third concern is using params. Is that just an overkill? One should suffice for all the situations I'm familiar with but does that mean I should be restrictive now?The bullet points highlight my main concerns but please feel free to comment on other things you think could be improved apart from (the lacking) documentation.
Simple Unity Integration
c#;dependency injection;unity