Udostępnij za pośrednictwem

Co nowego w programie ASP.NET Core 3.0

  • Artykuł

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

Blazor

Blazor to nowa struktura w programie ASP.NET Core do tworzenia interaktywnego internetowego interfejsu użytkownika po stronie klienta za pomocą platformy .NET:

  • Tworzenie zaawansowanych interaktywnych interfejsów użytkownika przy użyciu języka C#.
  • Udostępnianie logiki aplikacji po stronie serwera i po stronie klienta napisanej na platformie .NET.
  • Renderowanie interfejsu użytkownika jako kodu HTML i CSS w celu obsługi w szerokiej gamie przeglądarek, w tym przeglądarek mobilnych.

Blazor obsługiwane scenariusze platformy:

  • Składniki interfejsu użytkownika wielokrotnego użytku (Razor składniki)
  • Routing po stronie klienta
  • Układy składników
  • Obsługa wstrzykiwania zależności
  • Formularze i walidacja
  • Dostarczanie Razor składników w Razor bibliotekach klas
  • Międzyoperacyjność w języku JavaScript

Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor.

Blazor Server

Blazor Rozdziela logikę renderowania składników z sposobu stosowania aktualizacji interfejsu użytkownika. Serwer Blazor Server zapewnia obsługę hostowania składników Razor na serwerze w aplikacji ASP.NET Core. Aktualizacje interfejsu użytkownika są obsługiwane za pośrednictwem połączenia SignalR. Blazor Server program jest obsługiwany w programie ASP.NET Core 3.0.

Blazor WebAssembly (Wersja zapoznawcza)

Blazor aplikacje można również uruchamiać bezpośrednio w przeglądarce przy użyciu środowiska uruchomieniowego platformy .NET opartego na zestawie WebAssembly. Blazor WebAssembly jest w wersji zapoznawczej i nie jest obsługiwany w programie ASP.NET Core 3.0. Blazor WebAssembly będzie obsługiwany w przyszłej wersji ASP.NET Core.

Składniki Razor

Blazor aplikacje są tworzone na podstawie składników. Składniki są fragmentami samodzielnego interfejsu użytkownika, takimi jak strona, okno dialogowe lub formularz. Składniki to normalne klasy platformy .NET, które definiują logikę renderowania interfejsu użytkownika i programy obsługi zdarzeń po stronie klienta. Możesz tworzyć zaawansowane interaktywne aplikacje internetowe bez języka JavaScript.

Składniki w programie Blazor są zwykle tworzone przy użyciu Razor składni, naturalnej mieszanki języków HTML i C#. Razor składniki są podobne do Razor widoków Pages i MVC, w których oba te składniki używają polecenia Razor. W przeciwieństwie do stron i widoków, które są oparte na modelu odpowiedzi na żądanie, składniki są używane specjalnie do obsługi kompozycji interfejsu użytkownika.

gRPC

gRPC:

  • Jest popularną platformą RPC o wysokiej wydajności (zdalne wywołanie procedury).

  • Oferuje przegrzane podejście oparte na umowie pierwszej do opracowywania interfejsów API.

  • Korzysta z nowoczesnych technologii, takich jak:

    • Protokół HTTP/2 do transportu.
    • Bufory protokołu jako język opisu interfejsu.
    • Format serializacji binarnej.

  • Udostępnia funkcje, takie jak:

    • Uwierzytelnianie
    • Dwukierunkowa kontrola przesyłania strumieniowego i przepływu.
    • Anulowanie i przekroczenia limitu czasu.

Funkcje gRPC w systemie ASP.NET Core 3.0 obejmują:

  • Grpc.AspNetCore: platforma ASP.NET Core do hostowania usług gRPC. gRPC w systemie ASP.NET Core integruje się ze standardowymi funkcjami ASP.NET Core, takimi jak rejestrowanie, wstrzykiwanie zależności (DI), uwierzytelnianie i autoryzacja.
  • Grpc.Net.Client: klient gRPC dla platformy .NET Core, który opiera się na znanej HttpClientwersji .
  • Grpc.Net.ClientFactory: integracja klienta gRPC z programem HttpClientFactory.

Aby uzyskać więcej informacji, zobacz Omówienie usługi gRPC na platformie .NET.

SignalR

Aby uzyskać instrukcje dotyczące migracji, zobacz Aktualizowanie SignalR kodu . SignalR teraz używa System.Text.Json metody do serializacji/deserializowania JSkomunikatów WŁ. Aby uzyskać instrukcje dotyczące przywracania serializatora opartego na platformie Newtonsoft.Json, zobacz Switch to Newtonsoft.Json (Przełączanie do pliku Newtonsoft.JsonNewtonsoft.Json).

W programach JavaScript i .NET Clients for SignalRdodano obsługę automatycznego ponownego łączenia. Domyślnie klient próbuje natychmiast ponownie nawiązać połączenie i ponowić próbę po 2, 10 i 30 sekundach, jeśli to konieczne. Jeśli klient zostanie pomyślnie ponownie połączony, otrzyma nowy identyfikator połączenia. Automatyczne ponowne nawiązywanie połączenia jest opt-in:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect()
    .build();

Interwały ponownego łączenia można określić, przekazując tablicę czasu trwania na podstawie milisekund:

.withAutomaticReconnect([0, 3000, 5000, 10000, 15000, 30000])
//.withAutomaticReconnect([0, 2000, 10000, 30000]) The default intervals.

Implementację niestandardową można przekazać w celu pełnej kontroli interwałów ponownego łączenia.

Jeśli ponowne nawiązywanie połączenia zakończy się niepowodzeniem po ostatnim interwale ponownego połączenia:

  • Klient uważa, że połączenie jest w trybie offline.
  • Klient przestaje próbować ponownie nawiązać połączenie.

Podczas ponownych prób nawiązania połączenia zaktualizuj interfejs użytkownika aplikacji, aby powiadomić użytkownika o próbie ponownego nawiązania połączenia.

Aby przekazać opinię interfejsu użytkownika po przerwaniu połączenia, SignalR interfejs API klienta został rozszerzony w celu uwzględnienia następujących procedur obsługi zdarzeń:

  • onreconnecting: daje deweloperom możliwość wyłączenia interfejsu użytkownika lub powiadom użytkowników, że aplikacja jest w trybie offline.
  • onreconnected: daje deweloperom możliwość zaktualizowania interfejsu użytkownika po ponownym utworzeniu połączenia.

Poniższy kod służy onreconnecting do aktualizowania interfejsu użytkownika podczas próby nawiązania połączenia:

connection.onreconnecting((error) => {
    const status = `Connection lost due to error "${error}". Reconnecting.`;
    document.getElementById("messageInput").disabled = true;
    document.getElementById("sendButton").disabled = true;
    document.getElementById("connectionStatus").innerText = status;
});

Poniższy kod używa onreconnected metody w celu zaktualizowania interfejsu użytkownika w połączeniu:

connection.onreconnected((connectionId) => {
    const status = `Connection reestablished. Connected.`;
    document.getElementById("messageInput").disabled = false;
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectionStatus").innerText = status;
});

SignalR 3.0 i nowsze udostępnia niestandardowy zasób do obsługi autoryzacji, gdy metoda centrum wymaga autoryzacji. Zasób jest wystąpieniem HubInvocationContextklasy . Element HubInvocationContext zawiera następujące elementy:

  • HubCallerContext
  • Nazwa wywoływanej metody centrum.
  • Argumenty metody piasty.

Rozważmy poniższy przykład aplikacji pokoju rozmów zezwalającej na logowanie wielu organizacji za pośrednictwem usługi Azure Active Directory. Każda osoba mająca konto Microsoft może zalogować się do czatu, ale tylko członkowie organizacji należącej do organizacji mogą blokować użytkownikom lub wyświetlać historie czatów użytkowników. Aplikacja może ograniczyć niektóre funkcje od określonych użytkowników.

public class DomainRestrictedRequirement :
    AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>,
    IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
        DomainRestrictedRequirement requirement,
        HubInvocationContext resource)
    {
        if (context.User?.Identity?.Name == null)
        {
            return Task.CompletedTask;
        }

        if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }

    private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername)
    {
        if (hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase))
        {
            return currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase);
        }

        return currentUsername.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase));
    }
}

W poprzednim kodzie DomainRestrictedRequirement służy jako niestandardowy IAuthorizationRequirementelement . HubInvocationContext Ponieważ parametr zasobu jest przekazywany, logika wewnętrzna może:

  • Sprawdź kontekst, w którym jest wywoływany koncentrator.
  • Podejmij decyzje dotyczące zezwalania użytkownikowi na wykonywanie poszczególnych metod centrum.

Poszczególne metody centrum można oznaczyć nazwą zasad sprawdzanych w czasie wykonywania. Gdy klienci próbują wywołać poszczególne metody centrum, DomainRestrictedRequirement program obsługi uruchamia i kontroluje dostęp do metod. Na podstawie sposobu DomainRestrictedRequirement kontroli dostępu:

  • Wszyscy zalogowani użytkownicy mogą wywołać metodę SendMessage .
  • Tylko użytkownicy, którzy zalogowali się @jabbr.net przy użyciu adresu e-mail, mogą wyświetlać historie użytkowników.
  • Tylko bob42@jabbr.net użytkownicy mogą blokować dostęp do pokoju rozmów.
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

    [Authorize("DomainRestricted")]
    public void BanUser(string username)
    {
    }

    [Authorize("DomainRestricted")]
    public void ViewUserHistory(string username)
    {
    }
}

DomainRestricted Tworzenie zasad może obejmować:

  • W Startup.cspliku dodaj nowe zasady.
  • Podaj wymaganie niestandardowe DomainRestrictedRequirement jako parametr.
  • Rejestrowanie przy użyciu oprogramowania pośredniczącego DomainRestricted autoryzacji.
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR koncentratory używają routingu punktu końcowego. SignalR Połączenie koncentratora zostało wcześniej wykonane jawnie:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

W poprzedniej wersji deweloperzy musieli połączyć kontrolery, Razor strony i koncentratory w różnych miejscach. Jawne połączenie powoduje serię niemal identycznych segmentów routingu:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

app.UseRouting(routes =>
{
    routes.MapRazorPages();
});

SignalR Koncentratory 3.0 można kierować za pośrednictwem routingu punktów końcowych. W przypadku routingu punktów końcowych zazwyczaj można skonfigurować cały routing w programie UseRouting:

app.UseRouting(routes =>
{
    routes.MapRazorPages();
    routes.MapHub<ChatHub>("hubs/chat");
});

Dodano ASP.NET Core 3.0 SignalR :

Przesyłanie strumieniowe klient-serwer. W przypadku przesyłania strumieniowego typu klient-serwer metody po stronie serwera mogą przyjmować wystąpienia IAsyncEnumerable<T> typu lub ChannelReader<T>. W poniższym przykładzie UploadStream języka C# metoda w centrum otrzyma strumień ciągów od klienta:

public async Task UploadStream(IAsyncEnumerable<string> stream)
{
    await foreach (var item in stream)
    {
        // process content
    }
}

Aplikacje klienckie platformy .NET mogą przekazywać IAsyncEnumerable<T> wystąpienie typu lub ChannelReader<T> jako stream argument UploadStream metody Hub powyżej.

Po zakończeniu pętli i zakończeniu for funkcji lokalnej jest wysyłane uzupełnianie strumienia:

async IAsyncEnumerable<string> clientStreamData()
{
    for (var i = 0; i < 5; i++)
    {
        var data = await FetchSomeData();
        yield return data;
    }
}

await connection.SendAsync("UploadStream", clientStreamData());

Aplikacje klienckie języka JavaScript używają SignalRSubject (lub tematu RxJS) dla stream argumentu UploadStream metody Hub powyżej.

let subject = new signalR.Subject();
await connection.send("StartStream", "MyAsciiArtStream", subject);

Kod JavaScript może użyć subject.next metody do obsługi ciągów, ponieważ są przechwytywane i gotowe do wysłania na serwer.

subject.next("example");
subject.complete();

Korzystając z kodu takiego jak dwa poprzednie fragmenty kodu, można utworzyć środowiska przesyłania strumieniowego w czasie rzeczywistym.

Nowa JSserializacja ON

program ASP.NET Core 3.0 domyślnie używa System.Text.Json do JSserializacji ON:

  • Odczyty i zapisy JSWŁ. asynchronicznie.
  • Jest zoptymalizowany pod kątem tekstu UTF-8.
  • Zazwyczaj wyższa wydajność niż Newtonsoft.Json.

Aby dodać Json.NET do platformy ASP.NET Core 3.0, zobacz Dodawanie obsługi formatu ON opartego na JSpliku Newtonsoft.Json.

Nowe Razor dyrektywy

Poniższa lista zawiera nowe Razor dyrektywy:

  • @attribute@attribute: Dyrektywa stosuje dany atrybut do klasy wygenerowanej strony lub widoku. Na przykład @attribute [Authorize].
  • @implements@implements: Dyrektywa implementuje interfejs dla wygenerowanej klasy. Na przykład @implements IDisposable.

IdentitySerwer4 obsługuje uwierzytelnianie i autoryzację dla internetowych interfejsów API i spA

ASP.NET Core 3.0 oferuje uwierzytelnianie w aplikacjach jednostronicowych (SPA) przy użyciu obsługi autoryzacji internetowego interfejsu API. ASP.NET Core Identity do uwierzytelniania i przechowywania użytkowników jest połączony z serwerem IdentityServer4 na potrzeby implementowania Połączenie OpenID.

IdentityServer4 to platforma OpenID Połączenie i OAuth 2.0 dla platformy ASP.NET Core 3.0. Umożliwia ona następujące funkcje zabezpieczeń:

  • Uwierzytelnianie jako usługa (AaaS)
  • Logowanie jednokrotne/wyłączanie logowania jednokrotnego w wielu typach aplikacji
  • Kontrola dostępu dla interfejsów API
  • Brama federacyjna

Aby uzyskać więcej informacji, zobacz dokumentacjęIdentityserwera Server4 lub uwierzytelnianie i autoryzację dla spAs.

Uwierzytelnianie certyfikatu i protokołu Kerberos

Uwierzytelnianie certyfikatu wymaga:

  • Konfigurowanie serwera do akceptowania certyfikatów.
  • Dodanie oprogramowania pośredniczącego uwierzytelniania w programie Startup.Configure.
  • Dodawanie usługi uwierzytelniania certyfikatów w programie Startup.ConfigureServices.
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(
        CertificateAuthenticationDefaults.AuthenticationScheme)
            .AddCertificate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Opcje uwierzytelniania certyfikatu obejmują następujące możliwości:

  • Zaakceptuj certyfikaty z podpisem własnym.
  • Sprawdź, czy nie ma odwołania certyfikatów.
  • Sprawdź, czy certyfikat proffered ma w nim odpowiednie flagi użycia.

Domyślna jednostka użytkownika jest tworzona z właściwości certyfikatu. Podmiot zabezpieczeń użytkownika zawiera zdarzenie, które umożliwia uzupełnienie lub zastąpienie podmiotu zabezpieczeń. Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania certyfikatów w programie ASP.NET Core.

Uwierzytelnianie systemu Windows zostało rozszerzone na systemy Linux i macOS. W poprzednich wersjach uwierzytelnianie systemu Windows było ograniczone do usług IIS i HTTP.sys. W systemie ASP.NET Core 3.0 Kestrel można używać hostów przyłączonych do domeny systemu Windows, Kerberos i NTLM w systemach Windows, Linux i macOS. Kestrel obsługa tych schematów uwierzytelniania jest zapewniana przez pakiet NuGet Microsoft.AspNetCore.Authentication.Negotiate. Podobnie jak w przypadku innych usług uwierzytelniania, skonfiguruj szeroką aplikację uwierzytelniania, a następnie skonfiguruj usługę:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Wymagania dotyczące hosta:

  • Hosty systemu Windows muszą mieć nazwy główne usługi (SPN) dodane do konta użytkownika hostowania aplikacji.
  • Maszyny z systemami Linux i macOS muszą być przyłączone do domeny.
    • Nazwy SPN należy utworzyć dla procesu internetowego.
    • Pliki keytab muszą być generowane i konfigurowane na maszynie hosta.

Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania systemu Windows w ASP.NET Core.

Zmiany szablonu

Szablony interfejsu użytkownika sieci Web (Razor Strony, MVC z kontrolerem i widokami) zostały usunięte:

Szablon Angular został zaktualizowany do używania platformy Angular 8.

Szablon Razor biblioteki klas (RCL) domyślnie domyślnie służy do Razor tworzenia składników. Nowa opcja szablonu w programie Visual Studio zapewnia obsługę szablonów dla stron i widoków. Podczas tworzenia listy RCL na podstawie szablonu w powłoce poleceń przekaż --support-pages-and-views opcję (dotnet new razorclasslib --support-pages-and-views).

Host ogólny

Szablony ASP.NET Core 3.0 używają hosta ogólnego platformy .NET w programie ASP.NET Core. Poprzednie wersje używały elementu WebHostBuilder. Użycie hosta ogólnego platformy .NET Core (HostBuilder) zapewnia lepszą integrację aplikacji ASP.NET Core z innymi scenariuszami serwera, które nie są specyficzne dla sieci Web. Aby uzyskać więcej informacji, zobacz HostBuilder zastępuje WebHostBuilder.

Konfiguracja hosta

Przed wydaniem ASP.NET Core 3.0 zmienne środowiskowe poprzedzone prefiksem ASPNETCORE_ zostały załadowane do konfiguracji hosta hosta sieci Web. W wersji 3.0 AddEnvironmentVariables jest używany do ładowania zmiennych środowiskowych poprzedzonych prefiksem DOTNET_ dla konfiguracji hosta za pomocą polecenia CreateDefaultBuilder.

Zmiany w iniekcji konstruktora startowego

Host ogólny obsługuje tylko następujące typy iniekcji Startup konstruktora:

Wszystkie usługi można nadal wstrzykiwać bezpośrednio jako argumenty do Startup.Configure metody . Aby uzyskać więcej informacji, zobacz Generic Host restricts Startup constructor injection (aspnet/Anonss #353).

Kestrel

  • Kestrel konfiguracja została zaktualizowana do migracji do hosta ogólnego. W wersji 3.0 Kestrel program jest skonfigurowany w konstruktorze hostów sieci Web udostępnianym przez ConfigureWebHostDefaultsprogram .
  • Karty Połączenie ion zostały usunięte i Kestrel zastąpione oprogramowaniem pośredniczącym Połączenie ion, które jest podobne do oprogramowania pośredniczącego HTTP w potoku ASP.NET Core, ale w przypadku połączeń niższego poziomu.
  • Warstwa Kestrel transportu została udostępniona jako interfejs publiczny w programie Connections.Abstractions.
  • Niejednoznaczność między nagłówkami a przyczepami została rozwiązana przez przeniesienie nagłówków końcowych do nowej kolekcji.
  • Synchroniczne interfejsy API we/wy, takie jak HttpRequest.Body.Read, są typowym źródłem głodu wątku, co prowadzi do awarii aplikacji. W wersji 3.0 AllowSynchronousIO jest domyślnie wyłączona.

Aby uzyskać więcej informacji, zobacz Migrowanie z ASP.NET Core 2.2 do 3.0.

Protokół HTTP/2 jest domyślnie włączony

Protokół HTTP/2 jest domyślnie włączony dla Kestrel punktów końcowych HTTPS. Obsługa protokołu HTTP/2 dla usług IIS lub HTTP.sys jest włączona, gdy jest obsługiwana przez system operacyjny.

EventCounters na żądanie

Hosting EventSource, Microsoft.AspNetCore.Hosting, emituje następujące nowe EventCounter typy związane z żądaniami przychodzącymi:

  • requests-per-second
  • total-requests
  • current-requests
  • failed-requests

Routing punktów końcowych

Routing punktów końcowych, który umożliwia platformom (na przykład MVC) pracę z oprogramowaniem pośredniczącym, jest ulepszony:

  • Kolejność oprogramowania pośredniczącego i punktów końcowych można skonfigurować w potoku przetwarzania żądań programu Startup.Configure.
  • Punkty końcowe i oprogramowanie pośredniczące dobrze składają się z innych technologii opartych na ASP.NET Core, takich jak kontrole kondycji.
  • Punkty końcowe mogą implementować zasady, takie jak CORS lub autoryzacja, zarówno w oprogramowanie pośredniczące, jak i MVC.
  • Filtry i atrybuty można umieszczać na metodach w kontrolerach.

Aby uzyskać więcej informacji, zobacz Routing na platformie ASP.NET Core.

Kontrole kondycji

Testy kondycji używają routingu punktu końcowego z hostem ogólnym. W Startup.Configurepliku wywołaj MapHealthChecks konstruktora punktu końcowego przy użyciu adresu URL punktu końcowego lub ścieżki względnej:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHealthChecks("/health");
});

Punkty końcowe kontroli kondycji mogą:

  • Określ co najmniej jeden dozwolony host/porty.
  • Wymagaj autoryzacji.
  • Wymagaj mechanizmu CORS.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Potoki w obiekcie HttpContext

Teraz można odczytać treść żądania i napisać treść odpowiedzi przy użyciu interfejsu System.IO.Pipelines API. Właściwość HttpRequest.BodyReader udostępnia element PipeReader , który może służyć do odczytywania treści żądania. Właściwość HttpResponse.BodyWriter udostępnia element PipeWriter , który może służyć do zapisywania treści odpowiedzi. HttpRequest.BodyReader jest analogią strumienia HttpRequest.Body . HttpResponse.BodyWriter jest analogią strumienia HttpResponse.Body .

Ulepszone raportowanie błędów w usługach IIS

Błędy uruchamiania podczas hostowania aplikacji ASP.NET Core w usługach IIS generują teraz bogatsze dane diagnostyczne. Te błędy są zgłaszane do dziennika zdarzeń systemu Windows ze śladami stosu wszędzie tam, gdzie ma to zastosowanie. Ponadto wszystkie ostrzeżenia, błędy i nieobsługiwane wyjątki są rejestrowane w dzienniku zdarzeń systemu Windows.

Zestaw SDK usługi procesu roboczego i procesu roboczego

Program .NET Core 3.0 wprowadza nowy szablon aplikacji usługi Worker Service. Ten szablon stanowi punkt wyjścia do pisania długotrwałych usług na platformie .NET Core.

Aby uzyskać więcej informacji, zobacz:

Ulepszenia oprogramowania pośredniczącego nagłówków przekazywanych

W poprzednich wersjach ASP.NET Core wywoływanie i UseHstsUseHttpsRedirection było problematyczne podczas wdrażania w systemie Azure Linux lub za dowolnym zwrotnym serwerem proxy innym niż usługi IIS. Poprawka dla poprzednich wersji jest udokumentowana w temacie Przekazywanie schematu dla systemu Linux i odwrotnych serwerów proxy innych niż IIS.

Ten scenariusz został naprawiony w ASP.NET Core 3.0. Host włącza oprogramowanie pośredniczące nagłówków przekazywanych, gdy zmienna ASPNETCORE_FORWARDEDHEADERS_ENABLED środowiskowa jest ustawiona na truewartość . ASPNETCORE_FORWARDEDHEADERS_ENABLED parametr jest ustawiony na true wartość w naszych obrazach kontenerów.

usprawnienia dotyczące wydajności

ASP.NET Core 3.0 zawiera wiele ulepszeń, które zmniejszają użycie pamięci i zwiększają przepływność:

  • Zmniejszenie użycia pamięci podczas korzystania z wbudowanego kontenera iniekcji zależności dla usług o określonym zakresie.
  • Zmniejszenie alokacji w całej strukturze, w tym scenariusze oprogramowania pośredniczącego i routing.
  • Zmniejszenie użycia pamięci dla połączeń protokołu WebSocket.
  • Ulepszenia redukcji pamięci i przepływności dla połączeń HTTPS.
  • Nowa zoptymalizowana i w pełni asynchroniczna JSserializator ON.
  • Zmniejszenie użycia pamięci i ulepszenia przepływności podczas analizowania formularzy.

program ASP.NET Core 3.0 działa tylko na platformie .NET Core 3.0

Od wersji ASP.NET Core 3.0 platforma .NET Framework nie jest już obsługiwaną strukturą docelową. Projekty przeznaczone dla platformy .NET Framework mogą być nadal w pełni obsługiwane przy użyciu wersji LTS platformy .NET Core 2.1. Większość pakietów powiązanych z platformą ASP.NET Core 2.1.x będzie obsługiwana przez czas nieokreślony, poza trzyletnim okresem LTS dla platformy .NET Core 2.1.

Aby uzyskać informacje o migracji, zobacz Przenoszenie kodu z programu .NET Framework do platformy .NET Core.

Korzystanie z platformy udostępnionej ASP.NET Core

Udostępniona platforma ASP.NET Core 3.0 zawarta w metapakiecie Microsoft.AspNetCore.App nie wymaga już jawnego <PackageReference /> elementu w pliku projektu. Współużytkowana struktura jest automatycznie przywołyowana podczas korzystania z Microsoft.NET.Sdk.Web zestawu SDK w pliku projektu:

<Project Sdk="Microsoft.NET.Sdk.Web">

Zestawy usunięte z udostępnionej platformy ASP.NET Core

Najbardziej godne uwagi zestawy usunięte z platformy udostępnionej ASP.NET Core 3.0 to:

Aby uzyskać pełną listę zestawów usuniętych ze struktury udostępnionej, zobacz Zestawy usuwane z Microsoft.AspNetCore.App 3.0. Aby uzyskać więcej informacji na temat motywacji tej zmiany, zobacz Istotne zmiany w Microsoft.AspNetCore.App w wersji 3.0 i A first look at changes coming in ASP.NET Core 3.0 (Zmiany powodujące niezgodność w wersji 3.0) i A first look at changes coming in ASP.NET Core 3.0 (Zmiany powodujące niezgodność w wersji 3.0).