FeedbackHound Blog The latest news about feedbackhound.com

Follow FeedbackHound Twitter Facebook Google+ RSS Feed

Taking ownership of Unity.Mvc* and Unity.WebAPI

Taking ownership of Unity.Mvc* and Unity.WebAPI

We are pleased to announce that we have taken ownership of the popular Unity.Mvc* and Unity.WebAPI projects. At FeedbackHound, we use both these libraries in multiple applications so we are very grateful be able to take control and maintain the projects going forward.

Both libraries are fairly simple 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 all be used on later versions of MVC and WebAPI with the use of binding redirects but now that we have control, we have decided to release new versions that reference the latest assemblies and eliminate the use of binding redirects.

Unity.Mvc5

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. We have 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:

  • Updated project to .NET 4.5.
  • Updated Unity reference to version 3.
  • Updated to ASP.NET MVC reference to MVC5.
  • Changed readme.txt incusion so it only gets displayed rather than adding it to actual project.
  • Changed Bootstrapper.cs added to root into UnityConfig.cs added to App_Start.

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

Unity.WebAPI is in the process of being migrated to github. All new work will take place there and any issues should be submitted on github. 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:

  • Updated project to .NET 4.5.
  • Updated Unity reference to version 3.
  • Updated to ASP.NET Web API reference to Web API 2.
  • Changed readme.txt incusion so it only gets displayed rather than adding it to the actual project.
  • Changed Bootstrapper.cs added to root into UnityConfig.cs added to App_Start.

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 it 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
   RouteConfig.RegisterRoutes(RouteTable.Routes);
   BundleConfig.RegisterBundles(BundleTable.Bundles);
   ...
 }

Feedback

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.

Published

Sharing & Feedback

Twitter Facebook Google+ Sharing This Post

If you found this article useful, please share it with your friends and followers. We would also appreciate your feedback. If you are responding to the article, please use Twitter. For more general feedback including questions, suggestions and bug reports, please use our feedback site.