Accueil Nos publications Blog [ASP.NET 5] Quoi de neuf à la Build 2015 ?

[ASP.NET 5] Quoi de neuf à la Build 2015 ?

ASP.NET logoL’évènement Build 2015 a été l’occasion pour Microsoft d’annoncer plusieurs nouveautés phares dans sa gamme de produits pour les développeurs. Deux de ces annonces concernent tout particulièrement les développeurs Web Microsoft : Visual Studio Code et .NET Core. Même s’il n’y a pas eu d’autres annonces particulières concernant ASP.NET 5, le chemin parcouru depuis les premières annonces faîtes il y a maintenant près d’un an est énorme.

Ce billet est donc l’occasion pour moi de faire le point sur l’état d’avancement du projet, sur les modifications apportées à la plate-forme et sur ce à quoi nous pouvons nous attendre d’ici la sortie finale du produit.

Si vous êtes intéressés par le sujet, vous pouvez toujours consulter (en anglais), les deux sessions de la Build 2015 consacrées à ASP.NET 5. La première présente les fondamentaux de la plate-forme (la lecture de ce billet, en français, peut s’avérer être un bon point de départ avant de regarder l’enregistrement de cette session), la seconde rentre plus en profondeur sur le fonctionnement interne d’ASP.NET 5 et de l’environnement DNX.

Où en est-on ?

Premier élément important, le timing. En effet, lors de la Build, Microsoft a mis officiellement à disposition de tous les développeurs une version RC (Release Candidate) de Visual Studio 2015. Il s’agit là d’un des tout derniers jalons avant la sortie définitive d’un produit. Cependant, le cycle de développement d’ASP.NET 5 suit une route différente. En effet, sa sortie n’est pas corrélée à celle de Visual Studio 2015. Et donc, à l’heure actuelle, le projet n’est toujours pas disponible en version RC mais reste dans une version Beta 4. A noter que dans les stands ups hebdomadaires de l’équipe de développement, on apprenait déjà il y a quelques mois que cette phase de Beta 4 n’était pas initialement prévue mais qu’il avait été choisi de l’ajouter pour améliorer la qualité du produit. Enfin, d’après Scott Hunter et Scott Hanselman, le delta entre les deux cycles de développement (Visual Studio 2015 et ASP.NET 5) est d’environ 3 mois. On peut donc raisonnablement espérer voir la plate-forme arriver en version RC cet été.

Dans les premières phases du projet, et depuis les toutes premières versions rendues publiques il y a maintenant un an, l’intégralité d’ASP.NET 5 se basait sur un environnement nommé K. Cela englobait un gestionnaire de paquet, un gestionnaire d’environnement et une série de différents utilitaires. Là encore, si ces concepts ne vous parlent pas, je vous invite à prendre connaissance de ce billet. Assez récemment, les équipes de Microsoft ont décidé de renommer l’environnement et les différents outils et de revoir quelque peu leurs usages. Le but étant de donner une cohérence au tout et de distribuer aux développeurs des outils les plus adaptés et les plus intuitifs possibles.
Ainsi, les différents outils K* et l’intégralité de la plate-forme KRE deviennent respectivement les outils DN* et la plate-forme DNX.

Visual Studio 2015 et DNX

L’intégration d’ASP.NET 5 avec la version actuelle de Visual Studio 2015 est telle qu’il est maintenant possible de bénéficier de fenêtres d’accès rapides aux différentes commandes DNX.

Un projet ASP.NET 5, compatible avec DNX fonctionne avec deux éléments minimum : un fichier project.json et une classe Startup.

Le fichier project.json décrit le projet, c’est-à-dire les dépendances sur lesquelles il repose, les commandes qu’il supporte ou encore les fichiers à exclure ou à inclure lors des phases de compilation ou de publication de l’application.

Dans l’exemple de fichier project.json ci-dessous, deux éléments supplémentaires sont présents.

D’abord, la propriété webroot. Celle-ci correspond au nom du répertoire destiné à accueillir le contenu statique de l’application. C’est une des évolutions apportées par ASP.NET 5 par rapport aux versions précédentes. En effet, jusqu’à présent, les fichiers statiques (fichiers JS, images, pages HTML, etc.) étaient directement mélangés avec tout le code du site (vues Razor, ou directement les classes C#).

Avec ASP.NET 5, il est possible d’isoler tout le contenu statique de l’application dans un sous dossier, le nom de ce dernier étant le nom passé à la propriété webroot. Par défaut, la valeur utilisée est wwwroot. Ainsi, si je place un fichier mapage.html à la racine de mon application et que je navigue vers https://monsite/mapage.html, le serveur sera incapable de servir la ressource. En revanche, si je place ce même fichier dans le dossier wwwroot et que je navigue vers https://monsite/mapage.html, le serveur sera en mesure de servir le fichier.

La propriété frameworks permet de définir les versions de la plate-forme ciblée par l’application ASP.NET 5. Ici, les valeurs utilisées sont dnx451 et dnxcore50. Cela signifie que l’application doit être compatible avec la version complète du framework (dnx451) mais aussi avec la version allégée (dnxcore50). Dans Visual Studio 2015, ces valeurs vont directement influencer le contenu de la liste « CLR Type (Profile) » – permettant de choisir le runtime à utiliser lorsque l’application est démarrée via Visual Studio.

En coulisse, la valeur sélectionnée dans cette liste va simplement être utilisée par l’IDE pour faire à un appel à la commande dnvm use avec le paramètre adéquat. C’est également cette liste qui va alimenter le contenu du nœud « References » dans l’explorateur de solutions. Enfin Visual Studio utilise également la liste des frameworks supportés pour alimenter au mieux l’IntelliSense. En effet, dès qu’un développeur utilise une API, Visual Studio va vérifier la compatibilité de celle-ci avec la liste des frameworks supportés. Les résultats de cette compatibilité s’affichent alors dans la liste des erreurs de compilation, mais également directement dans la fenêtre dynamique de l’auto-complétion.

Le nœud dependencies représente les différents paquets nécessaires au fonctionnement de l’application. Cette approche est particulièrement intéressante puisqu’elle permet de mixer les sources de paquet. Cela signifie qu’ils sont recherchés en priorité en local, et s’ils ne sont pas trouvés à cet emplacement, ils sont alors recherchés dans les différents dépôts Nuget configurés. Techniquement, si vous souhaitez modifier les sources d’ASP.NET MVC, il vous suffit alors de les télécharger en local, les placer dans le même répertoire que le reste de votre application et… rien de plus. En effet, DNX va alors détecter automatiquement qu’il n’est plus nécessaire de rechercher le paquet sur le dépôt en ligne et va utiliser les sources locales en priorité. Vous pouvez alors débuguer librement dans les sources d’ASP.NET MVC.

Le concept de commandes, qui peuvent être exprimées par le nœud commands, permet de définir des points d’entrées pour l’application. Chaque commande à une clé associée (dans l’exemple ici, web) et une action. Ici, si le développeur tape dnx web dans le dossier de l’application, le runtime va chercher un point d’entrée dans l’assemblage Microsoft.AspNet.Hosting en lui passant deux paramètres (le type de serveur à utiliser et l’URL d’écoute). La clé web peut être remplacée par ce que l’on souhaite (toto par exemple est une clé tout à fait valable). Il est tout à fait possible de créer des points d’entrées “faits maisons” en créant un assemblage avec une classe Program et une méthode Main (comme un point d’entrée standard .NET).

{
  "webroot": "wwwroot",
  "dependencies": {
    "Microsoft.AspNet.Server.IIS": "1.0.0-beta4",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4"
  },
  "commands": {
      "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls https://localhost:5000"
  },
  "frameworks": {
    "dnx451": { },
    "dnxcore50": { }
  }
}

Un petit coup d’œil au fichier Startup.cs à présent. Si vous êtes déjà familier de Katana ou d’ASP.NET 5, il n’y a rien de nouveau ici depuis l’année précédente. La classe Startup représente en fait le lanceur de l’application. Elle est automatiquement découverte et chargée par le runtime au lancement de l’application.

La méthode ConfigureServices permet de charger les différents composants dans le conteneur IoC. La méthode Configure elle permet de configurer les différents Middleware (équivalents des modules/gestionnaires HTTP historiques) dans le tunnel de traitement des requêtes. L’exemple ici est extrêmement basique puisqu’il va se contenter de générer une réponse avec pour seul contenu le texte Hello World et ce, quel que soit la requête reçue en entrée.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Run(async (context) =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    }
}

Visual Studio Code

Visual Studio Code est un éditeur de texte présenté lors de la Build. Bien loin du fonctionnement complet d’un IDE tel que Visual Studio il présente néanmoins certains avantages le rendant particulièrement adapté au développement de projets ASP.NET 5 :

  • Intégration du projet OmniSharp et donc présence d’une IntelliSense et d’un processus de vérification syntaxique (similaire à la « compilation » d’un projet ASP.NET 5 sous Visual Studio 2015) ;
  • Palette de commande permettant un accès rapide aux fonctionnalités de DNX ;
  • Extrêmement léger à installer et à exécuter ;
  • Multiplateforme, l’outil est utilisable aussi bien sur Windows que sur Linux ou Mac OS.

Techniquement, l’expérience de développement s’approche de ce qu’un développeur pourrait trouver en combinant un éditeur tel que Atom ou Sublime avec les extensions OmniSharp et Kulture. Si vous êtes un développeur habitué à Visual Studio, vous allez probablement êtes perturbé par votre premier contact avec l’outil. Ici, pas de notion de solution, de projet, et exit également les fonctions de debuguage de l’IDE complet (mais ce n’est bien évidemment pas ce qui est demandé à un outil aussi léger).

A noter que l’outil n’est pas bridé aux technologies Microsoft ni même à ASP.NET 5. Le support officiel concerne en effet une douzaine de langages différents.

Pour conclure, si vous ne l’avez pas déjà fait, je vous invite vivement à vous intéresser à ASP.NET 5. En effet, la plate-forme est à présent dans un état largement assez stable pour que vous commenciez à l’envisager pour débuter un nouveau projet ou pour commencer à vous intéresser à la migration de votre projet actuel.