Mi-août, Microsoft lançait .NET Core 2.0. Si ces technologies sont connues depuis des années, elles ont passé durant l’été un cap important. Au cœur des nouveautés, on trouve notamment .NET Standard 2.0, une version largement étoffée du socle API. L’ensemble peut désormais prétendre à un vrai statut de solution multiplateforme.

L’environnement .NET existe depuis 2002. Pour beaucoup, ces technologies sont intimement liées à Windows et permettent le développement de solutions allant de l’application classique aux composants de serveurs. .NET se sert d’un environnement d’exécution basé sur la Common Language Infrastructure (CLI), implémenté sous forme de  Common Language Runtime (CLR).

Bien que la « voie royale » pour utiliser cet environnement soit le langage C# (développé initialement par Anders Hejlsberg, qui avait créé Delphi), d’autres sont pris en charge, .NET en étant indépendant. Tous les programmes sont transcodés dans un premier temps en bytecode, intermédiaire avant la compilation proprement dite, un fonctionnement qui le rapproche de Java (auquel .NET est souvent comparé du fait de son code managé).

Initialement, .NET a été créé pour effacer progressivement la frontière entre applications classiques et web, mais l’environnement restait invariablement lié à Windows. Bien que des produits comme Xamarin (depuis rachetée par Microsoft) aient cherché à faire de .NET et C# des solutions de développement multiplateforme, la vision n’a réellement commencé à se concrétiser qu’avec l’arrivée de .NET Core.

.NET Core et la nouvelle orientation multiplateforme

Quand Microsoft lance la version 1.0 de .NET Core, les développeurs voient débarquer un remaniement complet de la technologie, tiré d’un sous-ensemble du framework existant. Plus question cette fois d’un environnement centré sur Windows : Microsoft a repris son produit depuis le début pour un faire un socle multiplateforme.

Sûre d’elle, l’entreprise avait même annoncé cette version durant le Red Hat Summit. Pourquoi ? Parce qu’en plus de changer complètement d’orientation, l’éditeur a créé en même temps la .NET Foundation, qui gère désormais l’environnement devenu open source.

Voilà d’ailleurs comment est présenté .Net Core : un ensemble de technologies pour Linux, macOS, Windows et autres, dont le code est protégé par une licence Apache 2.0 ou MIT selon les cas, avec des dépôts GitHub associés.

Cet ensemble est modulaire. Il ne s’agit plus d’un framework complet, mais de technologies que le développeur peut utiliser ou non selon le contexte. Ces composants sont distribués sous forme de paquets NuGet, et il n’est plus question d’un environnement présent sur la machine : il est embarqué avec l’application, ou plus globalement le projet.

L’appellation « .NET Core » sert en fait de parapluie. On retrouve des éléments comme CoreCLR, le moteur d’exécution lui-même, la bibliothèque .NET Standard qui définit le socle fonctionnel via les API (pour toutes les plateformes), ASP.NET Core, Entity Framework et autres.

La version 1.0 sortie l’année dernière avait le mérite de tracer une ligne nette dans le sable, indiquant aux développeurs que tel était désormais le futur du développement .NET. La parité fonctionnelle était cependant loin d’être atteinte. La mouture 1.1 améliorait la situation quelques mois plus tard, mais c’est surtout .NET Core 2.0, sorti le mois dernier, qui change réellement la donne.

.NET Standard 2.0 fait le grand saut

L’un des plus gros changements de cette deuxième version majeure est l’accélération de la spécification .NET Standard. Le nombre d’interfaces disponibles pour les développeurs passe ainsi de 13 000 à 32 000. Les fonctions couvertes sont donc beaucoup plus nombreuses et arrivent presque au niveau de l’ancien Framework .NET 4.6. En fait, les écarts se font surtout sur des possibilités liées à Windows, non incluses puisque .NET Core est un environnement multiplateforme, bien que les p/invoke y soient toujours possibles.

.NET Standard 2.0 est probablement l’élément le plus important de l’ensemble. Un lot commun d’API et un moteur d’exécution multiplateforme permettent aux développeurs de se focaliser sur leur projet sans normalement tenir compte des spécificités de chaque système. .NET Standard 2.0 est considéré comme isofonctionnel et est supporté par le .NET Framework 4.6.1, .NET Core 2.0, Mono 5.4, Xamarin iOS 10.14, Xamarin.Mac 3.8 et Xamarin.Android 7.5. La prise en charge par UWP (Universal Windows Platform) sous Windows 10 doit arriver avant la fin de l’année.

.NET Standard 2.0 ajoute également un important mode de compatibilité venant compenser en partie l’un des reproches majeurs faits à la première version de l’environnement. En théorie, il permet au développeur de faire référence dans son projet à une API d’un ancien Framework. En pratique, ce n’est possible qu’avec celles référencées dans .NET Standard, d’où l’importance de cette version 2.0 et ses 32 000 API. Par ailleurs, les paquets NuGet n’ont plus besoin de déclarer de dépendances aux composants de .NET Core 2.0 : elles sont directement fournies par le SDK de l’environnement.

L’insistance particulière de Microsoft sur le multiplateforme est marquée : le développement sous Windows devient en quelque sorte moins important que la possibilité de pouvoir exécuter son code partout. Un projet .NET Core 2 développé dans Visual Studio 2017 par exemple pourra cibler tout ou partie des systèmes pris en charge. Dans la plupart des cas, le code sera strictement identique. Ce n’est qu’en abordant certains points que des suppléments seront à prévoir.

Les améliorations principales de .NET Core 2.0

La nouvelle version commence par augmenter le nombre de plateformes officiellement prises en charge. Debian Stretch, SUSE Linux Enterprise Server 12 SP2 et macOS High Sierra sont notamment de la partie. Linux est également traité désormais comme une plateforme unique. La compilation se fait toujours par architecture, mais toutes les distributions testées sont compatibles, essentiellement celles basées sur glibc (surtout Debian, Red Hat et leurs dérivés). Red Hat fournit d’ailleurs un support officiel de .NET Core 2.0.

Depuis la mouture précédente, Microsoft indique que les performances sont nettement à la hausse dans presque tous les domaines. Autre changement important, le compilateur RyuJIT est présent dans la version x86 de l’environnement pour tout ce qui touche au just-in-time (compilation à la volée). Il était déjà présent en version x64 mais remplace ici l’ancien compilateur JIT32, avec lequel il est totalement compatible et qui sera supprimé de la plateforme.

Microsoft indique que le comportement général de .NET Core 32 bits sera de fait beaucoup plus proche de la mouture 64 bits. Il ne faut cependant pas s’attendre à de grands écarts de performances sur le code dans cette version particulière de RyuJIT, comme l’éditeur l’expliquait en avril dernier. Cependant, le nouveau compilateur a davantage de fonctionnalités et réalise certaines opérations de manière plus efficace, notamment tout ce qui touche aux calculs en virgule flottante.

Enfin, bien que l’on parle ici d’une version finale de l’environnement, Microsoft en a profité pour glisser des préversions ARM32 du .NET Core Runtime pour Linux et Windows. Et signalons dans une moindre mesure la compatibilité de Visual Basic avec .NET Core, même si ses attributions se limitent pour l’instant au développement de bibliothèques de classes et d’applications console.

Notez que l’installation de .NET Core 2.0 ne remplace pas les versions 1.0 et 1.1 de l’environnement. Elles restent concurrentielles, et les applications conçues pour des moutures antérieurs continueront à le faire sans craindre une quelconque incompatibilité.

Quid d’ASP.NET Core 2.0 et Entity Framework Core 2.0 ?

Bien qu’éléments importants de l’ensemble, ASP.NET Core et Entity Framework Core ne font plus partie du tronc commun. Comme indiqué précédemment, l’environnement est modulaire, et ces éléments ne seront donc appelés que si le développeur en a besoin.

Comparativement au reste, ASP.NET Core 2.0 propose moins de nouveautés, mais certaines sont importantes. Pour simplifier le travail de ceux qui en ont besoin, Microsoft propose ainsi un métapaquet Microsoft.AspNetCore.All pour récupérer d’une traite tous les paquets nécessaire aux projets ASP.NET. La modularisation avait en effet entrainé une multiplication des paquets, provoquant l’agacement de certains.

Plus significatif, ASP.NET Core 2.0 introduit les Razor Pages, une alternative à l’architecture classique MVC (Model-View-Controller) quand le développeur travaille sur un projet centré sur les pages elles-mêmes. Il se concentre alors sur leur conception et l’interface utilisateur. Il n’y a plus par défaut qu’un seul fichier .cshtml contenant l’ensemble de la page. Solution tournée vers les petits et moyens projets, ou pour les débutants, elle permet dans un projet vide d’ajouter un dossier Pages puis de créer autant d’éléments PageModel que l’on souhaite.

Microsoft fournit en outre un nombre plus important de modèles, dont un nouveau justement pour les Razor Pages. D’autres se concentrent sur les scénarios SPA (single-page-applications), qui utilisent les JavaScript Services pour embarquer NodeJS dans ASP.NET Core côté serveur. Les applications JavaScript sont également compilées en même temps que le reste du projet.

Parmi les autres nouveautés, signalons une importante simplification de la configuration Host via un nouveau WebHost.CreateDefaultBuilder présent par défaut dans tous les modèles ASP.NET Core. Citons également un renforcement du serveur web Kestrel via la déclaration de limites (connexions clients entre autres), la compilation par défaut des vues et pages Razor pendant la publication (elle peut être désactivée).

Entity Framework est de son côté un O/RM (Object/Relational Mapping), à savoir une bibliothèque faisant le lien entre une base de données et son équivalent en modèle objet. Il permet donc de réaliser des requêtes (en LINQ ou en SQL) pour récupérer des éléments dans la base pour les transformer en objets exploitables par le développeur.

La version 2.0 du framework apporte là encore des nouveautés, notamment une traduction LINQ vers SQL améliorée, l’ajout de l’opérateur Like dans LINQ, la possibilité de définir des entités owned et child, l’ajout de filtres globaux pour les requêtes ou encore les requêtes explicitement compilées.

Pour se lancer dans ASP.NET Core 2.0

Il existe déjà plusieurs moyens d’exploiter les nouvelles versions de ces briques, même si l’installation du SDK est dans tous les cas obligatoires. Comme Microsoft l’indiquait dans son annonce, le développeur devra disposer au moins de la version 15.3 de Visual Studio 2017, ou des dernières révisions de Visual Studio pour Mac ou de Visual Studio Code. Pour ce dernier – et qu’il s’agisse de Linux, macOS ou Windows – l’extension C# sera nécessaire.

• SDK .NET Core 2.0 (dépôt GitHub)
• Visual Studio 2017 Community Edition
• Visual Studio pour Mac
• Visual Studio Code
• Extension C# pour VS Code