mercredi 20 avril 2016

ASP.NET Core on a Linux environment




I will explain  some things related to use of ASP.NET Core Linux,  for the development of a project (environment setup) and for the deployment of an application. This article is based on the version  RC1 of ASP.NET Core tools,  given that APIs, including utilities in command lines can change in the last releases.  We will use Ubuntu 14.04 which is Linux distribution  supported by ASP.NET Core.

Basic configuration of the environment

Installing DNVM

To start configuring and running a first application ASP.NET Core Linux, the first step is to install the runtimes Manager, which will enable us later to install a specific version of the runtime, and finally execute our applications.
On Windows, this runtimes manager is in the simple form of a powershell script. In Linux, there is a dnvm.sh script you can just download. This installation is done through another script (dnvminstall.sh). Nevertheless, the use of that script requires prerequisites: utility unzip (used by the dnvminstall.sh script) and curl (used in the following command and the dnvminstall.sh script).
Run both commands below to get the functional dnvm order.
sudo apt-get install unzip curl
curl -sSL https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.sh | DNX_BRANCH=dev sh && source ~/.dnx/dnvm/dnvm.sh
Now the DNVM command is usable. Make the test, simply type dnvm in the command prompt and the following result is displayed. However, note that with the previous command, the dnvm.sh script is only installed for the current user.

Installing DNX

sudo apt-get install libunwind8 gettext libssl-dev libcurl4-openssl-dev zlib1g libicu-dev uuid-dev
Once installed these dependencies, it is possible to use the DNVM command to install a version of the runtime. For example, the -r CoreCLR dnvm upgrade instruction will automatically get the latest version of the runtime suitable for .NET Core. Nevertheless, I recommend using the alternative below that allows you to explicitly specify the version of the runtime that you want to install.
dnvm install 1.0.0-rc1-update1 -r coreclr
The switch -r CoreCLR is necessary to clarify that the .NET runtime Core must be installed. Without this switch, the Mono runtime have to be installed. But Mono must also be installed on the server. In the development of your projects, support for .NET Core rather than Mono is more interesting, since it is developed and supported by Microsoft. CoreCLR the runtime for Linux is currently available in 64-bit. Using the -a switch x86 will throw automatically an error asking you to prioritize the use of 64-bit.

Installing libuv

The libuv is used by the HTTP Kestrel server. It is currently the only HTTP server used in an ASP.NET Core Linux. The following instructions will download the sources from the library, compile it and then place it in the charger dynamic system libraries (dlopen).
Note that installing libuv is a mandatory step to run an ASP.NET Core Linux. Without that, it will be impossible to start the application.

Starting a first project

For further, you must have an ASP.NET Core on your Linux machine. You can use either Yeoman (which can be installed with NPM) to generate a new project, and then transfer the sources of an existing application and developed in another environment (eg. Your Windows machine with Visual Studio).

Deployment and hosting solution

 Why use a reverse proxy?

Your ASP.NET Application Core carries its own HTTP server (Kestrel). Nevertheless, it is unusual to expose a single HTTP server to the public. In terms of production architecture, we prefer rather put a reverse proxy in front of the HTTP server and reverse proxy expose this to the public.
The interest of the reverse proxy is then to support anything that is not related to the performance of a piece of code. For example, serving static files, compress HTTP responses, ensuring support for SSL, etc.
Going to production ==> Need full featured web server,reverse proxy just like in IIS with HttpPlatformHandler so install Nginx.

Install Nginx

sudo apt-get install nginx
Once installed, Nginx is present in the form of a service. You then have the option to either restart the machine, either manually start the service.
sudo service nginx start

Nginx configuration

The configuration of the sites exposed by Nginx is done by editing the file in the /etc/nginx/sites-available / default. In my example, I have chosen to redirect site traffic on port 80 to port 5000. I added the crossing different headers to the HTTP request to take forward a Kestrel. Note that the Connection header must absolutely be present, otherwise the replies will not be returned by Kestrel.
Unix sockets are another form of inter-process communication. The operation is very simple, the HTTP server is not configured over a TCP port but compared to a path to a file. In application startup, the HTTP server will create this file, then the monitor. Nginx  will just write to that file every time an incoming request must be sent to the HTTP server.
In terms of configuration, the changes required are very simple. Just tell Nginx the file path to use as socket (via proxy_pass property).
Then, we must also change the commands Node project.json file of Core ASP.NET application. Indeed, until now, I was resting on the default port used by Kestrel (5000). However, I wish now that Kestrel uses the same socket unix as configured with Nginx. The server.urls option to easily override the configuration of Kestrel.

Application Management 

The supervisor application manages the instantiation and possibly automatic instantiation of our application in case of crash.
She moved through the command below.
sudo apt-get install supervisor
Then, the following content is to be placed in the file /etc/supervisor/conf.d/nerddinner.conf.

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.