Taking ownership of Unity.Mvc* and Unity.WebAPI

This post originally explained that ownership of Unity.WebApi and Unity.Mvc* was moving from DevTrends to our sister SaaS company Feedbackhound. Unfortunately, that did not work out so the projects are now back with DevTrends. We are pleased to announce a new release of Unity.WebApi and a new package for Unity.Mvc5.

Unity.WebApi and Unity.Mvc* are fairly simple libraries and once plugged in work seamlessly, which is probably why so many people have chosen to use them. There is nothing fundamentally wrong with the previous releases. They can both be used on later versions of MVC and WebAPI with the use of binding redirects but the new versions reference the latest assemblies to eliminate this requirement.


Unity.Mvc3 will remain published for use in MVC3 projects and is available on NuGet and on Codeplex. Somebody has already kindly released Unity.Mvc4 using the code on Codeplex. Unity.Mvc4 is exactly the same code as Unity.Mvc3 but references newer versions of dependencies.

We have now added Unity.Mvc5 to github and released a new NuGet package for those of you lucky enough to use the latest version of MVC. Usage is fundamentally the same but we have changed the bootstrapper to fit with newer MVC conventions (see below). The full set of changes is listed below:

To install Unity.Mvc5, type the following into the package manager console or search for Unity.Mvc5 from the GUI interface.

install-package Unity.Mvc5


Unity.WebAPI is in the process of being migrated to github. All new work will take place there and any issues should be submitted as github issues rather than codeplex. Unlike Unity.Mvc*, the Web API NuGet package has been updated rather than creating a completely separate package such as Unity.WebAPI2. This more closely aligns with the strategy employed by Microsoft with their own packages. The changes in the new release are listed below:

If you are updating from a previous Unity.WebAPI version, you will need to manually copy over your unity registrations from Bootstrapper.cs to UnityConfig.cs and then delete the Bootstrapper.cs file. New users can just add their Unity registrations directly to the new UnityConfig.cs file (in the App_Start folder).

To install Unity.WebApi, type the following into the package manager console or search for Unity.WebApi from the GUI interface.

install-package Unity.WebApi

Hooking them up

Once you have installed the NuGet package, you need to hook it up in order to get the framework to start resolving components via Unity. The old way involved calling Bootstrapper.Initialise(). For the new packages, we just change this line to UnityConfig.RegisterComponents(). This needs to be added to the Application_Start event in the global.asax file:

protected void Application_Start()
    UnityConfig.RegisterComponents();                   // <-- add this line


We have not strongly named either assembly as there seems to be a lot of debate over whether this is a good idea. Let us know for or against arguments and we can easily add it. UPDATE: The latest versions are strongly named.

We have also chosen to retain the manual hooking up via the global.asax. We could automate this via a hidden dynamic httpmodule but it is FAR clearer to see what is going on with the expicit call in global.asax and it fits in nicely with the default calls to RouteConfig and BundleConfig etc. Again, if you think this is the wrong approach, let us know.

Useful or Interesting?

If you liked the article, I would really appreciate it if you could share it with your Twitter followers.

Share on Twitter


Comments are now closed for this article.