Les nouveautés d’ASP.NET Core

1. L’environnement d’exécution dotnet

dotnet a été conçu afin de faire fonctionner des applications .NET de manière cross-platform sur Windows, Mac et Linux et ceci sans développer un runtime différent pour chaque plateforme. C’est à la fois un environnement d’exécution et un SDK embarquant ainsi tout ce qui est nécessaire pour le bon fonctionnement des applications web ASP.NET cross-platform.

Totalement orienté package-first, Microsoft a poussé le concept de modularité très loin, permettant même à l’environnement d’exécution d’embarquer, de gérer et de créer de lui-même les packages dont il a besoin, et ceci de manière automatique via NuGet. dotnet est capable de cibler plusieurs frameworks (.NET Core ou le framework .NET Full), et ainsi générer les packages NuGet directement. De plus, dotnet embarque le nouveau moteur d’exécution CoreCLR conçu spécialement pour les problématiques de compatibilité sur les autres plateformes.

dotnet est intégré à Visual Studio 2015 pour offrir une expérience développeur enrichie, mais l’environnement d’exécution est également pilotable via les lignes de commande. Dans un projet ASP.NET Core, il est possible de rajouter des outils Microsoft et ainsi piloter son projet avec dotnet en ligne de commande. Ces outils se rajoutent en même temps que le paquet NuGet dans le fichier .csproj :

<ItemGroup> 
    <DotNetCliToolReference Inclu-de="Microsoft.VisualStudio.Web.
CodeGeneration.Tools" Version="2.0.4" /> 
    <DotNetCliToolReference Include="BundlerMinifier.Core" 
Version="2.0.238" /> 
  </ItemGroup> 

Les commandes déclarées permettent par exemple de lancer un outil de génération...

1. Les fichiers .csproj

Un projet ASP.NET Core met en œuvre une toute nouvelle philosophie de conception d’applications web issue de chez Microsoft s’inspirant beaucoup de l’open source.

Le nouveau template ressemble à ceci :

Nouveau template de projet ASP.NET Core

La première chose à savoir est que la disposition des projets dans la solution n’est pas figée. En effet, via un système de références, il est très facile de modifier l’emplacement des projets afin de suivre vos propres conventions de nommage et de structure. Un projet basique ASP.NET Core MVC est composé des éléments suivants :

Microsoft Visual Studio Solution File, Format Version 12.00  
# Visual Studio 15  
VisualStudioVersion = 15.0.28010.2016  
MinimumVisualStudioVersion = 10.0.40219.1  
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = 
"MonApplication", "MonApplication\MonApplication.csproj", 
"{GUID-PROJET}  
EndProject  
Global  
   GlobalSection(SolutionConfigurationPlatforms) = preSolution  
       Debug|Any CPU = Debug|Any CPU  
       Release|Any CPU = Release|Any CPU  
   EndGlobalSection...

1. Les fichiers de configuration

Dans les versions précédentes, le système de configuration utilisait le namespace System.Configuration couplé avec un fichier XML intitulé web.config pour stocker les informations de configuration du projet (chaînes de connexion, informations de log...). Le nouveau système inclus dans ASP.NET Core a été complètement restructuré, proposant un nouveau modèle de configuration basé sur des clés/valeurs accessibles très facilement depuis l’application ou les frameworks utilisés.

// Ajout de la clé dans le provider 
provider = new MemoryConfigurationProvider(); 
provider.Add("uneCle", "uneValeur"); 
 
var config = new ConfigurationBuilder() 
                .Add(provider) 
                .Build(); 
 
// Récupération de la valeur 
string setting2 = config["uneCle"]; 

Les fichiers de configuration inclus dans la solution sont le meilleur moyen pour ASP.NET Core de stocker les informations de configuration. Ils peuvent être aux formats JSON, XML ou INIT, et s’organisent en sections, permettant de hiérarchiser les informations. Chaque format possède son propre provider dans l’API, et il est possible d’ajouter son provider personnel. Il est indispensable de configurer au moins un provider pour que l’API Configuration fonctionne. Par défaut, le template de Visual Studio utilise...

1. La gestion côté serveur

La politique de Microsoft concernant la gestion des dépendances côté serveur est très simple : elle préconise l’utilisation du gestionnaire de paquets NuGet. La version 3 de NuGet apporte une multitude de nouvelles fonctionnalités importantes qui ont permis de stabiliser le gestionnaire de paquets et le rendre plus utilisable. Ces changements ont notamment été guidés par les différentes remontées de la communauté Microsoft.

Le premier grand changement de NuGet concerne son interface graphique qui a été complètement réécrite. Les éléments notables sont :

1. Les tâches avec Grunt

Grunt est un package Node.js, au même titre que Gulp, et est communément décrit comme étant un JavaScript Task Runner, c’est-à-dire un outil capable de créer et gérer des tâches automatisées en JavaScript. L’intérêt de ce genre d’outil est multiple. Dans un premier temps, il permet à n’importe quel développeur, avec un minimum de connaissances en JavaScript, de créer ses propres processus de minimisation, compilation, déploiement et ainsi de suite en ayant le contrôle total sur ce qu’il se passe. Ensuite, l’automatisation de ces tâches permet de s’assurer que chaque processus est exécuté au bon moment et toujours de la même manière. Enfin, les JavaScript Task Runner sont aujourd’hui très répandus dans le développement web front-end, et bénéficient ainsi d’une communauté importante et grandissant chaque jour un peu plus. Les possibilités offertes par ce genre d’outil peuvent être étendues à l’infini.

Concrètement, Grunt est simplement un package NPM et la commande pour l’installer est la suivante :

$ npm install grunt --save-dev 

Rien de plus simple, l’option --save-dev permet de rajouter...