La version 2.2 du framework .Net Core est disponible
avec l’ajout d’une couche de sécurité pour les connexions avec SQL Server et un meilleur suivi des services à l’exécution
Depuis hier, .Net Core est disponible en version 2.2. Pour les personnes extérieures à l’environnement .Net, il faut savoir que .Net Core est un framework développé par Microsoft et compatible avec les systèmes d’exploitation Windows, GNU/Linux et macOS. Il se présente comme un assemblage modulaire de composants initialement disponibles dans le Framework .Net et a été rendu open source depuis 2014. Il se compose de plusieurs éléments comme CoreRT, la chaîne d’outils natifs permettant de compiler le code d’octet CLI en code machine, de CoreCLR, l’environnement d’exécution implémenté à partir de CLR (la machine virtuelle qui gère l’exécution des programmes .Net), de CoreFX, le fork de la bibliothèque standard de Microsoft FCL ainsi que de plusieurs autres composants.
Dans cette nouvelle version, nous avons comme de coutume plusieurs améliorations. Dans les versions antérieures par exemple, lorsqu’on souhaitait surveiller les services de l’environnement d’exécution tels que GC, JIT et ThreadPool par rapport au processus en cours afin de comprendre comment ces services se comportent lorsque vous exécutez une application, l’on se contentait de suivre les évènements ETW du processus en cours. Toutefois, cette pratique a des limites, car elle n’est pas facile à utiliser et pourrait ne pas être possible même dans des environnements disposant de peu de privilèges.
Vu ces difficultés rencontrées dans le suivi de ces évènements, l’équipe de .Net Core annonce que dans .Net Core 2.2, il est plus facile de surveiller ces évènements en raison de leur fonctionnement qui a été simplifié. Dans cette nouvelle version de .Net Core, les évènements CoreCLR peuvent maintenant être consommés à l'aide de la classe EventListener. Ces évènements décrivent le comportement de GC, JIT, ThreadPool et interop. Ce sont les mêmes évènements qui sont exposés dans le cadre du fournisseur CoreCLR ETW sous Windows. Cela permet aux applications de consommer ces évènements ou d'utiliser un mécanisme de transport pour les envoyer à un service d'agrégation de télémétrie.
Pour ceux qui se connectent à SQL Server, Microsoft annonce l’ajout de propriété de sécurité lors des connexions avec SQL Server en utilisant Azure Active Directory, le service de gestion des identités et des accès du service cloud de Microsoft. En effet, le fournisseur ADO.NET pour SQL Server, SqlClient, prend désormais en charge la définition de la propriété AccessToken pour authentifier les connexions SQL Server à l'aide d'Azure Active Directory. Pour pouvoir utiliser cette fonctionnalité, vous pouvez obtenir la valeur du jeton d'accès à l'aide de la bibliothèque d'authentification Active Directory pour .NET, contenue dans le package NuGet Microsoft.IdentityModel.Clients.ActiveDirectory.
Pour authentifier les connexions avec SQL Server en utilisant Azure Active Directory, l’on procéder de la manière suivante :
En plus de ces nouvelles implémentations, l’équipe de Microsoft annonce également qu’il est maintenant possible d’injecter du code avant d’exécuter une méthode principale d’application. Cela est possible en utilisant un point d’ancrage. Cette nouvelle disposition permet à un hôte de personnaliser le comportement des applications après leur déploiement, sans avoir besoin de recompiler ou de modifier l'application. En outre, vu que le point d'ancrage est séparé du point d'entrée, il n'est donc pas nécessaire de modifier le code utilisateur.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 // get access token using ADAL.NET var authContext = new AuthenticationContext(authority); var authResult = await authContext.AcquireTokenAsync(appUri, clientCredential); // setup connection to SQL Server var sqlConnection = new SqlConnection(connectionString); sqlConnection.AccessToken = authResult.AccessToken; await sqlConnection.OpenAsync();
Enfin, l’équipe de Microsoft annonce que l’ajout du support pour Windows ARM32, similaire au support Linux ARM32 qui a été ajouté dans .Net Core 2.1, est disponible. Toutefois, un bogue de dernière minute a empêché la publication de la version .Net Core pour Windows ARM32. Cet ajout a donc été reporté à la version 2.2.1 de .Net Core qui sortira en janvier 2019. Par ailleurs, les mainteneurs de .Net Core annoncent qu’ils ne sont pas tout à fait prêts à activer par défaut dans cette version la compilation à plusieurs niveaux qui avait été ajoutée de manière optionnelle dans .Net Core 2.1. La compilation à plusieurs niveaux, qui est une fonctionnalité permettant au moteur d'exécution d'utiliser de manière plus adaptative le compilateur Just-In-Time (JIT) pour obtenir de meilleures performances, aussi bien au démarrage que pour l'optimisation du débit, est donc toujours disponible de manière optionnelle dans cette dernière version de .Net Core.
Source : Microsoft
Et vous ?
Quel est votre avis sur cette nouvelle itération de .Net Core ?
Les fonctionnalités mises en avant sont elles en phase avec vos attentes ?
Voir aussi
.NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
Microsoft annonce la sortie de .NET Core 2.1, avec de nombreux ajouts et améliorations qui viennent enrichir cet environnement
Microsoft annonce la disponibilité de la première préversion de .NET Core 2.1 pour Windows, macOS et Linux
.NET Core ou .NET Framework ? Quelle implémentation adopter pour son projet ? Par Hinault Romaric
La feuille de route de .NET Core 2.0 et .NET Standard 2.0 dévoilée, que nous réservent les prochaines implémentations majeures ?
Partager