Using Unity.Mvc5 and Unity.WebApi together in a project

At Devtrends, we prefer to split our Web APIs and ASP.NET MVC sites into separate projects but I know that not all Unity.WebApi and Unity.Mvc5 users feel the same way. This blog post addresses use cases where people want to use both libraries together within the same project.

The problem

Both Unity.WebApi and Unity.Mvc5 contain a custom DependencyResolver - the primary mechanism for dependency injection in ASP.NET (both MVC and Web API). These resolvers are in different namespaces so there is no conflict and both can be used within the same project.

Both packages also use a UnityConfig.cs class to initialize the Unity container and register the DependencyResolver with the framework. This file is added to the App_Start folder of your project.

Unity.Mvc5 adds the following UnityConfig.cs:

using System.Web.Mvc;
using Microsoft.Practices.Unity;
using Unity.Mvc5;

namespace WebApplication1
{
    public static class UnityConfig
    {
        public static void RegisterComponents()
        {
            var container = new UnityContainer();
        
            // register all your components with the container here
            // it is NOT necessary to register your controllers

            // e.g. container.RegisterType<ITestService, TestService>();
        
            DependencyResolver.SetResolver(new UnityDependencyResolver(container));
        }
    }
}

Unity.WebAPI adds a similar file:

using Microsoft.Practices.Unity;
using System.Web.Http;
using Unity.WebApi;

namespace WebApplication1
{
    public static class UnityConfig
    {
        public static void RegisterComponents()
        {
            var container = new UnityContainer();
        
            // register all your components with the container here
            // it is NOT necessary to register your controllers
        
            // e.g. container.RegisterType<ITestService, TestService>();
        
            GlobalConfiguration.Configuration.DependencyResolver = new UnityDependencyResolver(container);
        }
    }
}

If you add both NuGet packages to the same project, you will find that the UnityConfig file will be created for the first package you install. You may be prompted to replace the existing UnityConfig file when you install the second NuGet package but this is not what we want. NuGet is not smart enough to merge these file together so some manual intervention is necessary. Nothing to worry about though - it is just a single line.

The solution

The contents of your UnityConfig file will differ depending on the install order of the Unity.WebApi and Unity.Mvc5 packages but in either case, we need to ensure that both DependencyResolvers are hooked up. To do this, simple change your UnityConfig so that it looks something like the following combined file:

using Microsoft.Practices.Unity;
using System.Web.Http;
using System.Web.Mvc;

namespace WebApplication1
{
    public static class UnityConfig
    {
        public static void RegisterComponents()
        {
            var container = new UnityContainer();
        
            // register all your components with the container here
            // it is NOT necessary to register your controllers
        
            // e.g. container.RegisterType<ITestService, TestService>();
        
            DependencyResolver.SetResolver(new Unity.Mvc5.UnityDependencyResolver(container));

            GlobalConfiguration.Configuration.DependencyResolver = new Unity.WebApi.UnityDependencyResolver(container);
        }
    }
}

As you can see, our new file includes both calls to set the custom DependencyResolver. We are also referencing each resolver using the full namespace (e.g. Unity.Mvc5.UnityDependencyResolver) rather than relying on a using statement at the top of the file.

That's all there is to it. Now your ASP.NET MVC and Web API projects will use Unity to resolve components.

Comments

Simon Parker wrote on 31 May 2023

Thank you for this. It worked like a charm. I was having an awful time trying to get Dependency Injection working on my API controllers, and the available documentation is quite sparse. This was really painless. Thanks.

Nestor CCastro wrote on 23 May 2024

Excelente aporte.
Me fue de gran ayuda.

Name Email Comment

Add Comment