mardi 5 avril 2016

Migrating an ASP.NET Web API 2 project to ASP.NET MVC 6

If we want to migrate ASP.NET MVC 5 project to ASP.NET Core et ASP.NET MVC 6 projet  is not an easy thing.  the new platform is a profound rewrite of all that existed until now, and this has an impact on the layers and APIs we handle directly into our applications.
Historically, the migration from a version of ASP.NET MVC to an other  was quite simply (essentially by modifying the configuration of the application), you must now expect a greater technical challenge. As part of this post, I wish to focus on the specific case of Web APIs.
Indeed, with ASP.NET Core , ASP.NET Web API brick disappears and it's directly merged with ASP.NET MVC 6. Thus, all types of bases, specific namespaces and extensions to ASP.NET Web API also disappear.
To make life easier for developers facing this kind of migration scenario of an existing ASP.NET Web API  application to ASP.NET MVC 6, Microsoft has decided to distribute a NuGet Microsoft.AspNet.Mvc.WebApiCompatShim package. This is what NuGet package I propose you to discover and manipulate today.

Creating the Project

The first step is to create the file project.json that matches your application. The focus of attention here concerns the expression of dependencies: reference the Microsoft.AspNet.Mvc and Microsoft.AspNet.Mvc.WebApiCompatShim packages. You then get a file similar to the sample file below.
The second step concerns the Startup class. In most of ASP.NET MVC applications, the application starting point is managed by the file Global.asax . We'll have to remove this file and convert its contents to the Startup class. If you have already jumped the step of Owin in your application ASP.NET Web API, you might already have a Startup class. However, syntax changes all with ASP.NET and ASP.NET MVC Core 6.
Then, choose the example  of Startup class provided below. The points of attention here are the way of referencing MVC (with calls to AddMvc and UseMvc) but also referencing Web APIs Shims with AddWebApiConventions instruction.

Gestion du routage

Usually, in projects that use ASP.NET Web API, using the attribute routing is preferred to the manual input of the routing table. However, the package Microsoft.AspNet.Mvc.WebApiCompatShim does not offer full compatibility with the routing attribute as it was available in ASP.NET Web API. Thus, RoutePrefix attribute is not available, and you must convert your code to instead use the Route attribute, latter having a prefix function if you place it in a controller. Finally, the Route attribute must receive a template parameter in its constructor, even, if the template in question is empty. Again, there is a difference with ASP.NET Web API 2 that is not filled by Shims.

Migrating controllers

The next step in migrating an ASP.NET Web API project to ASP.NET MVC 6 is to take all your controllers and models and services they rely on, and add them to your project. In your controller, once modified routing attributes (following the instructions in the previous section of this post), you should have gotten a functional code for ASP.NET MVC 6. Unless your actions using the return type IHttpActionResult. This interface was not brought in Shims, you must replace the IActionResult interface, which is the standard interface of ASP.NET MVC 6.Note that if your use of ASP.NET Web API had made you choose to type your actions with a POCO or with HttpResponseMessage type, you will not encounter problems. Indeed, the last type, and all the mechanisms for generating instances of HttpResponseMessage ** are supported and available through the library ** Microsoft.AspNet.Mvc.WebApiCompatShim.
The Microsoft.AspNet.Mvc.Web Api CompatShim package introduces a new model binder to receive instances of the class HttpRequestMessage parameter of an action. Thus, the following two examples can be written.
You have the ability to easily generate instances of HttpResponseMessage. You may choose to receive the request as an action parameter like in the previous example. You may also take advantage of having your controllers derive from the shim ApiController and this exposes a Request property HttpRequestMessage kind. Thus, the example below is a validated approach for the generation of a response.
In an earlier example, I used the method Ok. Again this is a method exposed by the shim ApiController. There are many others: Created, Conflict, NotFound, etc. These methods were already present in ASP.NET Web API 2. However, the implementation of the shim ApiController is such that a call to these methods will actually return you a type compatible ASP.NET MVC 6. Attention to the type back of your actions !

Error Handling

The type HttpResponseException is also introduced by the pack of shims. Its use is exactly the same with ASP.NET Web API. The example below illustrates this scenario.
Behind the scenes, the exception will be automatically hidden by a filter who will turn it into a classic answer with the correct code and any content that you would have attached. If you have chosen to manipulate instances of HttpRequestMessage and HttpResponseMessage also know that the CreateErrorResponse extension method was raised and is distributed via the shims.

Content Negotiation

Content negotiation is well and truly present with ASP.NET MVC 6, but its implementation is not the same as that available with ASP.NET Web API. However, if your code must refer to IContentNegociatior Service, know that it is accessible with shims.
The example below can then be written and performed with ASP.NET MVC 6

Conclusion

The package Microsoft.AspNet.Mvc.WebApiCompatShim does not  the miracle by migrating automatically for you an application to ASP.NET MVC 6. It does not help you in the migration of customization that you might have made to the tunnel message processing and other levels of API Web framework (controller factory, stock selection, etc.). Nevertheless, it should allow you to be able to resume as is the code of your APIs controllers providing minimal changes to it, which should be able to quickly allow you to compile your application based on the MVC 6.
But remember it is only a compatibility pack and you should seize the first opportunity to actually migrate the code of your APIs controllers to a more consistent approach with ASP.NET MVC 6.

2 commentaires: