Delen via

Wat is er nieuw in ASP.NET Core 5.0

  • Artikel

In dit artikel worden de belangrijkste wijzigingen in ASP.NET Core 5.0 beschreven met koppelingen naar relevante documentatie.

Verbeteringen ASP.NET Core MVC en Razor

Het model binden van DateTime als UTC

Modelbinding biedt nu ondersteuning voor het binden van UTC-tijdreeksen aan DateTime. Als de aanvraag een UTC-tijdtekenreeks bevat, bindt de modelbinding deze aan een UTC-DateTime. De volgende tijdtekenreeks is bijvoorbeeld afhankelijk van de UTC-DateTime: https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z

Modelbinding en validatie met C# 9-recordtypen

C# 9-recordtypen kunnen worden gebruikt met modelbinding in een MVC-controller of een Razor-pagina. Recordtypen zijn een goede manier om gegevens te modelleren die via het netwerk worden verzonden.

De volgende PersonController gebruikt bijvoorbeeld het recordtype Person met modelbinding en formuliervalidatie:

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

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

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

Het bestand 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" />

Verbeteringen in DynamicRouteValueTransformer

ASP.NET Core 3.1 heeft DynamicRouteValueTransformer geïntroduceerd als een manier om aangepast eindpunt te gebruiken om dynamisch een MVC-controlleractie of een Razor pagina te selecteren. ASP.NET Core 5.0-apps kunnen de status doorgeven aan een DynamicRouteValueTransformer en de gekozen set eindpunten filteren.

Allerlei

  • Het kenmerk [Vergelijken] kan worden toegepast op eigenschappen op een Razor paginamodel.
  • Parameters en eigenschappen die afhankelijk zijn van de hoofdtekst, worden standaard als vereist beschouwd.

Web-API

OpenAPI-specificatie standaard ingeschakeld

OpenAPI-specificatie is een industriestandaard voor het beschrijven van HTTP-API's en het integreren ervan in complexe bedrijfsprocessen of met derden. OpenAPI wordt veel ondersteund door alle cloudproviders en veel API-registers. Apps die OpenAPI-documenten van web-API's verzenden, hebben verschillende nieuwe mogelijkheden waarin deze API's kunnen worden gebruikt. In samenwerking met de onderhouders van het opensource-project Swashbuckle.AspNetCorebevat de ASP.NET Core-API-sjabloon een NuGet-afhankelijkheid van Swashbuckle-. Swashbuckle is een populair opensource NuGet-pakket waarmee OpenAPI-documenten dynamisch worden verzonden. Swashbuckle doet dit door introspectie uit te voeren op de API-controllers en het OpenAPI-document te genereren tijdens runtime of tijdens het bouwen met behulp van de Swashbuckle CLI.

In ASP.NET Core 5.0 schakelen de web-API-sjablonen standaard de OpenAPI-ondersteuning in. OpenAPI uitschakelen:

  • Vanaf de opdrachtregel:

      dotnet new webapi --no-openapi true

  • Vanuit Visual Studio: schakel OpenAPI-ondersteuning uitschakelenuit.

Alle .csproj bestanden die voor web-API-projecten zijn gemaakt, bevatten de Swashbuckle.AspNetCore NuGet-pakketreferentie.

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

De door de sjabloon gegenereerde code bevat code in Startup.ConfigureServices waarmee het genereren van OpenAPI-documenten wordt geactiveerd:

public void ConfigureServices(IServiceCollection services)
{

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

Met de methode Startup.Configure wordt de Swashbuckle middleware toegevoegd, waarmee het volgende mogelijk is:

  • Proces voor het genereren van documenten.
  • Swagger UI-pagina standaard in de ontwikkelmodus.

Met de door de sjabloon gegenereerde code wordt de beschrijving van de API niet per ongeluk weergegeven bij het publiceren naar productie.

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();
    });
}

Azure API Management Importeren

Wanneer ASP.NET Core API-projecten OpenAPI inschakelen, biedt visual Studio 2019 versie 16.8 en later automatisch een extra stap in de publicatiestroom. Ontwikkelaars die gebruikmaken van Azure API Management hebben de mogelijkheid om de API's automatisch te importeren in Azure API Management tijdens de publicatiestroom:

Importeren vs. publiceren in Azure API Management

Betere startervaring voor web-API-projecten

Als OpenAPI standaard is ingeschakeld, verbetert de startervaring voor apps (F5) voor web-API-ontwikkelaars aanzienlijk. Met ASP.NET Core 5.0 is de web-API-sjabloon vooraf geconfigureerd om de Swagger UI-pagina te laden. De Swagger UI-pagina bevat zowel de documentatie die is toegevoegd voor de gepubliceerde API en maakt het mogelijk om de API's met één klik te testen.

swagger/index.html weergave

Blazor

Prestatieverbeteringen

Voor .NET 5 hebben we aanzienlijke verbeteringen aangebracht in de runtimeprestaties van .NET WebAssembly met een specifieke focus op complexe UI-rendering en JSON-serialisatie. In onze prestatietests is Blazor WebAssembly in .NET 5 twee tot drie keer sneller voor de meeste scenario's. Zie ASP.NET Blog: ASP.NET Core-updates in .NET 5 Release Candidate 1voor meer informatie.

CSS-isolatie

Blazor ondersteunt nu het definiëren van CSS-stijlen die zijn gericht op een bepaald onderdeel. Onderdeelspecifieke CSS-stijlen maken het gemakkelijker om redeneren over de stijlen in een app en om onbedoelde bijwerkingen van globale stijlen te voorkomen. Zie ASP.NET Core Blazor CSS-isolatievoor meer informatie.

Nieuw InputFile-onderdeel

Met het InputFile-onderdeel kunt u een of meer bestanden lezen die door een gebruiker zijn geselecteerd voor uploaden. Zie voor meer informatie ASP.NET Core Blazor-bestandsupload.

Nieuwe InputRadio- en InputRadioGroup-onderdelen

Blazor beschikt over ingebouwde InputRadio- en InputRadioGroup-componenten waarmee gegevensbinding met groepen van keuzerondjes met geïntegreerde validatie wordt vereenvoudigd. Zie ASP.NET Core Blazor invoeronderdelenvoor meer informatie.

Onderdeelvirtualisatie

Verbeter de waargenomen prestaties van onderdeelrendering met behulp van de ingebouwde virtualisatieondersteuning van het Blazor framework. Zie ASP.NET Core Razor componentvirtualisatievoor meer informatie.

ondersteuning voor ontoggle evenementen

Blazor gebeurtenissen ondersteunen nu de ontoggle DOM-gebeurtenis. Zie ASP.NET Core Blazor event handlingvoor meer informatie.

De focus van de gebruikersinterface instellen in Blazor-apps

Gebruik de FocusAsync gemaksmethode voor elementverwijzingen om de focus van de gebruikersinterface op dat element in te stellen. Zie ASP.NET Core Blazor event handlingvoor meer informatie.

Aangepaste css-klassekenmerken voor validatie

Aangepaste css-klassekenmerken voor validatie zijn handig bij het integreren met CSS-frameworks, zoals Bootstrap. Zie ASP.NET Core Blazor formuliervalidatievoor meer informatie.

Ondersteuning voor IAsyncDisposable

Razor onderdelen ondersteunen nu de IAsyncDisposable-interface voor de asynchrone release van toegewezen resources.

JavaScript-isolatie en objectverwijzingen

Blazor maakt JavaScript-isolatie mogelijk in standaard JavaScript-modules. Zie JavaScript-functies aanroepen vanuit .NET-methoden in ASP.NET Core Blazorvoor meer informatie.

Formulieronderdelen ondersteunen weergavenamen

De volgende ingebouwde onderdelen ondersteunen weergavenamen met de parameter DisplayName:

  • InputDate
  • InputNumber
  • InputSelect

Zie ASP.NET Core Blazor forms overviewvoor meer informatie.

Parameters voor allesomvattende route

Catch-all route-parameters, die paden over meerdere mapgrenzen vangen, worden ondersteund in componenten. Zie ASP.NET Core Blazor routering en navigatievoor meer informatie.

Verbeteringen voor foutopsporing

De foutopsporing van Blazor WebAssembly-apps is verbeterd in ASP.NET Core 5.0. Daarnaast wordt foutopsporing nu ondersteund in Visual Studio voor Mac. Voor meer informatie, zie debuggen van ASP.NET Core Blazor-apps.

Microsoft Identity v2.0 en MSAL v2.0

Blazor beveiliging maakt nu gebruik van Microsoft Identity v2.0 (Microsoft.Identity.Web en Microsoft.Identity.Web.UI) en MSAL v2.0. Zie voor meer informatie de onderwerpen in de Blazor Beveiliging en Identity node.

Beveiligde browseropslag voor Blazor Server

Blazor Server apps kunnen nu gebruikmaken van ingebouwde ondersteuning voor het opslaan van de app-status in de browser die is beveiligd tegen manipulatie met behulp van ASP.NET Core-gegevensbeveiliging. Gegevens kunnen worden opgeslagen in lokale browseropslag of sessieopslag. Zie ASP.NET Core Blazor state managementvoor meer informatie.

Blazor WebAssembly vooraf renderen

De integratie van componenten is verbeterd in hostingmodellen en Blazor WebAssembly apps kunnen nu uitvoer vooraf op de server renderen.

Verbeteringen in bijsnijden en koppelen

Blazor WebAssembly voert IL-bijsnijden/koppelen uit tijdens een build om onnodige IL uit de uitvoer van de app te verwijderen. Met de release van ASP.NET Core 5.0 voert Blazor WebAssembly verbeterde trimming uit met extra configuratieopties. Zie voor meer informatie De trimmer configureren voor ASP.NET Core Blazor en Opties voor bijsnijden.

Browsercompatibiliteitsanalyse

Blazor WebAssembly-apps zijn gericht op de volledige reikwijdte van de .NET-API, maar niet alle .NET-API's worden op WebAssembly ondersteund vanwege de beperkingen van de sandbox in de browser. Niet-ondersteunde API's gooien PlatformNotSupportedException bij het uitvoeren op WebAssembly. Een platformcompatibiliteitsanalyse waarschuwt de ontwikkelaar wanneer de app API's gebruikt die niet worden ondersteund door de doelplatforms van de app. Voor meer informatie, zie onderdelen van ASP.NET Core Razor gebruiken vanuit een Razor klasse-bibliotheek (RCL).

Assemblies met laadtijdwinst

Blazor WebAssembly opstartprestaties van apps kunnen worden verbeterd door het laden van sommige toepassingsassembly's uit te stellen totdat deze zijn vereist. Zie Lazy load assembly's in ASP.NET Core Blazor WebAssemblyvoor meer informatie.

Bijgewerkte ondersteuning voor globalisatie

Globalisatieondersteuning is beschikbaar voor Blazor WebAssembly op basis van International Components for Unicode (ICU). Zie ASP.NET Core Blazor globalisatie en lokalisatievoor meer informatie.

gRPC

Er zijn veel performanceverbeteringen aangebracht in gRPC. Zie gRPC-prestatieverbeteringen in .NET 5voor meer informatie.

Zie Overzicht voor gRPC op .NETvoor meer informatie over gRPC.

SignalR

SignalR Hub-filters

SignalR Hub-filters, hubpijplijnen genoemd in ASP.NET SignalR, is een functie waarmee code kan worden uitgevoerd voor en nadat Hub-methoden worden aangeroepen. Het uitvoeren van code voor en na hub-methoden is vergelijkbaar met de manier waarop middleware code kan uitvoeren voor en na een HTTP-aanvraag. Veelgebruikte toepassingen zijn logboekregistratie, foutafhandeling en argumentvalidatie.

Zie Hubfilters gebruiken in ASP.NET Core-SignalRvoor meer informatie.

SignalR parallelle hubaanroepen

ASP.NET Core SignalR kan nu parallelle hub-aanroepen verwerken. Het standaardgedrag kan worden gewijzigd zodat clients meer dan één hubmethode tegelijk kunnen aanroepen:

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

Messagepack-ondersteuning toegevoegd in SignalR Java-client

Een nieuw pakket, com.microsoft.signalr.messagepack, voegt MessagePack-ondersteuning toe aan de SignalR Java-client. Als u het MessagePack-hubprotocol wilt gebruiken, voegt u .withHubProtocol(new MessagePackHubProtocol()) toe aan de opbouwfunctie voor verbindingen:

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

Kestrel

  • Opnieuw laadbare eindpunten via configuratie: Kestrel kan wijzigingen in de configuratie detecteren die zijn doorgegeven aan KestrelServerOptions.Configure en unbind van bestaande eindpunten en binden aan nieuwe eindpunten zonder dat een toepassing opnieuw hoeft te worden opgestart wanneer de parameter reloadOnChange is true. Wanneer u ConfigureWebHostDefaults of CreateDefaultBuildergebruikt, wordt Kestrel standaard gekoppeld aan de Kestrel configuratiesubsectie met reloadOnChange ingeschakeld. Apps moeten reloadOnChange: true doorgeven bij het aanroepen van KestrelServerOptions.Configure handmatig om herlaadbare eindpunten op te halen.

  • Verbeteringen in HTTP/2-antwoordheaders. Zie Prestatieverbeteringen in de volgende sectie voor meer informatie.

  • Ondersteuning voor extra eindpunttypen in het sockettransport: Aanvullend op de nieuwe API die is geïntroduceerd in System.Net.Sockets, maakt het standaardtransport van sockets in Kestrel binding mogelijk met zowel bestaande bestandskoppelingen als Unix-domeinsockets. Ondersteuning voor binding met bestaande bestandsingangen maakt het mogelijk om de bestaande Systemd-integratie te gebruiken zonder dat het libuv transport is vereist.

  • Aangepaste headercodering in Kestrel: apps kunnen opgeven welke Encoding moet worden gebruikt om binnenkomende headers te interpreteren op basis van de headernaam in plaats van standaard UTF-8 te gebruiken. Stel de eigenschap Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelector in om op te geven welke codering moet worden gebruikt:

    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>();
      });

Kestrel eindpuntspecifieke opties via configuratie

Er is ondersteuning toegevoegd voor het configureren van de eindpuntspecifieke opties van Kestrelvia configuratie-. De eindpuntspecifieke configuraties omvatten het volgende:

  • GEBRUIKTE HTTP-protocollen
  • GEBRUIKTE TLS-protocollen
  • Certificaat geselecteerd
  • Klantcertificaatmodus

Met configuratie kunt u opgeven welk certificaat is geselecteerd op basis van de opgegeven servernaam. De servernaam maakt deel uit van de SNI-extensie (Server Name Indication) naar het TLS-protocol, zoals aangegeven door de client. Kestrel's configuratie ondersteunt ook een jokertekenvoorvoegsel in de hostnaam.

In het volgende voorbeeld ziet u hoe u eindpunt-specifieke instellingen kunt definiëren door middel van een configuratiebestand.

{
  "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",
          }
        }
      }
    }
  }
}

Servernaamindicatie (SNI) is een TLS-extensie om een virtueel domein op te nemen als onderdeel van SSL-onderhandeling. Wat dit effectief betekent, is dat de virtuele domeinnaam of een hostnaam kan worden gebruikt om het eindpunt van het netwerk te identificeren.

Prestatieverbeteringen

HTTP/2

  • Aanzienlijke verlagingen van toewijzingen in het HTTP/2-codepad.

  • Ondersteuning voor dynamische HPack-compressie van HTTP/2-antwoordheaders in Kestrel. Zie Kopteksttabelgrootte en HPACK: de stille moordenaar (functie) van HTTP/2voor meer informatie.

  • HTTP/2 PING-frames verzenden: HTTP/2 heeft een mechanisme voor het verzenden van PING-frames om ervoor te zorgen dat een niet-actieve verbinding nog steeds functioneel is. Het garanderen van een levensvatbare verbinding is vooral handig bij het werken met langlevende streams die vaak inactief zijn, maar alleen af en toe activiteit zien, bijvoorbeeld gRPC-streams. Apps kunnen periodieke PING-frames in Kestrel verzenden door limieten in te stellen voor 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>();
      });

Containers

Vóór .NET 5.0 vereiste het bouwen en publiceren van een Dockerfile- voor een ASP.NET Core-app dat de volledige .NET Core SDK en de ASP.NET Core-afbeelding werden opgehaald. Met deze release wordt het ophalen van de SDK-installatiekopieën beperkt en worden de bytes die zijn opgehaald voor de ASP.NET Core-installatiekopie grotendeels geëlimineerd. Zie deze opmerking bij gitHub-problemenvoor meer informatie.

Verificatie en autorisatie

Microsoft Entra ID-verificatie met Microsoft.Identity. Web

De ASP.NET Core-projectsjablonen kunnen nu worden geïntegreerd met Microsoft.Identity.Web om verificatie af te handelen met Microsoft Entra ID. De Microsoft.Identity. Webpakket biedt:

  • Een betere ervaring voor verificatie via Microsoft Entra ID.
  • Een eenvoudigere manier om namens uw gebruikers toegang te krijgen tot Azure-resources, waaronder Microsoft Graph. Zie het Microsoft.Identity. Webvoorbeeld, dat begint met een eenvoudige aanmelding en voortgaat naar multi-tenancy, gebruikmakend van Azure-API's, Microsoft Graph en om uw eigen API's te beveiligen. Microsoft.Identity.Web is beschikbaar naast .NET 5.

Anonieme toegang tot een eindpunt toestaan

Met de AllowAnonymous-extensiemethode is anonieme toegang tot een eindpunt toegestaan:

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();
    });
}

Aangepaste verwerking van autorisatiefouten

Aangepaste verwerking van autorisatiefouten is nu eenvoudiger met de nieuwe IAuthorizationMiddlewareResultHandler interface die wordt aangeroepen door de autorisatieMiddleware. De standaard implementatie blijft hetzelfde, maar een aangepaste handler kan worden geregistreerd in [Afhankelijkheidsinjectie, waardoor aangepaste HTTP-antwoorden kunnen worden toegestaan op basis van waarom autorisatie is mislukt. Zie dit voorbeeld dat het gebruik van de IAuthorizationMiddlewareResultHandlerlaat zien.

Autorisatie bij het gebruik van eindpuntroutering

Autorisatie bij het gebruik van eindpuntroutering ontvangt nu de HttpContext in plaats van de eindpuntinstantie. Hierdoor heeft de autorisatie-middleware toegang tot de RouteData en andere eigenschappen van de HttpContext die niet toegankelijk waren via de klasse Endpoint. Het eindpunt kan worden opgehaald uit de context met behulp van context. GetEndpoint.

Op rollen gebaseerd toegangsbeheer met Kerberos-verificatie en LDAP op Linux

Zie Kerberos-verificatie en op rollen gebaseerd toegangsbeheer (RBAC)

API-verbeteringen

JSON-extensiemethoden voor HttpRequest en HttpResponse

JSON-gegevens kunnen worden gelezen en geschreven vanuit een HttpRequest en HttpResponse met behulp van de nieuwe ReadFromJsonAsync- en WriteAsJsonAsync-extensiemethoden. Deze extensiemethoden gebruiken de System.Text.Json serializer om de JSON-gegevens te verwerken. De nieuwe HasJsonContentType extensiemethode kan ook controleren of een aanvraag een JSON-inhoudstype heeft.

De JSON-extensiemethoden kunnen worden gecombineerd met eindpuntroutering om JSON-API's te maken in een programmeerstijl die we route naar codeaanroepen. Het is een nieuwe optie voor ontwikkelaars die eenvoudige JSON-API's willen maken op een lichtgewicht manier. Een web-app met slechts een handvol eindpunten kan er bijvoorbeeld voor kiezen om route naar code te gebruiken in plaats van de volledige functionaliteit van 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

De standaardindeling voor System.Diagnostics.Activity wordt nu standaard ingesteld op de W3C-indeling. Dit maakt gedistribueerde traceringsondersteuning in ASP.NET Core standaard compatibel met meer frameworks.

FromBodyAttribute

FromBodyAttribute biedt nu ondersteuning voor het configureren van een optie waarmee deze parameters of eigenschappen als optioneel kunnen worden beschouwd:

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

Diverse verbeteringen

We zijn begonnen met het toepassen van nullable annotaties op ASP.NET Core-assembly's. We zijn van plan aantekeningen te maken voor het grootste deel van het algemene openbare API-oppervlak van het .NET 5-framework.

Activering van opstartklasse beheren

Er is een extra UseStartup overbelasting toegevoegd waarmee een app een fabrieksmethode kan bieden voor het beheren van Startup klasseactivering. Het controleren van de activatie van Startup-klassen is nuttig om extra parameters door te geven aan Startup, die samen met de host wordt geïnitialiseerd.

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();
    }
}

Automatisch vernieuwen met dotnet-horloge

Als u in .NET 5 dotnet watch uitvoert op een ASP.NET Core-project, wordt de standaardbrowser gestart en wordt de browser automatisch vernieuwd wanneer er wijzigingen in de code worden aangebracht. Dit betekent dat u het volgende kunt doen:

  • Open een ASP.NET Core-project in een teksteditor.
  • Voer dotnet watchuit.
  • Focus op de codewijzigingen terwijl de tooling het opnieuw opbouwen, opnieuw opstarten en opnieuw laden van de app afhandelt.

Console Logger Formatter

Er zijn verbeteringen aangebracht aan de console-logboekprovider in de Microsoft.Extensions.Logging-bibliotheek. Ontwikkelaars kunnen nu een aangepaste ConsoleFormatter implementeren om volledige controle uit te oefenen over het opmaken en kleuren van de console-uitvoer. De formatter-API's maken rijke opmaak mogelijk door een subset van de VT-100-escapereeksen te implementeren. VT-100 wordt ondersteund door de meeste moderne terminals. De consolelogger kan escapereeksen parseren op niet-ondersteunde terminals, zodat ontwikkelaars één formatter voor alle terminals kunnen ontwerpen.

JSON Console Logger

Naast ondersteuning voor aangepaste formatters, hebben we ook een ingebouwde JSON-indeling toegevoegd waarmee gestructureerde JSON-logboeken naar de console worden verzonden. De volgende code laat zien hoe u kunt overschakelen van de standaardlogger naar 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>();
  });

Logboekberichten die naar de console worden verzonden, zijn opgemaakt met 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}"
  }
}