.NET Core 3.1 est sorti et il nous apporte quelques modifications substantielle, notamment pour les utilisateurs de Blazor et le Windows Desktop

Pour mémo, Blazor est une façon efficace, et orignale, d’envisager la création de site web. Il permet non seulement au programmeur de ne pas quitter son environnement de programmation préféré mais surtout de ne pas changer de langages.

Réfléchissez bien et observer en quoi consiste la création « moderne » et « professionnelle » de sites web. Bien sûr, PHP peut toujours être utilisé, mais rappelez vous que PHP signifie Personal Home Page. Le « Personal » devrait oriente et légitimer la raison pour laquelle en entreprise, du moins en grande entreprise, les sites web ne sont pas codé en PHP. Oui, d’une façon générale vous trouverez majoritairement des applications codées en C#, Java, parfois C++ côté serveur et beaucoup de Javascript côté client. C# et Java ont l’avantage d’avoir des API riches et des cas d’usage nombreux, notamment en termes de connexion à des bases de données ou en support de problématiques de charge. Pour ces raisons, ils sont majoritairement utilisés côté serveur mais on voit de plus en plus apparaître du Node JS. Mais quid du côté client ?

Côté client, c’est Javascript… Enfin TypeScript (créé par Microsoft, ou plus précisément par le créateur de C#, faut-il le rappeler ?) qui gagne la mise. Par Javascript/TypeScript j’entends tous les framework de React à Angular en passant par VueJS. Il y en a plein d’autres m ais ceux là remportent un franc succès. Le hic ? Il est simple à comprendre, un programmeur C# n’est pas un programmeur Javascript/Typescript tout comme un développeur Java n’est pas un programmeur C#, Javascript/TypeScript, etc…. Vous l’aurez compris, le changement de langage tue la productivité. Ce que propose Microsoft avec Blazor, c’est une solution pour ne pas nécessiter de changement. Le développeur garde son langage de prédilection et peut adresser aussi bien des problématiques serveurs que client webPour la petite histoire, ce n’est pas la première fois que ce type de solution est proposée aux informaticiens. Côté Java, le framework GWT (Google Web Toolit) a connu un grand engouement dans les années 2016/2017. Très opérationnelle, des solutions comme SmartGWT, GXT s’appuyant sont GWT sont apparus. Elles permettaient aux développeurs Java de coder « tout en Java », une vraie révolution. Demeure que ces solutions n’ont pas été pérenne car non proposées par le créateur de Java, c’est-à-dire Oracle. Microsoft de son côté évoquait dès 2007 un projet, dénommé Volta, qui devrait couvrir ce cas d’usage. En provenance de Microsoft Labs, en dehors d’une preview, rien n’est véritablement sorti ; le projet ayant été avortée avant.

Mais ceci c’était avant Blazor qui se positionne comme une façon intéressante d’aborder le Web, notamment lorsque l’on pense WebAssembly, c’est-à-dire (pour simplifier) ces composants compilés qui se comportent à l’image des Dlls, mais pour le Web.

Blazor Component Tag Helper

Avec .NET Core 3.0, nous étions contraint d’utiliser le helper HTML Html.RenderComponentAsync. S’il est toujours valide avec ASP.NET Core 3.1, le nouveau component tag suivant est à préférer.

Passage de paramètres à des composants Top-Level

Il n’était jusqu’alors impossible de passer des paramètres à des composants top-level qu’avec RenderMode.Static. Les modes ServerPrerendered et Server sont désormais supportés.

Outre Blazor, .NET Core 3.1 nous apporte des fonctionnalités intéressantes.

Support des classes partielles pour Razor

Les composants Razor sont générés en classes partielles, ce qui permet une extension des composants au besoin. Pour méo, avec Razor on peut générer des composants in situ dans le code ou mode HTML markup. Pour en savoir plus.

Mises à jour pour Windows Forms

Des changements substantielles ont eu lieu sur d’anciens contrôles désormais obsolètes. Ces contrôles ne sont ainsi plus dispobibleLes programmeurs sont invités à mettre à jour leurs applications ; le processus est simple, il consiste en un rechercher/remplacer. La liste des composants se retrouve ici.

C++/CLI

Bonne nouvelle pour les aficionados de C++, il est désormais possible sur Windows C++/CLI pour des composants Desktop. Cette fonctionnalité requiert l’utilisation de Visual Studio 2019 version 16.4.

Les binaires produits sont compatibles .NET Core 3.0 et versions suivantes

Release étendue

Le support de .NET Core 3.1 est en mode « long-term », autrement dit 3 ans. Il est releasé avec VS 2019.16.4, Microsoft recommande un update de ce dernier pour bénéficier de .NET Core 2.1.

Pour les utilisateurs Mac, il faut opter pour VS Studio Mac 8.4 Preview channel.

Génération de code Mach-O pour les utilisateurs Mac

Le format Mach-O ne vous dit rien ? Si je vous dis PE ou ELF, ça vous évoque quelque-chose ?

Sur chaque système d’exploitation il y a un format de fichier qui correspond aux exécutables. Sur Windows, ce format est le PE (pour Portable Executable) matérialisé par des extensions de fichier « .exe », sur Linux et les versions récentes d’UNIX, c’est le format ELF (Executable and Linkable Format) et pour Mac c’est le format Mach-O (pour Mach Object).

Avec la nouvelle version .NET Core, le paramètre appHost est désormais désactivé par défaut.

Quand ce paramètre est activé, .NET Core génère du code natif lorsque l’on build ou déploie une application. Cette dernière fonctionne dans le contexte appHost lorsqu’elle est lancée à partir de la commande dotnet run ou en lançant l’executable Mach-O directement.

Sans l’AppHost, la seule façon pour un utilisateur de démarrer une application qui dépend du runtime (c’est-à-dire non self-contained ») est d’effectuer la commande dotnet application. dll

Notez que lorsqu’on publie une application en mode « self-contained », un appHost est toujours crée.

Le réglage appHost peut se faire au niveau du projet :

Il peut également se faire via la paramètre -p:UseAppHost sur les commandes dotnet adéquates comme par exemple :

Quel intérêt ? Pouvoir immédiatement permettre de distinguer les applications self-contained des autres et garantir un lancement adéquat, par les bonnes commandes, par l’utilisateur (qui soit s’assurer d’avoir le runtime dans le cas non self-contained).