Partager via

Nouveautés d’ASP.NET Core 5.0

  • Article

Cet article met en évidence les modifications les plus importantes dans ASP.NET Core 5.0 et fournit des liens vers la documentation appropriée.

Améliorations MVC et Razor dans ASP.NET Core

Liaison de modèle DateTime au format UTC

La liaison de modèle prend désormais en charge la liaison de chaînes temporelles UTC à DateTime. Si la demande contient une chaîne temporelle UTC, la liaison de modèle la lie à un DateTime UTC. Par exemple, la chaîne temporelle suivante est liée au DateTime UTC : https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z

Liaison de modèle et validation avec les types d’enregistrement C# 9

Les types d’enregistrement C# 9 peuvent être utilisés avec la liaison de modèle dans un contrôleur MVC ou une page Razor. Les types d’enregistrement sont un bon moyen de modéliser les données transmises sur le réseau.

Par exemple, l’élément PersonController suivant utilise le type d’enregistrement Person avec la liaison de modèle et la validation de formulaire :

public record Person([Required] string Name, [Range(0, 150)] int Age);

public class PersonController
{
   public IActionResult Index() => View();

   [HttpPost]
   public IActionResult Index(Person person)
   {
          // ...
   }
}

Le fichier Person/Index.cshtml :

@model Person

<label>Name: <input asp-for="Model.Name" /></label>
<span asp-validation-for="Model.Name" />

<label>Age: <input asp-for="Model.Age" /></label>
<span asp-validation-for="Model.Age" />

Améliorations apportées à DynamicRouteValueTransformer

ASP.NET Core 3.1 a introduit DynamicRouteValueTransformer comme un moyen d’utiliser un point de terminaison personnalisé pour sélectionner dynamiquement une action de contrôleur MVC ou une page Razor. Les applications ASP.NET Core 5.0 peuvent transmettre l’état à un DynamicRouteValueTransformer et filtrer l’ensemble de points de terminaison choisi.

Divers

  • L’attribut [Compare] peut être appliqué aux propriétés sur un modèle de page Razor.
  • Les paramètres et propriétés liés à partir du corps sont considérés comme requis par défaut.

API Web

Spécification OpenAPI activée par défaut

La spécification OpenAPI est une norme de l’industrie utilisée pour décrire les API HTTP et les intégrer dans des processus métier complexes ou avec des tiers. La spécification OpenAPI est largement prise en charge par tous les fournisseurs de services cloud et de nombreux registres d’API. Les applications qui émettent des documents OpenAPI à partir d’API Web disposent d’une variété de nouvelles opportunités dans lesquelles ces API peuvent être utilisées. En partenariat avec les chargés de maintenance du projet open source Swashbuckle.AspNetCore, le modèle d’API ASP.NET Core contient une dépendance NuGet sur Swashbuckle. Swashbuckle est un package NuGet open source populaire qui émet dynamiquement des documents OpenAPI. Pour ce faire, Swashbuckle effectue une introspection sur les contrôleurs d’API et génère le document OpenAPI au moment de l’exécution ou au moment de la génération à l’aide de l’interface de ligne de commande Swashbuckle.

Dans ASP.NET Core 5.0, les modèles d’API Web activent la prise en charge d’OpenAPI par défaut. Pour désactiver OpenAPI :

  • Depuis la ligne de commande :

      dotnet new webapi --no-openapi true

  • À partir de Visual Studio : décochez Activer la prise en charge d’OpenAPI.

Tous les fichiers .csproj créés pour des projets d’API Web contiennent la référence du package NuGet Swashbuckle.AspNetCore.

<ItemGroup>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" />
</ItemGroup>

Le code généré par le modèle contient du code dans Startup.ConfigureServices qui active la génération du document OpenAPI :

public void ConfigureServices(IServiceCollection services)
{

    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApp1", Version = "v1" });
    });
}

La méthode Startup.Configure ajoute l’intergiciel Swashbuckle, qui :

  • permet le processus de génération du document ;
  • active la page d’interface utilisateur Swagger par défaut en mode de développement.

Le code généré par le modèle n’expose pas accidentellement la description de l’API lors de la publication en production.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseSwagger();  // UseSwaggerUI Protected by if (env.IsDevelopment())
        app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
                         "WebApp1 v1"));
    }

    app.UseHttpsRedirection();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

Importation dans la gestion des API Azure

Quand les projets d’API ASP.NET Core activent OpenAPI, la publication de Visual Studio 2019 version 16.8 ou ultérieure offre automatiquement une étape supplémentaire dans le flux de publication. Les développeurs qui utilisent la gestion des API Azure ont la possibilité d’importer automatiquement les API dans la gestion des API Azure durant le flux de publication :

Publication ou importation dans la gestion des API Azure

Meilleure expérience de lancement pour les projets d’API Web

Avec OpenAPI activé par défaut, l’expérience de lancement d’application (F5) pour les développeurs d’API Web s’améliore considérablement. Avec ASP.NET Core 5.0, le modèle d’API Web est préconfiguré pour charger la page d’interface utilisateur Swagger. La page d’interface utilisateur Swagger fournit la documentation ajoutée pour l’API publiée et permet de tester les API en un seul clic.

Vue swagger/index.html

Blazor

Optimisation des performances

Pour .NET 5, nous avons apporté des améliorations significatives aux performances d’exécution .NET WebAssembly avec un accent particulier sur le rendu complexe de l’interface utilisateur et la sérialisation JSON. Dans nos tests de performances, Blazor WebAssembly dans .NET 5 est deux à trois fois plus rapide pour la plupart des scénarios. Pour plus d’informations, consultez Blog ASP.NET : mises à jour ASP.NET Core dans .NET 5 Release Candidate 1.

Isolation CSS

Blazor prend désormais en charge la définition de styles CSS qui sont limités à un composant donné. Les styles CSS spécifiques aux composants permettent de mieux raisonner au sujet des styles dans une application et d’éviter les effets secondaires involontaires des styles globaux. Pour plus d’informations, consultez Isolation CSS d’ASP.NET Core Blazor.

Nouveau composant InputFile

Le composant InputFile permet de lire un ou plusieurs fichiers sélectionnés par un utilisateur pour le chargement. Pour plus d’informations, consultez Chargements de fichiers ASP.NET Core Blazor.

Nouveaux composants InputRadio et InputRadioGroup

Blazor dispose de composants InputRadio et InputRadioGroup intégrés qui simplifient la liaison de données à des groupes de cases d’option avec validation intégrée. Pour obtenir plus d’informations, consultez Composants d’entrée Blazor ASP.NET Core.

Virtualisation de composant

Améliorez les performances perçues du rendu des composants à l’aide de la prise en charge intégrée de la virtualisation de l’infrastructure Blazor. Pour plus d’informations, consultez Virtualisation des composants ASP.NET Core Razor.

Prise en charge des événements ontoggle

Les événements Blazor prennent désormais en charge l’événement DOM ontoggle. Pour plus d’informations, consultez Gestion des événements ASP.NET Core Blazor.

Définir le focus de l’interface utilisateur dans les applications Blazor

Utilisez la méthode pratique FocusAsync sur des références d’élément pour définir le focus de l’interface utilisateur sur cet élément. Pour plus d’informations, consultez Gestion des événements ASP.NET Core Blazor.

Attributs de classe CSS de validation personnalisée

Les attributs de classe CSS de validation personnalisée sont utiles lors de l’intégration à des infrastructures CSS, telles que Bootstrap. Pour obtenir plus d’informations, consultez Validation des formulaires Blazor ASP.NET Core.

Prise en charge de IAsyncDisposable

Les composants Razor prennent désormais en charge l’interface IAsyncDisposable pour la mise en production asynchrone des ressources allouées.

Isolation JavaScript et références d’objets

Blazor active l’isolation JavaScript dans les modules JavaScript standard. Pour plus d’informations, consultez Appeler des fonctions JavaScript à partir de méthodes .NET dans ASP.NET Core Blazor.

Prise en charge du nom d’affichage des composants de formulaire

Les composants intégrés suivants prennent en charge les noms d’affichage avec le paramètre DisplayName :

  • InputDate
  • InputNumber
  • InputSelect

Pour plus d’informations, consultez Vue d’ensemble des formulaires Blazor ASP.NET Core.

Paramètres de route fourre-tout

Les paramètres de route Catch-all, qui capturent les chemins d’accès dans les limites de plusieurs dossiers, sont pris en charge dans les composants. Pour plus d’informations, consultez Routage et navigation ASP.NET Core Blazor.

Améliorations du débogage

Le débogage des applications Blazor WebAssembly est amélioré dans ASP.NET Core 5.0. En outre, le débogage est désormais pris en charge sur Visual Studio pour Mac. Pour plus d’informations, consultez Déboguer des applications Blazor ASP.NET Core.

Microsoft Identity v2.0 et MSAL v2.0

La sécurité Blazor utilise désormais Microsoft Identity v2.0 (Microsoft.Identity.Web et Microsoft.Identity.Web.UI) et MSAL v2.0. Pour plus d’informations, consultez les rubriques du nœud Blazor Security and Identity.

Stockage par navigateur protégé pour Blazor Server

Les applications Blazor Server peuvent désormais utiliser la prise en charge intégrée pour stocker l’état de l’application dans le navigateur qui a été protégé contre la falsification à l’aide de la protection des données ASP.NET Core. Les données peuvent être stockées dans le stockage de navigateur local ou dans le stockage de session. Pour plus d’informations, consultez Gestion d’état ASP.NET Core Blazor.

Prérendu Blazor WebAssembly

L’intégration des composants est améliorée entre les modèles d’hébergement et les applications Blazor WebAssembly peuvent désormais effectuer un prérendu de la sortie sur le serveur.

Améliorations apportées au découpage et à la liaison

Blazor WebAssembly effectue un découpage/une liaison de langage intermédiaire (IL) pendant un build pour découper le langage intermédiaire inutile des assemblys de sortie de l’application. Avec la publication d’ASP.NET Core 5.0, Blazor WebAssembly effectue un découpage amélioré avec des options de configuration supplémentaires. Pour plus d’informations, consultez Configurer l’outil de découpage pour ASP.NET Core Blazor et Options de découpage.

Analyseur de compatibilité du navigateur

Les applications Blazor WebAssembly ciblent la surface d’exposition complète des API .NET, mais toutes les API .NET ne sont pas prises en charge sur WebAssembly en raison des contraintes de bac à sable du navigateur. Les API non prises en charge lèvent PlatformNotSupportedException lors de leur exécution sur WebAssembly. Un analyseur de compatibilité de plateforme avertit le développeur quand l’application utilise des API qui ne sont pas prises en charge par les plateformes cibles de l’application. Pour plus d’informations, consultez Consommer des composants ASP.NET Core Razor à partir d’une bibliothèque de classes (RCL) Razor.

Charger des assemblys en mode différé

Les performances de démarrage des applications Blazor WebAssembly peuvent être améliorées en reportant le chargement de certains assemblys d’application jusqu’à ce qu’ils soient requis. Pour plus d’informations, consultez Charger des assemblys en mode différé dans ASP.NET Core Blazor WebAssembly.

Mise à jour de la prise en charge de la globalisation

La prise en charge de la globalisation est disponible pour Blazor WebAssembly en fonction des composants ICU (International Components for Unicode). Pour plus d’informations, consultez Globalisation et localisation d’ASP.NET Core Blazor.

gRPC

De nombreuses améliorations de performances ont été apportées dans gRPC. Pour plus d’informations, consultez Améliorations des performances gRPC dans .NET 5.

Pour plus d’informations sur gRPC, consultez Vue d’ensemble de gRPC sur .NET.

SignalR

Filtres hub SignalR

Les filtres hub SignalR, appelés pipelines hub dans ASP.NET SignalR, sont une fonctionnalité qui permet au code de s’exécuter avant et après l’appel des méthodes Hub. L’exécution de code avant et après l’appel des méthodes Hub est similaire à la façon dont l’intergiciel a la possibilité d’exécuter du code avant et après une requête HTTP. Les utilisations courantes incluent la journalisation, la gestion des erreurs et la validation des arguments.

Pour plus d’informations, consultez Utiliser des filtres hub dans ASP.NET Core SignalR.

Appels de hub parallèles SignalR

ASP.NET Core SignalR est désormais capable de gérer les appels de hub parallèles. Le comportement par défaut peut être modifié pour permettre aux clients d’appeler plusieurs méthodes hub à la fois :

public void ConfigureServices(IServiceCollection services)
{
    services.AddSignalR(options =>
    {
        options.MaximumParallelInvocationsPerClient = 5;
    });
}

Ajout de la prise en charge de Messagepack dans le client Java SignalR

Un nouveau package, com.microsoft.signalr.messagepack, ajoute la prise en charge de MessagePack au client Java SignalR. Pour utiliser le protocole de hub MessagePack, ajoutez .withHubProtocol(new MessagePackHubProtocol()) au générateur de connexion :

HubConnection hubConnection = HubConnectionBuilder.create(
                           "http://localhost:53353/MyHub")
               .withHubProtocol(new MessagePackHubProtocol())
               .build();

Kestrel

  • Points de terminaison rechargeables via la configuration : Kestrel peut détecter les modifications apportées à la configuration transmises à KestrelServerOptions.Configure et les dissocier des points de terminaison existants, pour les lier à de nouveaux points de terminaison sans nécessiter le redémarrage de l’application quand le paramètre reloadOnChange a pour valeur true. Par défaut, quand vous utilisez ConfigureWebHostDefaults ou CreateDefaultBuilder, Kestrel est lié à la sous-section de configuration « Kestrel » avec reloadOnChange activé. Les applications doivent transmettre reloadOnChange: true quand elles appellent KestrelServerOptions.Configure manuellement pour obtenir des points de terminaison rechargeables.

  • Améliorations des en-têtes de réponse HTTP/2. Pour plus d’informations, consultez Améliorations des performances dans la section suivante.

  • Prise en charge des types de points de terminaison supplémentaires dans le transport de sockets : en ajoutant à la nouvelle API introduite dans System.Net.Sockets, le transport par défaut des sockets dans Kestrel permet la liaison à la fois aux handles de fichiers existants et aux sockets de domaine Unix. La prise en charge de la liaison à des handles de fichiers existants permet d’utiliser l’intégration Systemd existante sans nécessiter le transport libuv.

  • Décodage d’en-tête personnalisé dans Kestrel : les applications peuvent spécifier quel Encoding utiliser pour interpréter les en-têtes entrants en fonction du nom de l’en-tête au lieu d’utiliser par défaut UTF-8. Définissez la propriété Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelector pour spécifier l’encodage à utiliser :

    public static IHostBuilder CreateHostBuilder(string[] args) =>
  Host.CreateDefaultBuilder(args)
      .ConfigureWebHostDefaults(webBuilder =>
      {
          webBuilder.ConfigureKestrel(options =>
          {
              options.RequestHeaderEncodingSelector = encoding =>
              {
                    return encoding switch
                    {
                        "Host" => System.Text.Encoding.Latin1,
                        _ => System.Text.Encoding.UTF8,
                    };
              };
          });
          webBuilder.UseStartup<Startup>();
      });

Options spécifiques au point de terminaison Kestrel via la configuration

La prise en charge a été ajoutée pour la configuration des options spécifiques au point de terminaison de Kestrel via la configuration. Les configurations spécifiques au point de terminaison incluent :

  • Protocoles HTTP utilisés
  • Protocoles TLS utilisés
  • Certificat sélectionné
  • Mode de certificat client

La configuration permet de spécifier quel certificat est sélectionné en fonction du nom de serveur spécifié. Le nom de serveur fait partie de l’extension SNI (Server Name Indication) du protocole TLS, comme indiqué par le client. La configuration de Kestrel prend également en charge un préfixe générique dans le nom d’hôte.

L’exemple suivant montre comment spécifier un élément spécifique au point de terminaison à l’aide d’un fichier de configuration :

{
  "Kestrel": {
    "Endpoints": {
      "EndpointName": {
        "Url": "https://*",
        "Sni": {
          "a.example.org": {
            "Protocols": "Http1AndHttp2",
            "SslProtocols": [ "Tls11", "Tls12"],
            "Certificate": {
              "Path": "testCert.pfx",
              "Password": "testPassword"
            },
            "ClientCertificateMode" : "NoCertificate"
          },
          "*.example.org": {
            "Certificate": {
              "Path": "testCert2.pfx",
              "Password": "testPassword"
            }
          },
          "*": {
            // At least one sub-property needs to exist per
            // SNI section or it cannot be discovered via
            // IConfiguration
            "Protocols": "Http1",
          }
        }
      }
    }
  }
}

SNI (Server Name Indication) est une extension TLS permettant d’inclure un domaine virtuel dans le cadre de la négociation SSL. Cela signifie en fait que le nom de domaine virtuel, ou un nom d’hôte, peut être utilisé pour identifier le point de terminaison du réseau.

Optimisation des performances

HTTP/2

  • Réductions significatives des allocations dans le chemin de code HTTP/2.

  • Prise en charge de la compression dynamique HPack des en-têtes de réponse HTTP/2 dans Kestrel. Pour plus d’informations, consultez Taille de la table d’en-tête et HPACK : le tueur silencieux (fonctionnalité) de HTTP/2.

  • Envoi de trames PING HTTP/2 : HTTP/2 dispose d’un mécanisme permettant d’envoyer des trames PING afin de garantir qu’une connexion inactive est toujours fonctionnelle. La garantie d’une connexion viable est particulièrement utile lorsque vous travaillez avec des flux de longue durée qui sont souvent inactifs, mais qui connaissent une activité par intermittence, par exemple, les flux gRPC. Les applications peuvent envoyer des trames PING périodiques dans Kestrel en définissant les limites sur KestrelServerOptions :

    public static IHostBuilder CreateHostBuilder(string[] args) =>
  Host.CreateDefaultBuilder(args)
      .ConfigureWebHostDefaults(webBuilder =>
      {
          webBuilder.ConfigureKestrel(options =>
          {
              options.Limits.Http2.KeepAlivePingInterval =
                                             TimeSpan.FromSeconds(10);
              options.Limits.Http2.KeepAlivePingTimeout =
                                             TimeSpan.FromSeconds(1);
          });
          webBuilder.UseStartup<Startup>();
      });

Conteneurs

Avant .NET 5.0, la création et la publication d’un fichier Dockerfile pour une application ASP.NET Core nécessitaient l’extraction (pull) de l’intégralité du kit SDK .NET Core et de l’image ASP.NET Core. Avec cette version, l’extraction des octets d’image du kit SDK est réduite et les octets extraits pour l’image ASP.NET Core sont en grande partie éliminés. Pour plus d’informations, consultez ce commentaire de problème GitHub.

Authentification et autorisation

Authentification ID Microsoft Entra auprès de Microsoft.Identity.Web

Les modèles de projet ASP.NET Core s’intègrent désormais à Microsoft.Identity.Web pour gérer l’authentification avec ID Microsoft Entra. Le package Microsoft.Identity.Web fournit :

  • Une meilleure expérience d’authentification au moyen d’ID Microsoft Entra.
  • Un moyen plus simple d’accéder aux ressources Azure pour le compte de vos utilisateurs, y compris Microsoft Graph. Consultez l’exemple Microsoft.Identity.Web, qui commence par une connexion de base et avance via la mutualisation, l’utilisation des API Azure, l’utilisation de Microsoft Graph et la protection de vos propres API. Microsoft.Identity.Web est disponible en même temps que .NET 5.

Autoriser l’accès anonyme à un point de terminaison

La méthode d’extension AllowAnonymous autorise l’accès anonyme à un point de terminaison :

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        })
        .AllowAnonymous();
    });
}

Gestion personnalisée des échecs d’autorisation

La gestion personnalisée des défaillances d’autorisation est maintenant plus facile avec la nouvelle interface IAuthorizationMiddlewareResultHandler qui est appelée par l’intergiciel d’autorisation. L’implémentation par défaut reste la même, mais un gestionnaire personnalisé peut être inscrit dans l’injection de dépendances, qui autorise des réponses HTTP personnalisées en fonction de la raison de l’échec de l’autorisation. Consultez cet exemple qui illustre l’utilisation de IAuthorizationMiddlewareResultHandler.

Autorisation lors de l’utilisation du routage de point de terminaison

L’autorisation lors de l’utilisation du routage du point de terminaison reçoit désormais le HttpContext à la place de l’instance du point de terminaison. Cela permet à l’intergiciel d’autorisation d’accéder à RouteData et aux autres propriétés de HttpContext qui n’étaient pas accessibles via la classe Endpoint. Le point de terminaison peut être extrait du contexte à l’aide de context.GetEndpoint.

Contrôle d’accès en fonction du rôle avec l’authentification Kerberos et LDAP sur Linux

Consultez Authentification Kerberos et contrôle d’accès en fonction du rôle (RBAC)

Améliorations d’API

Méthodes d’extension JSON pour HttpRequest et HttpResponse

Les données JSON peuvent être lues et écrites dans et à partir de HttpRequest et de HttpResponse à l’aide des nouvelles méthodes d’extension ReadFromJsonAsync et WriteAsJsonAsync. Ces méthodes d’extension utilisent le sérialiseur System.Text.Json pour gérer les données JSON. La nouvelle méthode d’extension HasJsonContentType peut également vérifier si une demande a un type de contenu JSON.

Les méthodes d’extension JSON peuvent être combinées avec le routage de point de terminaison pour créer des API JSON dans un style de programmation que nous appelons route vers le code. Il s’agit d’une nouvelle option pour les développeurs qui souhaitent créer des API JSON de base de manière légère. Par exemple, une application web qui n’a qu’une poignée de points de terminaison peut choisir d’utiliser une route vers le code plutôt que les fonctionnalités complètes d’ASP.NET Core MVC :

endpoints.MapGet("/weather/{city:alpha}", async context =>
{
    var city = (string)context.Request.RouteValues["city"];
    var weather = GetFromDatabase(city);

    await context.Response.WriteAsJsonAsync(weather);
});

System.Diagnostics.Activity

Le format par défaut pour System.Diagnostics.Activity est désormais le format W3C. Cela rend la prise en charge du suivi distribué dans ASP.NET Core interopérable avec davantage d’infrastructures par défaut.

FromBodyAttribute

FromBodyAttribute prend désormais en charge la configuration d’une option qui permet à ces paramètres ou propriétés d’être considérés comme facultatifs :

public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)]
                          MyModel model)
{
    ...
}

Améliorations diverses

Nous avons commencé à appliquer des annotations nullables aux assemblys ASP.NET Core. Nous prévoyons d’annoter la majeure partie de la surface d’API publique commune de l’infrastructure .NET 5.

Contrôler l’activation de la classe de démarrage

Une surcharge UseStartup supplémentaire a été ajoutée pour permettre à une application de fournir une méthode de fabrique pour contrôler l’activation de classe Startup. Le contrôle de l’activation de classe Startup est utile pour transmettre des paramètres supplémentaires à Startup qui sont initialisés avec l’hôte :

public class Program
{
    public static async Task Main(string[] args)
    {
        var logger = CreateLogger();
        var host = Host.CreateDefaultBuilder()
            .ConfigureWebHost(builder =>
            {
                builder.UseStartup(context => new Startup(logger));
            })
            .Build();

        await host.RunAsync();
    }
}

Actualisation automatique avec dotnet watch

Dans .NET 5, l’exécution de dotnet watch sur un projet ASP.NET Core lance le navigateur par défaut et actualise automatiquement le navigateur à mesure que des modifications sont apportées au code. Cela signifie que vous pouvez :

  • Ouvrir un projet ASP.NET Core dans un éditeur de texte.
  • Exécutez dotnet watch.
  • Vous concentrer sur les modifications du code pendant que les outils gèrent la reconstruction, le redémarrage et le rechargement de l’application.

Formateur d’enregistreur d’événements de console

Des améliorations ont été apportées au fournisseur de journaux de console dans la bibliothèque Microsoft.Extensions.Logging. Les développeurs peuvent désormais implémenter un ConsoleFormatter personnalisé pour exercer un contrôle total sur la mise en forme et la colorisation de la sortie de la console. Les API de formateur permettent une mise en forme enrichie en implémentant un sous-ensemble des séquences d’échappement VT-100. VT-100 est pris en charge par la plupart des terminaux modernes. L’enregistreur d’événements de console peut analyser les séquences d’échappement sur des terminaux non pris en charge, ce qui permet aux développeurs de créer un seul formateur pour tous les terminaux.

Enregistreur d’événements de console JSON

En plus de la prise en charge des formateurs personnalisés, nous avons également ajouté un formateur JSON intégré qui émet des journaux JSON structurés à la console. Le code suivant montre comment passer de l’enregistreur d’événements par défaut à JSON :

public static IHostBuilder CreateHostBuilder(string[] args) =>
           Host.CreateDefaultBuilder(args)
  .ConfigureLogging(logging =>
  {
     logging.AddJsonConsole(options =>
     {
         options.JsonWriterOptions = new JsonWriterOptions()
         { Indented = true };
     });
  })
  .ConfigureWebHostDefaults(webBuilder =>
  {
    webBuilder.UseStartup<Startup>();
  });

Les messages de journal émis dans la console sont au format JSON :

{
  "EventId": 0,
  "LogLevel": "Information",
  "Category": "Microsoft.Hosting.Lifetime",
  "Message": "Now listening on: https://localhost:5001",
  "State": {
    "Message": "Now listening on: https://localhost:5001",
    "address": "https://localhost:5001",
    "{OriginalFormat}": "Now listening on: {address}"
  }
}