Le 4 décembre, .NET Core 2.2 a été publié. "Qui peut être surpris des nouvelles d'il y a une semaine?" - vous demandez et vous aurez raison ... et au fait, avez-vous déjà été mis à jour? )

Passons maintenant à l'affaire. La nouvelle version inclut des améliorations de diagnostic dans l'exécution, la prise en charge d'ARM32 pour Windows et la prise en charge d'Azure Active Directory pour SQL Client. Les principales améliorations de cette version sont ASP.NET Core.

ASP.NET Core 2.2 et Entity Framework Core 2.2 ont été publiés le même jour.

.NET Core 2.2 pour Windows, macOS et Linux vous attend déjà sur les liens:

• SDK .NET Core 2.2 (le runtime est inclus dans l'assemblage)
• Runtime .NET Core 2.2

La prise en charge de .NET Core 2.2 est présente dans Visual Studio 15.9 , Visual Studio pour Mac et Visual Studio Code.

Les conteneurs Docker sont disponibles sur microsoft / dotnet pour .NET Core et ASP.NET Core.

Les informations les plus complètes sur cette version se trouvent dans les notes de version de .NET Core 2.2 . Il existe des instructions supplémentaires, des problèmes connus et des moyens de les contourner. Veuillez nous faire part de tout défaut trouvé dans ce document dans les commentaires sur dotnet / core # 2098 .

Compilation à plusieurs niveaux

La compilation à plusieurs niveaux est une fonctionnalité qui permet au runtime d'utiliser le compilateur JIT de manière plus intelligente pour obtenir de meilleures performances à la fois au stade du lancement de l'application et au stade de la maximisation des performances pendant son fonctionnement. La possibilité de le faire a été ajoutée en tant que fonctionnalité facultative dans .NET Core 2.1 et ensuite activée par défaut dans .NET Core 2.2 Preview 2. Nous avons pensé et décidé que nous n'étions toujours pas convaincus de la pertinence de son inclusion dans la version finale de .NET Core 2.2, encore une fois. l'a rendu facultatif, tout comme c'était le cas dans .NET Core 2.1. Cependant, dans .NET Core 3.0, nous allons y basculer complètement.

Événements d'exécution

Il est généralement judicieux de surveiller les services d'exécution, par exemple, GC, JIT ou ThreadPool du processus en cours, pour comprendre comment ces services se comportent pendant la durée de vie de l'application. Sur les systèmes Windows, cela se fait généralement en utilisant ETW et en surveillant les événements ETW pour le processus en cours. Cette méthode fonctionne toujours très bien, mais l'utilisation d'ETW n'est pas toujours possible, et lorsque cela est possible, elle peut être difficile. Par exemple, vous exécutez dans un environnement avec des privilèges insuffisants ou sur Linux / macOS.

À partir de .NET Core 2.2, les événements CoreCLR peuvent être gérés par la classe EventListener . Ces événements décrivent le comportement de GC, JIT, ThreadPool et interope. Ce sont les mêmes événements qui sont désormais disponibles dans le cadre du fournisseur CoreCLR ETW pour Windows. Cette approche permet aux applications de traiter des événements ou d'utiliser des mécanismes de transport pour envoyer des événements au service d'agrégation de télémétrie.

Voici comment vous pouvez vous abonner à des événements:

 internal sealed class SimpleEventListener : EventListener { //     EventSource. protected override void OnEventSourceCreated(EventSource eventSource) { //   EventSource  .NET runtime     . if (eventSource.Name.Equals("Microsoft-Windows-DotNETRuntime")) { EnableEvents(eventSource, EventLevel.Verbose, (EventKeywords)(-1)); } } //     . protected override void OnEventWritten(EventWrittenEventArgs eventData) { //     . Console.WriteLine($"ThreadID = {eventData.OSThreadId} ID = {eventData.EventId} Name = {eventData.EventName}"); for (int i = 0; i < eventData.Payload.Count; i++) { string payloadString = eventData.Payload[i] != null ? eventData.Payload[i].ToString() : string.Empty; Console.WriteLine($"\tName = \"{eventData.PayloadNames[i]}\" Value = \"{payloadString}\""); } Console.WriteLine("\n"); } } 

Prise en charge d'AccessToken dans SqlConnection

Le fournisseur ADO.NET pour SQL Server, SqlClient, prend désormais en charge la définition de la propriété AccessToken, qui permet l'authentification des connexions à SQL Server à l'aide d'Azure Active Directory. Pour commencer à utiliser cette fonctionnalité, vous devez obtenir un jeton d'accès à l'aide de la bibliothèque d'authentification Active Directory pour .NET, fournie avec le package NuGet de Microsoft.IdentityModel.Clients.ActiveDirectory.

Voici comment authentifier les connexions à SQL Server à l'aide d'Azure AD:

 //   ,  ADAL.NET var authContext = new AuthenticationContext(authority); var authResult = await authContext.AcquireTokenAsync(appUri, clientCredential); //   SQL Server var sqlConnection = new SqlConnection(connectionString); sqlConnection.AccessToken = authResult.AccessToken; await sqlConnection.OpenAsync(); 

Pour plus d'informations, consultez la documentation ADAL.NET et Azure Active Directory .

Exécution de code avant Main

.NET Core vous permet désormais d'incorporer du code avant de démarrer la méthode principale, et cela se fait à l'aide du crochet de démarrage. Ces hooks permettent à l'hôte de personnaliser le comportement de l'application après son déploiement, sans avoir à reconstruire ou modifier le code.

Ici, nous voulons dire que les hébergeurs créeront leurs propres configurations et politiques, y compris les paramètres qui pourraient potentiellement affecter le comportement de chargement du point d'entrée principal de l'application, par exemple AssemblyLoadContext. Le hook peut être utilisé pour configurer le traçage ou implémenter la télémétrie, connecter des rappels ou tout autre paramètre de comportement spécifique à un environnement d'exécution particulier. Les crochets sont une entité complètement distincte par rapport au point d'entrée et ne nécessitent donc pas de changer le code d'application.

Une description plus détaillée se trouve dans la documentation .

Windows ARM32

Nous ajoutons la prise en charge de Windows ARM32, similaire à celle qui existe déjà pour Linux ARM32, à commencer par .NET Core 2.1. Windows prend en charge WIN32 depuis un certain temps, grâce à Windows IoT Core . Dans le cadre de la version Windows Server 2019, la prise en charge ARM32 a été ajoutée à Nanoserver. .NET Core peut désormais être utilisé sur Nanoserver et IoT Core.

Les conteneurs Docker Nanoserver pour ARM32, comme toujours, apparaîtront dans Microsoft / Dotnet sur le Docker Hub.

Nous aimerions publier des assemblys .NET Core pour Windows ARM32 aujourd'hui, mais nous sommes tombés sur un bogue tardif qui rend leur publication inutile. Nous espérons que des assemblys apparaîtront pour .NET Core 2.2.1 vers janvier 2019.

Plateformes prises en charge

.NET Core 2.2 est pris en charge sur les systèmes d'exploitation suivants:

• Client Windows: 7, 8.1, 10 (1607+)
• Windows Server: 2008 R2 SP1 +
• macOS: 10.12+
• RHEL: 6+
• Fedora: 26+
• Ubuntu: 16.04+
• Debian: 9+
• SLES: 12+
• openSUSE: 42.3+
• Alpine: 3,7+

Plates-formes matérielles prises en charge:

• x64 - Windows, macOS et Linux
• x86 - Windows
• ARM32 - Linux (Ubuntu 16.04+, Debian 9+)
• ARM32 - Windows (1809+; disponible en janvier)

Conclusion

.NET Core 2.2 est une version comprenant des améliorations majeures de la plate-forme. Nous vous recommandons fortement de l'essayer et de nous dire ce que vous en pensez. En outre, il est logique de comprendre les améliorations apportées à ASP.NET Core 2.2 et Entity Framework 2.2.

N'oubliez pas que les billets pour DotNext à partir du 1er janvier augmenteront de prix. Personnel - pour mille, et Standard - pour deux mille. Les détails sur Early Bird sont sur le site .