Udostępnij za pośrednictwem

Co nowego w programie ASP.NET Core 5.0

  • Artykuł

W tym artykule przedstawiono najważniejsze zmiany w programie ASP.NET Core 5.0 z linkami do odpowiedniej dokumentacji.

ASP.NET Core MVC i Razor ulepszenia

Powiązanie modelu DateTime jako UTC

Powiązanie modelu obsługuje teraz powiązanie ciągów czasu UTC z DateTime. Jeśli żądanie zawiera ciąg czasu UTC, powiązanie modelu wiąże je z godziną UTC DateTime. Na przykład następujący ciąg czasu jest powiązany z utc DateTime: https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z

Powiązanie modelu i walidacja z typami rekordów języka C# 9

Typy rekordów języka C# 9 mogą być używane z powiązaniem modelu w kontrolerze MVC lub na Razor stronie. Typy rekordów to dobry sposób modelowania danych przesyłanych za pośrednictwem sieci.

Na przykład następujące PersonController elementy używają typu rekordu Person z powiązaniem modelu i weryfikacją formularza:

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

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

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

Plik 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" />

Ulepszenia elementu DynamicRouteValueTransformer

ASP.NET Core 3.1 wprowadzony DynamicRouteValueTransformer jako sposób używania niestandardowego punktu końcowego do dynamicznego wybierania akcji kontrolera MVC lub Razor strony. ASP.NET aplikacje Core 5.0 mogą przekazywać stan do obiektu DynamicRouteValueTransformer i filtrować wybrany zestaw punktów końcowych.

Różne

  • Atrybut [Compare] można zastosować do właściwości w Razor modelu strony.
  • Parametry i właściwości powiązane z treścią są domyślnie uznawane za wymagane.

Internetowy interfejs API

Specyfikacja interfejsu OpenAPI domyślnie włączona

Specyfikacja interfejsu OpenAPI jest standardem branżowym opisującym interfejsy API HTTP i integrowaniem ich ze złożonymi procesami biznesowymi lub z firmami trzecimi. Interfejs OpenAPI jest powszechnie obsługiwany przez wszystkich dostawców usług w chmurze i wiele rejestrów interfejsów API. Aplikacje emitujące dokumenty OpenAPI z internetowych interfejsów API mają różne nowe możliwości, w których można używać tych interfejsów API. We współpracy z opiekunami projektu open source Swashbuckle.AspNetCore szablon interfejsu API platformy ASP.NET Core zawiera zależność NuGet od pakietu Swashbuckle. Swashbuckle to popularny pakiet NuGet typu open source, który dynamicznie emituje dokumenty OpenAPI. Pakiet Swashbuckle wykonuje to przez introspekcja kontrolerów interfejsu API i generowanie dokumentu OpenAPI w czasie wykonywania lub w czasie kompilacji przy użyciu interfejsu wiersza polecenia programu Swashbuckle.

W ASP.NET Core 5.0 szablony internetowego interfejsu API domyślnie obsługują interfejs OpenAPI. Aby wyłączyć interfejs OpenAPI:

  • Za pomocą wiersza polecenia:

      dotnet new webapi --no-openapi true

  • W programie Visual Studio: usuń zaznaczenie pola wyboru Włącz obsługę interfejsu OpenAPI.

Wszystkie .csproj pliki utworzone dla projektów internetowego interfejsu API zawierają dokumentację pakietu NuGet Swashbuckle.AspNetCore .

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

Wygenerowany kod szablonu zawiera kod, który Startup.ConfigureServices aktywuje generowanie dokumentu OpenAPI:

public void ConfigureServices(IServiceCollection services)
{

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

Metoda Startup.Configure dodaje oprogramowanie pośredniczące Swashbuckle, które umożliwia:

  • Proces generowania dokumentów.
  • Strona interfejsu użytkownika struktury Swagger domyślnie w trybie programowania.

Wygenerowany kod szablonu nie uwidacznia przypadkowo opisu interfejsu API podczas publikowania w środowisku produkcyjnym.

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

Importowanie usługi Azure API Management

W przypadku włączenia interfejsu OpenAPI projektów interfejsu API core ASP.NET program Visual Studio 2019 w wersji 16.8 lub nowszej automatycznie oferuje dodatkowy krok w przepływie publikowania. Deweloperzy korzystający z usługi Azure API Management mogą automatycznie importować interfejsy API do usługi Azure API Management podczas przepływu publikowania:

Importowanie publikowania programu VS w usłudze Azure API Management

Lepsze środowisko uruchamiania projektów internetowego interfejsu API

Po włączeniu interfejsu OpenAPI środowisko uruchamiania aplikacji (F5) dla deweloperów internetowego interfejsu API znacznie się poprawia. W przypadku platformy ASP.NET Core 5.0 szablon internetowego interfejsu API jest wstępnie skonfigurowany do ładowania strony interfejsu użytkownika struktury Swagger. Strona interfejsu użytkownika struktury Swagger zawiera zarówno dokumentację dodaną dla opublikowanego interfejsu API, jak i umożliwia testowanie interfejsów API za pomocą jednego kliknięcia.

widok swagger/index.html

Blazor

usprawnienia dotyczące wydajności

W przypadku platformy .NET 5 wprowadziliśmy znaczące ulepszenia wydajności środowiska uruchomieniowego zestawu WebAssembly platformy .NET, koncentrując się na złożonym renderowaniu interfejsu użytkownika i serializacji JSON. W naszych testach Blazor WebAssembly wydajnościowych platforma .NET 5 jest od dwóch do trzech razy szybsza w przypadku większości scenariuszy. Aby uzyskać więcej informacji, zobacz blog ASP.NET: ASP.NET Aktualizacje podstawowe w programie .NET 5 Release Candidate 1.

Izolacja CSS

Blazor Teraz obsługuje definiowanie stylów CSS, które są ograniczone do danego składnika. Style CSS specyficzne dla składników ułatwiają wnioskowanie o stylach w aplikacji i unikanie niezamierzonych skutków ubocznych stylów globalnych. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor CSS izolacja.

Nowy InputFile składnik

Składnik InputFile umożliwia odczytywanie co najmniej jednego pliku wybranego przez użytkownika do przekazania. Aby uzyskać więcej informacji, zobacz ASP.NET Core file uploads (Przekazywanie plików ASP.NET CoreBlazor).

Nowe InputRadio i InputRadioGroup składniki

Blazor ma wbudowane InputRadio składniki InputRadioGroup , które upraszczają powiązanie danych z grupami przycisków radiowych ze zintegrowaną walidacją. Aby uzyskać więcej informacji, zobacz ASP.NET Podstawowe Blazor składniki wejściowe.

Wirtualizacja składników

Zwiększ postrzeganą wydajność renderowania składników przy użyciu wbudowanej Blazor obsługi wirtualizacji platformy. Aby uzyskać więcej informacji, zobacz ASP.NET Core component virtualization (Wirtualizacja składników podstawowego systemu ASP.NET CoreRazor).

ontoggle obsługa zdarzeń

Blazor zdarzenia obsługują ontoggle teraz zdarzenie DOM. Aby uzyskać więcej informacji, zobacz obsługa zdarzeń ASP.NET CoreBlazor.

Ustawianie fokusu interfejsu użytkownika w Blazor aplikacjach

Użyj metody wygody FocusAsync w odwołaniach do elementów, aby ustawić fokus interfejsu użytkownika na ten element. Aby uzyskać więcej informacji, zobacz obsługa zdarzeń ASP.NET CoreBlazor.

Niestandardowe atrybuty klasy CSS walidacji

Niestandardowe atrybuty klasy CSS walidacji są przydatne podczas integrowania z platformami CSS, takimi jak Bootstrap. Aby uzyskać więcej informacji, zobacz sprawdzanie poprawności formularzy ASP.NET CoreBlazor.

Obsługa interfejsu IAsyncDisposable

Razor składniki obsługują IAsyncDisposable teraz interfejs dla asynchronicznej wersji przydzielonych zasobów.

Izolacja języka JavaScript i odwołania do obiektów

Blazor umożliwia izolację języka JavaScript w standardowych modułach Języka JavaScript. Aby uzyskać więcej informacji, zobacz Wywoływanie funkcji języka JavaScript z metod platformy .NET na platformie ASP.NET Core Blazor.

Składniki formularza obsługują nazwę wyświetlaną

Następujące wbudowane składniki obsługują nazwy wyświetlane z parametrem DisplayName :

  • InputDate
  • InputNumber
  • InputSelect

Aby uzyskać więcej informacji, zobacz omówienie formularzy ASP.NET CoreBlazor.

Parametry trasy catch-all

Parametry trasy catch-all, które przechwytują ścieżki w wielu granicach folderów, są obsługiwane w składnikach. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor routing i nawigacja.

Ulepszenia debugowania

Ulepszono debugowanie Blazor WebAssembly aplikacji w ASP.NET Core 5.0. Ponadto debugowanie jest teraz obsługiwane w Visual Studio dla komputerów Mac. Aby uzyskać więcej informacji, zobacz Debugowanie aplikacji ASP.NET CoreBlazor.

Microsoft Identity v2.0 i MSAL w wersji 2.0

Blazor zabezpieczenia korzystają teraz z platform Microsoft Identity w wersji 2.0 (Microsoft.Identity.Web i Microsoft.Identity.Web.UI) oraz biblioteki MSAL w wersji 2.0. Aby uzyskać więcej informacji, zobacz tematy w temacie Blazor Zabezpieczenia i Identity węzeł.

Magazyn chronionej przeglądarki dla programu Blazor Server

Blazor Server Aplikacje mogą teraz używać wbudowanej obsługi przechowywania stanu aplikacji w przeglądarce, która została chroniona przed manipulowaniem przy użyciu ochrony danych ASP.NET Core. Dane mogą być przechowywane w magazynie przeglądarki lokalnej lub w magazynie sesji. Aby uzyskać więcej informacji, zobacz zarządzanie stanem ASP.NET CoreBlazor.

Blazor WebAssembly prerendering

Integracja składników jest ulepszona w modelach hostingu, a Blazor WebAssembly aplikacje mogą teraz wstępnie prerender danych wyjściowych na serwerze.

Ulepszenia przycinania/łączenia

Blazor WebAssembly Wykonuje przycinanie/łączenie języka pośredniego (IL) podczas kompilacji w celu przycinania niepotrzebnego il z zestawów wyjściowych aplikacji. W wersji ASP.NET Core 5.0 Blazor WebAssembly zapewnia ulepszone przycinanie z dodatkowymi opcjami konfiguracji. Aby uzyskać więcej informacji, zobacz Configure the Trimmer for ASP.NET Core and Trimming options (Konfigurowanie trymmeru dla opcji ASP.NET Core Blazor i Trimming).

Analizator zgodności przeglądarki

Blazor WebAssembly aplikacje są przeznaczone dla pełnego obszaru powierzchni interfejsu API platformy .NET, ale nie wszystkie interfejsy API platformy .NET są obsługiwane w zestawie WebAssembly z powodu ograniczeń piaskownicy przeglądarki. Nieobsługiwane interfejsy API zgłaszane PlatformNotSupportedException podczas uruchamiania w zestawie WebAssembly. Analizator zgodności platformy ostrzega dewelopera, gdy aplikacja korzysta z interfejsów API, które nie są obsługiwane przez platformy docelowe aplikacji. Aby uzyskać więcej informacji, zobacz Korzystanie ze składników platformy ASP.NET Core Razor z biblioteki klas Razor (RCL).

Zestawy ładowania z opóźnieniem

Blazor WebAssembly Wydajność uruchamiania aplikacji można poprawić przez odroczenie ładowania niektórych zestawów aplikacji do momentu ich wymagania. Aby uzyskać więcej informacji, zobacz Ładowanie zestawów z opóźnieniem w programie ASP.NET Core Blazor WebAssembly.

Zaktualizowana obsługa globalizacji

Obsługa globalizacji jest dostępna na Blazor WebAssembly podstawie międzynarodowych składników dla standardu Unicode (ICU). Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor globalizacji i lokalizacji.

gRPC

W gRPC wprowadzono wiele ulepszeń preformcji. Aby uzyskać więcej informacji, zobacz gRPC performance improvements in .NET 5 (Ulepszenia wydajności usługi gRPC na platformie .NET 5).

Aby uzyskać więcej informacji o gRPC, zobacz Overview for gRPC on .NET (Omówienie usługi gRPC na platformie .NET).

SignalR

SignalR Filtry koncentratora

SignalR Filtry koncentratora nazywane potokami koncentratora w ASP.NET SignalRto funkcja umożliwiająca uruchamianie kodu przed wywołaniami metod centrum i po nim. Uruchamianie kodu przed wywołaniami metod centrum i po nim jest podobne do tego, jak oprogramowanie pośredniczące ma możliwość uruchamiania kodu przed żądaniem HTTP i po nim. Typowe zastosowania obejmują rejestrowanie, obsługę błędów i walidację argumentów.

Aby uzyskać więcej informacji, zobacz Use hub filters in ASP.NET Core (Używanie filtrów centrum w programie ASP.NET Core SignalR).

SignalR wywołania koncentratora równoległego

ASP.NET Core SignalR jest teraz w stanie obsługiwać wywołania koncentratora równoległego. Zachowanie domyślne można zmienić, aby umożliwić klientom wywoływanie więcej niż jednej metody centrum jednocześnie:

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

Dodano obsługę pakietu Messagepack w SignalR kliencie Java

Nowy pakiet com.microsoft .signalr. messagepack dodaje obsługę pakietu MessagePack do SignalR klienta Java. Aby użyć protokołu centrum MessagePack, dodaj .withHubProtocol(new MessagePackHubProtocol()) go do konstruktora połączeń:

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

Kestrel

  • Ponowne ładowanie punktów końcowych za pośrednictwem konfiguracji: Kestrel umożliwia wykrywanie zmian konfiguracji przekazanych do KestrelServerOptions.Configure and unbind z istniejących punktów końcowych i wiązać się z nowymi punktami końcowymi bez konieczności ponownego uruchamiania aplikacji, gdy reloadOnChange parametr ma wartość true. Domyślnie w przypadku używania polecenia ConfigureWebHostDefaults lub CreateDefaultBuilderKestrel element wiąże się z podsekcją konfiguracji "Kestrel" z włączoną obsługąreloadOnChange. Aplikacje muszą być przekazywane reloadOnChange: true podczas ręcznego wywoływania KestrelServerOptions.Configure w celu uzyskania punktów końcowych z możliwością ponownego ładowania.

  • Ulepszenia nagłówków odpowiedzi HTTP/2. Aby uzyskać więcej informacji, zobacz Ulepszenia wydajności w następnej sekcji.

  • Obsługa dodatkowych typów punktów końcowych w transporcie gniazd: dodanie do nowego interfejsu API wprowadzonego w System.Net.Socketssystemie , domyślny transport gniazd w Kestrel programie umożliwia powiązanie zarówno z istniejącymi dojściami plików, jak i gniazdami domeny systemu Unix. Obsługa powiązania z istniejącymi uchwytami plików umożliwia korzystanie z istniejącej Systemd integracji bez konieczności libuv transportu.

  • Dekodowanie nagłówka niestandardowego w programie Kestrel: Aplikacje mogą określać, które Encoding z nich mają być interpretowane do interpretowania nagłówków przychodzących na podstawie nazwy nagłówka zamiast domyślnej wartości UTF-8. Ustaw właściwość , Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelector aby określić, które kodowanie ma być używane:

    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 opcje specyficzne dla punktu końcowego za pośrednictwem konfiguracji

Dodano obsługę konfigurowania Kestrelopcji specyficznych dla punktu końcowego za pośrednictwem konfiguracji. Konfiguracje specyficzne dla punktu końcowego obejmują następujące elementy:

  • Używane protokoły HTTP
  • Używane protokoły TLS
  • Wybrany certyfikat
  • Tryb certyfikatu klienta

Konfiguracja umożliwia określenie wybranego certyfikatu na podstawie określonej nazwy serwera. Nazwa serwera jest częścią rozszerzenia SNI (Server Name Indication) do protokołu TLS wskazanego przez klienta. KestrelKonfiguracja programu obsługuje również prefiks wieloznaczny w nazwie hosta.

W poniższym przykładzie pokazano, jak określić punkt końcowy specyficzny dla danego punktu końcowego przy użyciu pliku konfiguracji:

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

Wskazanie nazwy serwera (SNI) to rozszerzenie protokołu TLS do uwzględnienia domeny wirtualnej w ramach negocjacji protokołu SSL. Oznacza to, że nazwa domeny wirtualnej lub nazwa hosta może służyć do identyfikowania punktu końcowego sieci.

usprawnienia dotyczące wydajności

HTTP/2

  • Znaczne zmniejszenie alokacji w ścieżce kodu HTTP/2.

  • Obsługa dynamicznej kompresji HPack nagłówków odpowiedzi HTTP/2 w pliku Kestrel. Aby uzyskać więcej informacji, zobacz Rozmiar tabeli nagłówka i HPACK: cichy zabójca (funkcja) http/2.

  • Wysyłanie ramek HTTP/2 PING: PROTOKÓŁ HTTP/2 ma mechanizm wysyłania ramek PING w celu zapewnienia, że bezczynne połączenie jest nadal funkcjonalne. Zapewnienie opłacalnego połączenia jest szczególnie przydatne podczas pracy ze strumieniami długotrwałymi, które są często bezczynne, ale tylko sporadycznie widzą działania, na przykład strumienie gRPC. Aplikacje mogą wysyłać okresowe ramki PING, Kestrel ustawiając limity dla elementu 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>();
      });

Kontenery

Przed platformą .NET 5.0 kompilowanie i publikowanie pliku Dockerfile dla aplikacji ASP.NET Core wymaga ściągnięcia całego zestawu .NET Core SDK i obrazu platformy ASP.NET Core. W tej wersji ściąganie bajtów obrazów zestawu SDK jest zmniejszane, a bajty pobierane dla obrazu ASP.NET Core są w dużej mierze wyeliminowane. Aby uzyskać więcej informacji, zobacz ten komentarz dotyczący problemu w usłudze GitHub.

Uwierzytelnianie i autoryzacja

Microsoft Entra ID authentication with Microsoft.Identity. Sieć

Szablony projektów ASP.NET Core są teraz zintegrowane z usługą Microsoft.Identity.Web w celu obsługi uwierzytelniania za pomocą identyfikatora Entra firmy Microsoft. Microsoft .Identity. Pakiet internetowy zapewnia:

  • Lepsze środowisko uwierzytelniania za pomocą identyfikatora Entra firmy Microsoft.
  • Łatwiejszy sposób uzyskiwania dostępu do zasobów platformy Azure w imieniu użytkowników, w tym programu Microsoft Graph. Zobacz Microsoft .Identity. Przykład internetowy, który rozpoczyna się od podstawowego logowania i przechodzi przez wiele dzierżaw, przy użyciu interfejsów API platformy Azure, przy użyciu programu Microsoft Graph i ochrony własnych interfejsów API. Microsoft.Identity.Web jest dostępny wraz z platformą .NET 5.

Zezwalaj na anonimowy dostęp do punktu końcowego

AllowAnonymous Metoda rozszerzenia umożliwia anonimowy dostęp do punktu końcowego:

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

Niestandardowa obsługa błędów autoryzacji

Niestandardowa obsługa błędów autoryzacji jest teraz łatwiejsza w przypadku nowego interfejsu IAuthorizationMiddlewareResultHandler wywoływanego przez oprogramowanie pośredniczące autoryzacji. Domyślna implementacja pozostaje taka sama, ale niestandardowa procedura obsługi może być zarejestrowana w lokalizacji [Wstrzykiwanie zależności, co umożliwia niestandardowe odpowiedzi HTTP na podstawie przyczyny niepowodzenia autoryzacji. Zobacz ten przykład , który demonstruje użycie obiektu IAuthorizationMiddlewareResultHandler.

Autoryzacja podczas korzystania z routingu punktu końcowego

Autoryzacja podczas korzystania z routingu punktu końcowego odbiera HttpContext teraz wystąpienie punktu końcowego zamiast wystąpienia punktu końcowego. Dzięki temu oprogramowanie pośredniczące autoryzacji może uzyskać dostęp do RouteData właściwości i innych elementów HttpContext , które nie były dostępne, choć Endpoint klasa. Punkt końcowy można pobrać z kontekstu przy użyciu kontekstu. GetEndpoint.

Kontrola dostępu oparta na rolach przy użyciu uwierzytelniania Kerberos i protokołu LDAP w systemie Linux

Zobacz Uwierzytelnianie Kerberos i kontrola dostępu oparta na rolach (RBAC)

Ulepszenia interfejsu API

Metody rozszerzenia JSON dla obiektów HttpRequest i HttpResponse

Dane JSON można odczytywać i zapisywać na podstawie HttpRequest metody i HttpResponse przy użyciu nowych ReadFromJsonAsync metod rozszerzeń.WriteAsJsonAsync Te metody rozszerzenia używają serializatora System.Text.Json do obsługi danych JSON. Nowa HasJsonContentType metoda rozszerzenia może również sprawdzić, czy żądanie ma typ zawartości JSON.

Metody rozszerzenia JSON można połączyć z routingiem punktów końcowych w celu utworzenia interfejsów API JSON w stylu programowania, który wywołujemy jako trasę do kodu. Jest to nowa opcja dla deweloperów, którzy chcą tworzyć podstawowe interfejsy API JSON w uproszczony sposób. Na przykład aplikacja internetowa, która ma tylko kilka punktów końcowych, może użyć trasy do kodu, a nie pełnej funkcjonalności 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

Domyślny format dla System.Diagnostics.Activity teraz jest domyślnie formatem W3C. Dzięki temu obsługa śledzenia rozproszonego w ASP.NET Core jest domyślnie współdziałana z większą możliwą obsługą struktur.

FromBodyAttribute

FromBodyAttribute Teraz obsługuje konfigurowanie opcji, która umożliwia rozważenie tych parametrów lub właściwości jako opcjonalnych:

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

Różne ulepszenia

Zaczęliśmy stosować adnotacje dopuszczające wartość null do zestawów ASP.NET Core. Planujemy dodać adnotację do większości typowych publicznych powierzchni interfejsów API platformy .NET 5.

Kontrolowanie aktywacji klasy uruchamiania

Dodano dodatkowe UseStartup przeciążenie, które umożliwia aplikacji zapewnienie metody fabrycznej do kontrolowania Startup aktywacji klas. Kontrolowanie Startup aktywacji klasy jest przydatne do przekazywania dodatkowych parametrów do Startup , które są inicjowane wraz z hostem:

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

Automatyczne odświeżanie za pomocą zegarka dotnet

Na platformie .NET 5 uruchomienie zegarka dotnet w projekcie ASP.NET Core powoduje uruchomienie domyślnej przeglądarki i automatyczne odświeżenie przeglądarki w miarę wprowadzania zmian w kodzie. Oznacza to, że można wykonywać następujące czynności:

  • Otwórz projekt ASP.NET Core w edytorze tekstów.
  • Uruchom program dotnet watch.
  • Skoncentruj się na zmianach kodu, gdy narzędzie obsługuje ponowne kompilowanie, ponowne uruchamianie i ponowne ładowanie aplikacji.

Program formatujący rejestratora konsoli

Wprowadzono ulepszenia dostawcy dzienników konsoli w bibliotece Microsoft.Extensions.Logging . Deweloperzy mogą teraz zaimplementować niestandardowy ConsoleFormatter element umożliwiający wykonywanie pełnej kontroli nad formatowaniem i kolorowaniem danych wyjściowych konsoli. Interfejsy API formatowania umożliwiają sformatowanie przez zaimplementowanie podzestawu sekwencji ucieczki VT-100. VT-100 jest obsługiwany przez większość nowoczesnych terminali. Rejestrator konsoli może analizować sekwencje ucieczki w nieobsługiwanych terminalach, dzięki czemu deweloperzy mogą tworzyć jeden formater dla wszystkich terminali.

Rejestrator konsoli JSON

Oprócz obsługi niestandardowych formatów dodaliśmy również wbudowany formater JSON, który emituje strukturalne dzienniki JSON do konsoli. Poniższy kod pokazuje, jak przełączyć się z domyślnego rejestratora do formatu 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>();
  });

Komunikaty dziennika emitowane do konsoli są sformatowane w formacie 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}"
  }
}