Nyheter i ASP.NET Core 3.0

2025-05-28

Den här artikeln belyser de viktigaste ändringarna i ASP.NET Core 3.0 med länkar till relevant dokumentation.

Blazor

Blazor är ett nytt ramverk i ASP.NET Core för att skapa interaktivt webbgränssnitt på klientsidan med .NET:

Skapa omfattande interaktiva UIs med C#.
Dela applogik på serversidan och på klientsidan som skrivits i .NET.
Rendera användargränssnittet som HTML och CSS för bred webbläsarsupport, inklusive mobila webbläsare.

Blazor ramverksscenarier som stöds:

Återanvändbara gränssnittskomponenter (Razor komponenter)
Routning på klientsidan
Komponentlayouter
Stöd för beroendeinjektion
Formulär och validering
Leverera Razor komponenter i Razor klassbibliotek
JavaScript-interoperabilitet

Mer information finns i ASP.NET Core Blazor.

Blazor Server

Blazor frikopplar komponentrenderingslogik från hur användargränssnittsuppdateringar tillämpas. Blazor Server ger stöd för att hantera Razor komponenter på servern i en ASP.NET Core-app. Användargränssnittsuppdateringar hanteras via en SignalR anslutning. Blazor Server stöds i ASP.NET Core 3.0.

Blazor WebAssembly (förhandsversion)

Blazor appar kan också köras direkt i webbläsaren med hjälp av en WebAssembly-baserad .NET-körning. Blazor WebAssembly är i förhandsversion och stöds inte i ASP.NET Core 3.0. Blazor WebAssembly kommer att stödjas i en framtida version av ASP.NET Core.

Razor komponenter

Blazor appar skapas från komponenter. Komponenter är fristående delar av användargränssnittet (UI), till exempel en sida, dialogruta eller ett formulär. Komponenter är normala .NET-klasser som definierar UI-renderingslogik och händelsehanterare på klientsidan. Du kan skapa interaktiva webbappar utan JavaScript.

Komponenter i Blazor skapas vanligtvis med hjälp av Razor syntax, en naturlig blandning av HTML och C#. Razor komponenter liknar Razor Pages- och MVC-vyer eftersom de båda använder Razor. Till skillnad från sidor och vyer, som baseras på en modell för begäran-svar, används komponenter specifikt för att hantera användargränssnittssammansättning.

gRPC

gRPC:

Är ett populärt, högpresterande RPC-ramverk (fjärrproceduranrop).
Erbjuder en åsiktsbaserad kontraktsinriktad metod för API-utveckling.
Använder modern teknik som:
- HTTP/2 för transport.
- Protokollbuffertar som gränssnittsbeskrivningsspråk.
- Binär serialiseringsformat.
Innehåller funktioner som:
- Autentisering
- Dubbelriktad direktuppspelning och flödeskontroll.
- Annullering och tidsgränser.

gRPC-funktioner i ASP.NET Core 3.0 innehåller:

Grpc.AspNetCore: Ett ASP.NET Core-ramverk för att vara värd för gRPC-tjänster. gRPC på ASP.NET Core integreras med Standard ASP.NET Core-funktioner som loggning, beroendeinmatning (DI), autentisering och auktorisering.
Grpc.Net.Client: En gRPC-klient för .NET Core som bygger på den välbekanta HttpClient.
Grpc.Net.ClientFactory: gRPC-klientintegrering med HttpClientFactory.

Mer information finns i Översikt för gRPC på .NET.

SignalR

Se Uppdatera SignalR kod för migreringsinstruktioner. SignalR använder System.Text.Json nu för att serialisera/deserialisera JSON-meddelanden. Se Växla till Newtonsoft.Json för instruktioner om hur du återställer Newtonsoft.Json-baserade serialiseraren.

I JavaScript- och .NET-klienterna för SignalRhar stöd lagts till för automatisk återanslutning. Som standard försöker klienten återansluta omedelbart och försöka igen efter 2, 10 och 30 sekunder om det behövs. Om klienten återansluts får den ett nytt anslutnings-ID. Automatisk återanslutning är valbar.

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

Återanslutningsintervallen kan anges genom att skicka en matris med millisekundersbaserade varaktigheter:

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

En anpassad implementering kan skickas in för fullständig kontroll över återanslutningsintervallen.

Om återanslutningen misslyckas efter det senaste återanslutningsintervallet:

Klienten anser att anslutningen är offline.
Klienten slutar att försöka återansluta.

Under återanslutningsförsök uppdaterar du appens användargränssnitt för att meddela användaren att återanslutningen görs.

För att ge feedback om användargränssnittet när anslutningen avbryts har klient-API:et SignalR utökats så att det omfattar följande händelsehanterare:

onreconnecting: Ger utvecklare en möjlighet att inaktivera användargränssnittet eller låta användarna veta att appen är offline.
onreconnected: Ger utvecklare en möjlighet att uppdatera användargränssnittet när anslutningen har återupprättats.

Följande kod använder onreconnecting för att uppdatera användargränssnittet när du försöker ansluta:

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

Följande kod använder onreconnected för att uppdatera användargränssnittet vid anslutning:

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 eller senare tillhandahåller en anpassad resurs till auktoriseringshanterare när en hubbmetod kräver auktorisering. Resursen är en instans av HubInvocationContext. Innehåller HubInvocationContext följande:

HubCallerContext
Namnet på hubbmetoden som anropas.
Argument till hubbmetoden.

Tänk dig följande exempel på en chattrumsapp som tillåter flera organisationsinloggning via Azure Active Directory. Alla med ett Microsoft-konto kan logga in för att chatta, men endast medlemmar i den ägande organisationen kan förbjuda användare eller visa användarnas chatthistorik. Appen kan begränsa vissa funktioner från specifika användare.

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

I föregående kod DomainRestrictedRequirement fungerar som en anpassad IAuthorizationRequirement. HubInvocationContext Eftersom resursparametern skickas in kan den interna logiken:

Granska kontexten där hubben anropas.
Fatta beslut om att tillåta användaren att köra enskilda hubbmetoder.

Enskilda hubbmetoder kan markeras med namnet på policyn som koden kontrollerar vid körning. När klienter försöker anropa enskilda hubbmetoder styr hanteraren DomainRestrictedRequirement körningen och hanterar åtkomsten till metoderna. Baserat på hur DomainRestrictedRequirement kontrollerar åtkomst:

Alla inloggade användare kan anropa SendMessage metoden.
Endast användare som har loggat in med en @jabbr.net e-postadress kan visa användarnas historia.
Endast bob42@jabbr.net kan förbjuda användare från chattrummet.

[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

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

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

Skapandet av DomainRestricted-policyn kan omfatta:

I Startup.cslägger du till den nya principen.
Ange det anpassade DomainRestrictedRequirement kravet som en parameter.
Registrerar DomainRestricted med auktoriseringsmellanprogrammet.

services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR hubbar använder slutpunktsroutning. SignalR hubbanslutningen utfördes tidigare explicit:

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

I den tidigare versionen behövde utvecklare koppla upp styrenheter, Razor sidor och hubbar på flera olika platser. Exakt anslutning resulterar i en serie nästan identiska ruttsegment.

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

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

SignalR 3.0-hubbar kan dirigeras via slutpunktsroutning. Med slutpunktsroutning kan normalt all routning konfigureras i UseRouting:

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

ASP.NET Core 3.0 SignalR har lagts till:

Direktuppspelning från klient till server. Med strömning från klient till server kan metoder på serversidan ta instanser av antingen en IAsyncEnumerable<T> eller ChannelReader<T>. I följande C#-exempel UploadStream får metoden på hubben en ström med strängar från klienten:

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

.NET-klientappar kan antingen skicka en IAsyncEnumerable<T> instans eller en ChannelReader<T> instans som stream-argument för UploadStream-hubbmetoden ovan.

När loopen for har slutförts och den lokala funktionen avslutas skickas dataströmmens slutförande:

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

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

JavaScript-klientappar använder SignalRSubject (eller ett RxJS Subject) för argumentet i stream-metoden i hubben ovan.

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

JavaScript-koden kan använda subject.next metoden för att hantera strängar när de samlas in och är redo att skickas till servern.

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

Med hjälp av kod som de två föregående kodfragmenten kan realtidsströmningsupplevelser skapas.

Ny JSON-serialisering

ASP.NET Core 3.0 används System.Text.Json nu som standard för JSON-serialisering:

Läser och skriver JSON asynkront.
Är optimerad för UTF-8-text.
Vanligtvis högre prestanda än Newtonsoft.Json.

Information om hur du lägger till Json.NET i ASP.NET Core 3.0 finns i Lägga till Newtonsoft.Json-baserat JSON-formatstöd.

Nya Razor direktiv

Följande lista innehåller nya Razor direktiv:

@attribute: Direktivet @attribute tillämpar det angivna attributet på klassen för den genererade sidan eller vyn. Till exempel @attribute [Authorize].
@implements: Direktivet @implements implementerar ett gränssnitt för den genererade klassen. Till exempel @implements IDisposable.

IdentityServer4 stöder autentisering och auktorisering för webb-API:er och SPA:er

ASP.NET Core 3.0 erbjuder autentisering i ensidesappar (SPA) med hjälp av stöd för webb-API-auktorisering. ASP.NET Core Identity för autentisering och lagring av användare kombineras med IdentityServer4 för implementering av OpenID Connect.

IdentityServer4 är ett OpenID Connect- och OAuth 2.0-ramverk för ASP.NET Core 3.0. Den aktiverar följande säkerhetsfunktioner:

Autentisering som en tjänst (AaaS)
Enkel inloggning/av(SSO) över flera programtyper
Åtkomstkontroll för API:er
Federationsgateway

Mer information finns i dokumentationen om IdentityServer4 eller autentisering och auktorisering för SPA:er.

Certifikat- och Kerberos-autentisering

Certifikatautentisering kräver:

Konfigurera servern för att acceptera certifikat.
Lägga till mellanprogrammet för autentisering i Startup.Configure.
Lägga till certifikatautentiseringstjänsten i 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.
}

Alternativen för certifikatautentisering omfattar möjligheten att:

Acceptera självsignerade certifikat.
Kontrollera om certifikatet återkallas.
Kontrollera att det erbjudna certifikatet har rätt användningsflaggor i det.

Ett standardanvändarhuvudnamn skapas från certifikategenskaperna. Användarhuvudnamnet innehåller ett event som möjliggör att komplettera eller ersätta huvudprincipalen. Mer information finns i Konfigurera certifikatautentisering i ASP.NET Core.

Windows-autentisering har utökats till Linux och macOS. I tidigare versioner var Windows-autentisering begränsad till IIS och HTTP.sys. I ASP.NET Core 3.0 Kestrel kan du använda Negotiate, Kerberos och NTLM i Windows, Linux och macOS för windows-domänanslutna värdar. Kestrel stöd för dessa autentiseringsscheman tillhandahålls av NuGet-paketet Microsoft.AspNetCore.Authentication.Negotiate . Precis som med de andra autentiseringstjänsterna konfigurerar du autentiseringsappen brett och konfigurerar sedan tjänsten:

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.
}

Värdkrav:

Windows-värdar måste ha tjänsthuvudnamn (SPN) tillagda i användarkontot som är värd för appen.
Linux- och macOS-datorer måste vara anslutna till domänen.
- SPN måste skapas för webbprocessen.
- Keytab-filer måste genereras och konfigureras på värddatorn.

Mer information finns i Konfigurera Windows-autentisering i ASP.NET Core.

Malländringar

Webbgränssnittsmallarna (Razor Sidor, MVC med kontrollant och vyer) har följande borttagna:

Användargränssnittet cookie för medgivande ingår inte längre. Information om hur du aktiverar cookie medgivandefunktionen i en ASP.NET Core 3.0-mallgenererad app finns i GDPR-stöd (General Data Protection Regulation) i ASP.NET Core.
Skript och relaterade statiska tillgångar refereras nu som lokala filer i stället för att använda CDN. Mer information finns i Skript och relaterade statiska tillgångar refereras nu till som lokala filer i stället för att använda CDN baserat på den aktuella miljön (dotnet/AspNetCore.Docs #14350).

Angular-mallen har uppdaterats för att använda Angular 8.

Mallen Razor klassbibliotek (RCL) är som standard för utveckling av Razor-komponenter. Ett nytt mallalternativ i Visual Studio ger mallstöd för sidor och vyer. När du skapar en RCL från mallen i ett kommandogränssnitt skickar du alternativet --support-pages-and-views (dotnet new razorclasslib --support-pages-and-views).

Allmän värd

Mallarna ASP.NET Core 3.0 använder .NET Generic Host i ASP.NET Core. Tidigare versioner använde WebHostBuilder. Med .NET Core Generic Host (HostBuilder) får du bättre integrering av ASP.NET Core-appar med andra serverscenarier som inte är webbspecifika. Mer information finns i HostBuilder ersätter WebHostBuilder.

Värdkonfiguration

Före lanseringen av ASP.NET Core 3.0 lästes miljövariabler med prefixet ASPNETCORE_ in för konfiguration av webbvärden. I 3.0 AddEnvironmentVariables används för att läsa in miljövariabler som prefixats med DOTNET_ för värdkonfiguration med CreateDefaultBuilder.

Ändringar i startkonstruktorinmatning

Den generiska värden stöder endast följande typer för Startup konstruktorinmatning:

IHostEnvironment
IWebHostEnvironment
IConfiguration

Alla tjänster kan fortfarande matas in direkt som argument till Startup.Configure metoden. Mer information finns i Generic Host restricts Startup constructor injection (aspnet/Announcements #353).

Kestrel

Kestrel konfigurationen har uppdaterats för migreringen till den generiska värden. I 3.0 konfigureras Kestrel på webbvärdsmotorn som tillhandahålls av ConfigureWebHostDefaults.
Anslutningskort har tagits bort från Kestrel och ersatts med Anslutningsmellanprogram, vilket liknar HTTP Middleware i ASP.NET Core-pipelinen men för anslutningar på lägre nivå.
Transportlagret Kestrel har exponerats som ett offentligt gränssnitt i Connections.Abstractions.
Tvetydighet mellan rubriker och trailers har lösts genom att avslutande rubriker flyttas till en ny samling.
Synkrona I/O-API:er, till exempel HttpRequest.Body.Read, är en vanlig källa till trådsvält som leder till appkrascher. I 3.0 inaktiveras AllowSynchronousIO som standard.

Mer information finns i Migrera från ASP.NET Core 2.2 till 3.0.

HTTP/2 aktiverat som standard

HTTP/2 är aktiverat som standard i Kestrel för HTTPS-slutpunkter. HTTP/2-stöd för IIS eller HTTP.sys aktiveras när det stöds av operativsystemet.

EventCounters på begäran

Värdhändelsekällan, Microsoft.AspNetCore.Hosting, genererar följande nya EventCounter typer som är relaterade till inkommande begäranden:

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

Slutpunktsroutning

Slutpunktsroutning, som gör att ramverk (till exempel MVC) kan fungera bra med mellanprogram, har förbättrats:

Ordningen på mellanprogram och slutpunkter kan konfigureras i pipelinen för bearbetning av begäranden för Startup.Configure.
Slutpunkter och mellanprogram fungerar bra med andra ASP.NET Core-baserade tekniker, till exempel hälsokontroller.
Slutpunkter kan implementera en princip, till exempel CORS eller auktorisering, i både mellanprogram och MVC.
Filter och attribut kan placeras på metoder i kontrollanter.

Mer information finns i Routning i ASP.NET Core.

Hälsokontroller

Hälsokontroller använder slutpunktsdirigering med den generiska värden. I Startup.Configureanropar du MapHealthChecks på slutpunktsverktyget med slutpunkts-URL:en eller den relativa sökvägen:

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

Slutpunkter för hälsokontroller kan:

Ange en eller flera tillåtna värdar/portar.
Kräv auktorisering.
Kräv CORS.

Mer information finns i följande artiklar:

Pipes på HttpContext

Nu är det möjligt att läsa begärandetexten och skriva svarstexten med hjälp av API:et System.IO.Pipelines . Egenskapen HttpRequest.BodyReader innehåller en PipeReader som kan användas för att läsa begärandetexten. Egenskapen HttpResponse.BodyWriter tillhandahåller en PipeWriter som kan användas för att skriva svarstexten. HttpRequest.BodyReader är en analog av HttpRequest.Body strömmen. HttpResponse.BodyWriter är en analog av HttpResponse.Body strömmen.

Förbättrad felrapportering i IIS

Startfel vid hosting av ASP.NET Core-appar i IIS ger nu mer detaljerad diagnostikdata. Dessa fel rapporteras till Windows-händelseloggen med stackspårningar i tillämpliga fall. Dessutom loggas alla varningar, fel och ohanterade undantag i Windows-händelseloggen.

Worker Service och Worker SDK

.NET Core 3.0 introducerar den nya arbetstjänstappmallen. Den här mallen är en startpunkt för att skriva långvariga tjänster i .NET Core.

Mer information finns i:

Förbättringar av vidarebefordrade sidhuvuden i mellanprogram

I tidigare versioner av ASP.NET Core var anrop UseHsts och UseHttpsRedirection problematiska när de distribuerades till en Azure Linux eller bakom någon annan omvänd proxy än IIS. Korrigeringen för tidigare versioner dokumenteras i Vidarebefordra schemat för Linux och icke-IIS omvända proxyservrar.

Det här scenariot har åtgärdats i ASP.NET Core 3.0. Värden aktiverar mellanprogrammet Vidarebefordrade rubriker när ASPNETCORE_FORWARDEDHEADERS_ENABLED miljövariabeln är inställd på true. ASPNETCORE_FORWARDEDHEADERS_ENABLED är inställd på true i våra containerbilder.

Prestandaförbättringar

ASP.NET Core 3.0 innehåller många förbättringar som minskar minnesanvändningen och förbättrar dataflödet:

Minskad minnesanvändning när du använder den inbyggda containern för beroendeinmatning för begränsade tjänster.
Minskning av allokeringar i ramverket, inklusive mellanprogramsscenarier och routning.
Minskad minnesanvändning för WebSocket-anslutningar.
Förbättringar av minnesminskning och dataflöde för HTTPS-anslutningar.
Ny optimerad och helt asynkron JSON-serialiserare.
Minskad minnesanvändning och förbättringar av dataflödet i formparsing.

ASP.NET Core 3.0 körs endast på .NET Core 3.0

Från och med ASP.NET Core 3.0 är .NET Framework inte längre ett målramverk som stöds. Projekt som riktar sig till .NET Framework kan fortsätta på ett sätt som stöds fullt ut med hjälp av .NET Core 2.1 LTS-versionen. De flesta ASP.NET Core 2.1.x-relaterade paket stöds på obestämd tid, utöver den treåriga LTS-perioden för .NET Core 2.1.

Information om migrering finns i Porta koden från .NET Framework till .NET Core.

Använda det delade ASP.NET Core-ramverket

Det delade ramverket ASP.NET Core 3.0, som finns i Microsoft.AspNetCore.App metapackage, kräver inte längre ett explicit <PackageReference /> element i projektfilen. Det delade ramverket refereras automatiskt när du använder Microsoft.NET.Sdk.Web SDK i projektfilen:

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

Sammansättningar som tagits bort från det delade ASP.NET Core-ramverket

De mest anmärkningsvärda sammansättningarna som tagits bort från det delade ramverket ASP.NET Core 3.0 är:

Newtonsoft.Json (Json.NET). Information om hur du lägger till Json.NET i ASP.NET Core 3.0 finns i Lägga till Newtonsoft.Json-baserat JSON-formatstöd. ASP.NET Core 3.0 introducerar System.Text.Json för läsning och skrivning av JSON. Mer information finns i Ny JSON-serialisering i det här dokumentet.
Entity Framework Core

En fullständig lista över sammansättningar som tagits bort från det delade ramverket finns i Sammansättningar som tas bort från Microsoft.AspNetCore.App 3.0. Mer information om motivationen för den här ändringen finns i Breaking changes to Microsoft.AspNetCore.App in 3.0 och A first look at changes coming in ASP.NET Core 3.0.

Brytande förändringar

Använd artiklarna i Icke-bakåtkompatibla ändringar i .NET för att hitta icke-bakåtkompatibla ändringar som kan gälla när du uppgraderar en app till en nyare version av .NET.

Feedback

Var den här sidan till hjälp?