Wat is er nieuw in ASP.NET Core 3.0

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

Blazor

Blazor is een nieuw framework in ASP.NET Core voor het bouwen van interactieve webgebruikersinterface aan de clientzijde met .NET:

• Maak uitgebreide interactieve UIS's met C#.
• Server- en clientzijde applicatielogica in .NET delen.
• Geef de gebruikersinterface weer als HTML en CSS voor brede browserondersteuning, inclusief mobiele browsers.

Blazor door het framework ondersteunde scenario's

• Herbruikbare UI-onderdelen (Razor onderdelen)
• Routering aan clientzijde
• Onderdeelindelingen
• Ondersteuning voor afhankelijkheidsinjectie
• Formulieren en validatie
• Lever Razor componenten in Razor classbibliotheken
• JavaScript-interoperatie

Zie ASP.NET Core Blazorvoor meer informatie.

Blazor Server

Blazor Koppelt de renderinglogica van onderdelen los van de wijze waarop UI-updates worden toegepast. Blazor Server biedt ondersteuning voor het hosten van Razor onderdelen op de server in een ASP.NET Core-app. UI-updates worden verwerkt via een SignalR verbinding. Blazor Server wordt ondersteund in ASP.NET Core 3.0.

Blazor WebAssembly (voorbeeld)

Blazor apps kunnen ook rechtstreeks in de browser worden uitgevoerd met behulp van een .NET Runtime op basis van WebAssembly. Blazor WebAssembly bevindt zich in een vroege versie en wordt niet ondersteund in ASP.NET Core 3.0. Blazor WebAssembly wordt ondersteund in een toekomstige release van ASP.NET Core.

Razor onderdelen

Blazor apps zijn gebouwd op basis van onderdelen. Onderdelen zijn zelfstandige segmenten van de gebruikersinterface (UI), zoals een pagina, dialoogvenster of formulier. Onderdelen zijn normale .NET-klassen die ui-renderinglogica en gebeurtenis-handlers aan de clientzijde definiëren. U kunt uitgebreide interactieve web-apps maken zonder JavaScript.

Onderdelen in Blazor worden doorgaans geschreven met behulp Razor van syntaxis, een natuurlijke mix van HTML en C#. Razor onderdelen zijn vergelijkbaar met Razor pagina's en MVC-weergaven, omdat ze beide gebruiken Razor. In tegenstelling tot pagina's en weergaven, die zijn gebaseerd op een aanvraag-antwoordmodel, worden componenten specifiek gebruikt voor het samenstellen van UI-componenten.

gRPC

gRPC:

• Is een populair RPC-framework met hoge prestaties (remote procedure call).

• Biedt een eigenzinnige contract-first benadering voor API-ontwikkeling.

• Maakt gebruik van moderne technologieën, zoals:

  • HTTP/2 voor transport.
  • Protocolbuffers als de interfacebeschrijvingstaal.
  • Binaire serialisatie-indeling.

• Biedt functies zoals:

  • Authenticatie
  • Bidirectioneel streaming- en stroombeheer.
  • Annulering en tijdslimieten.

gRPC-functionaliteit in ASP.NET Core 3.0 omvat:

• Grpc.AspNetCore: een ASP.NET Core-framework voor het hosten van gRPC-services. gRPC op ASP.NET Core kan worden geïntegreerd met standaardfuncties van ASP.NET Core, zoals logboekregistratie, afhankelijkheidsinjectie (DI), verificatie en autorisatie.
• Grpc.Net.Client: een gRPC-client voor .NET Core die voortbouwt op het vertrouwde HttpClient.
• Grpc.Net.ClientFactory: gRPC-clientintegratie met HttpClientFactory.

Zie Overzicht voor gRPC op .NET voor meer informatie.

SignalR

Zie Code bijwerken SignalR voor migratie-instructies. SignalR wordt nu gebruikt System.Text.Json om JSON-berichten te serialiseren/deserialiseren. Zie Switch to Newtonsoft.Json voor instructies om de op Newtonsoft.Json gebaseerde serializer te herstellen.

In de JavaScript- en .NET-clients voor SignalRis ondersteuning toegevoegd voor automatische opnieuw verbinding maken. De client probeert standaard onmiddellijk opnieuw verbinding te maken en na 2, 10 en 30 seconden opnieuw te proberen, indien nodig. Als de client opnieuw verbinding maakt, ontvangt deze een nieuwe verbindings-id. Automatisch opnieuw verbinding maken vereist actieve deelname.

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

De intervallen voor opnieuw verbinden kunnen worden opgegeven door een matrix van op milliseconden gebaseerde duur door te geven:

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

Een aangepaste implementatie kan worden doorgegeven voor volledig beheer van de intervallen voor opnieuw verbinden.

Als de herverbinding mislukt na het laatste interval voor opnieuw verbinden:

• De client beschouwt dat de verbinding offline is.
• De client probeert geen verbinding meer te maken.

Werk tijdens pogingen om opnieuw verbinding te maken de gebruikersinterface van de app bij om de gebruiker op de hoogte te stellen dat er opnieuw verbinding wordt gemaakt.

Als u feedback over de gebruikersinterface wilt geven wanneer de verbinding wordt onderbroken, is de SignalR client-API uitgebreid met de volgende gebeurtenis-handlers:

• onreconnecting: biedt ontwikkelaars de mogelijkheid om de gebruikersinterface uit te schakelen of gebruikers te laten weten dat de app offline is.
• onreconnected: Biedt ontwikkelaars de mogelijkheid om de gebruikersinterface bij te werken zodra de verbinding opnieuw tot stand is gebracht.

De volgende code gebruikt onreconnecting om de gebruikersinterface bij te werken tijdens het maken van verbinding:

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

De volgende code gebruikt onreconnected om de gebruikersinterface bij te werken bij de verbinding:

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 of hoger biedt een aangepaste resource voor autorisatiehandlers wanneer voor een hubmethode autorisatie is vereist. De resource is een exemplaar van HubInvocationContext. Het HubInvocationContext omvat het volgende:

• HubCallerContext
• De naam van de hubmethode die wordt aangeroepen.
• Argumenten voor de hubmethode.

Bekijk het volgende voorbeeld van een chatruimte-app waarmee meerdere organisaties zich kunnen aanmelden via Azure Active Directory. Iedereen met een Microsoft-account kan zich aanmelden bij chatten, maar alleen leden van de organisatie die eigenaar zijn, kunnen gebruikers verbieden of chatgeschiedenis van gebruikers bekijken. De app kan bepaalde functionaliteit van specifieke gebruikers beperken.

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

In de voorgaande code dient DomainRestrictedRequirement als een aangepaste IAuthorizationRequirement. Omdat de HubInvocationContext resourceparameter wordt doorgegeven, kan de interne logica het volgende doen:

• Inspecteer de context waarin de Hub wordt aangeroepen.
• Neem beslissingen over het toestaan van de gebruiker om afzonderlijke Hub-methoden uit te voeren.

Afzonderlijke Hub-methoden kunnen worden gemarkeerd met de naam van het beleid dat de code tijdens runtime controleert. Wanneer clients proberen afzonderlijke Hub-methoden aan te roepen, wordt de DomainRestrictedRequirement handler uitgevoerd en de toegang tot de methoden beheerd. Op basis van de manier waarop de DomainRestrictedRequirement toegang wordt beheerd:

• Alle aangemelde gebruikers kunnen de SendMessage methode aanroepen.
• Alleen gebruikers die zich met een @jabbr.net e-mailadres hebben aangemeld, kunnen de geschiedenis van gebruikers bekijken.
• Alleen bob42@jabbr.net kan gebruikers uit de chatruimte verbannen.

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

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

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

Het maken van het DomainRestricted beleid kan betrekking hebben op:

• Voeg Startup.cs het nieuwe beleid toe.
• Geef de aangepaste DomainRestrictedRequirement vereiste op als parameter.
• Het registreren van DomainRestricted bij de autorisatie-middleware.

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

SignalR hubs maken gebruik van Eindpuntroutering. SignalR hubverbinding is eerder expliciet uitgevoerd:

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

In de vorige versie moesten ontwikkelaars controllers, Razor pagina's en hubs in verschillende plaatsen verbinden. Expliciete verbinding resulteert in een reeks bijna identieke routeringssegmenten:

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

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

SignalR 3.0-hubs kunnen worden gerouteerd middels eindpuntroutering. Met eindpuntroutering kan doorgaans alle routering worden geconfigureerd in UseRouting:

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

ASP.NET Core 3.0 SignalR toegevoegd:

Client-naar-server streaming. Met client-naar-serverstreaming kunnen serverzijdige methoden exemplaren van een IAsyncEnumerable<T> of ChannelReader<T> nemen. In het volgende C#-voorbeeld ontvangt de UploadStream methode op de Hub een stroom tekenreeksen van de client:

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

.NET-client-apps kunnen een IAsyncEnumerable<T> of ChannelReader<T> instantie doorgeven als het stream-argument van de UploadStream Hub-methode hierboven.

Nadat de for lus is voltooid en de lokale functie wordt afgesloten, wordt de stream voltooid verzonden:

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

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

JavaScript-client-apps gebruiken het SignalRSubject (of een RxJS-onderwerp) voor het stream argument van de UploadStream bovenstaande Hub-methode.

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

De JavaScript-code kan de subject.next methode gebruiken om tekenreeksen te verwerken wanneer ze worden vastgelegd en klaar zijn om naar de server te worden verzonden.

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

Met behulp van code zoals de twee voorgaande codefragmenten kunnen realtime streaming-ervaringen worden gemaakt.

Nieuwe JSON-serialisatie

ASP.NET Core 3.0 gebruikt System.Text.Json nu standaard voor JSON-serialisatie:

• Leest en schrijft JSON asynchroon.
• Is geoptimaliseerd voor UTF-8-tekst.
• Doorgaans hogere prestaties dan Newtonsoft.Json.

Zie Ondersteuning voor JSON-indeling op basis van Newtonsoft.Json toevoegen om Json.NET toe te voegen aan ASP.NET Core 3.0.

Nieuwe Razor voorschriften

De volgende lijst bevat nieuwe Razor richtlijnen:

• @attribute: De @attribute instructie past het opgegeven kenmerk toe op de klasse van de gegenereerde pagina of weergave. Bijvoorbeeld: @attribute [Authorize].
• @implements: De @implements richtlijn implementeert een interface voor de gegenereerde klasse. Bijvoorbeeld: @implements IDisposable.

IdentityServer4 ondersteunt verificatie en autorisatie voor web-API's en SPA's

ASP.NET Core 3.0 biedt verificatie in SPA's (Single Page Apps) met behulp van de ondersteuning voor web-API-autorisatie. ASP.NET Core Identity voor het verifiëren en opslaan van gebruikers wordt gecombineerd met IdentityServer4 voor het implementeren van OpenID Connect.

IdentityServer4 is een OpenID Connect- en OAuth 2.0-framework voor ASP.NET Core 3.0. Hiermee worden de volgende beveiligingsfuncties ingeschakeld:

• Verificatie als een service (AaaS)
• Eenmalige aanmelding/uit (SSO) voor meerdere toepassingstypen
• Toegangsbeheer voor API's
• Federatie-gateway

Zie de documentatie over IdentityServer4 of verificatie en autorisatie voor SPA's voor meer informatie.

Certificaat- en Kerberos-verificatie

Voor certificaatverificatie is het volgende vereist:

• De server configureren voor het accepteren van certificaten.
• De verificatie-middleware toevoegen in Startup.Configure.
• De certificaatverificatieservice toevoegen in 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.
}

Opties voor certificaatverificatie zijn onder andere de mogelijkheid om:

• Zelfondertekende certificaten accepteren.
• Controleer op certificaatintrekking.
• Controleer of het geprofferde certificaat de juiste gebruiksvlagken bevat.

Een standaardgebruikersprincipaal wordt samengesteld op basis van de certificaateigenschappen. De gebruikersprincipaal bevat een gebeurtenis waarmee de principal kan worden aangevuld of vervangen. Zie Certificaatverificatie configureren in ASP.NET Corevoor meer informatie.

Windows-verificatie is uitgebreid naar Linux en macOS. In eerdere versies was Windows-verificatie beperkt tot IIS en HTTP.sys. In ASP.NET Core 3.0 Kestrel heeft u de mogelijkheid om Negotiate, Kerberos en NTLM te gebruiken op Windows-, Linux- en macOS-hosts die lid zijn van een domein. Kestrel ondersteuning van deze verificatieschema's wordt geleverd door het NuGet-pakket Microsoft.AspNetCore.Authentication.Negotiate . Net als bij de andere verificatieservices configureert u de verificatie-app breed en configureert u vervolgens de service:

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

Hostvereisten:

• Windows-hosts moeten service-principalnamen (SPN's) hebben toegevoegd aan het gebruikersaccount dat als host fungeert voor de app.
• Linux- en macOS-machines moeten lid zijn van het domein.
  • SPN's moeten worden gemaakt voor het webproces.
  • Keytab-bestanden moeten worden gegenereerd en geconfigureerd op de hostcomputer.

Zie Windows-verificatie configureren in ASP.NET Corevoor meer informatie.

Sjabloonwijzigingen

De webgebruikersinterfacesjablonen (Razor Pagina's, MVC met controller en weergaven) hebben het volgende verwijderd:

• De cookie gebruikersinterface voor toestemming is niet meer opgenomen. Als u de cookie toestemmingsfunctie wilt inschakelen in een door een ASP.NET Core 3.0-sjabloon gegenereerde app, raadpleegt u de ondersteuning voor algemene verordening gegevensbescherming (AVG) in ASP.NET Core.
• Scripts en gerelateerde statische assets worden nu als lokale bestanden verwezen in plaats van cdn's te gebruiken. Voor meer informatie, zie Scripts en gerelateerde statische middelen worden nu als lokale bestanden aangeroepen in plaats van gebruik te maken van CDN's, afhankelijk van de huidige omgeving (dotnet/AspNetCore.Docs #14350).

De Angular-sjabloon is bijgewerkt voor gebruik van Angular 8.

De sjabloon van de Razor klasse-bibliotheek (RCL) is standaard ingesteld op Razor componentontwikkeling. Een nieuwe sjabloonoptie in Visual Studio biedt sjabloonondersteuning voor pagina's en weergaven. Wanneer u een RCL maakt op basis van de sjabloon in een opdrachtshell, geeft u de --support-pages-and-views optie (dotnet new razorclasslib --support-pages-and-views) door.

Algemene host

De ASP.NET Core 3.0-sjablonen gebruiken .NET Generic Host in ASP.NET Core. Vorige versies hebben WebHostBuilder gebruikt. Het gebruik van de .NET Core Generic Host (HostBuilder) biedt een betere integratie van ASP.NET Core-apps met andere serverscenario's die niet specifiek zijn voor het web. Zie HostBuilder vervangt WebHostBuilder voor meer informatie.

Hostconfiguratie

Vóór de release van ASP.NET Core 3.0 werden omgevingsvariabelen met het voorvoegsel ASPNETCORE_ geladen voor de hostconfiguratie van de webhost. In 3.0 AddEnvironmentVariables wordt gebruikt om omgevingsvariabelen met het voorvoegsel DOTNET_ voor hostconfiguratie te laden met CreateDefaultBuilder.

Wijzigingen in de opstartconstructor-injectie

De algemene host ondersteunt alleen de volgende typen voor Startup constructorinjectie:

• IHostEnvironment
• IWebHostEnvironment
• IConfiguration

Alle services kunnen nog steeds rechtstreeks als argumenten aan de Startup.Configure methode worden geïnjecteerd. Zie Generic Host beperkt opstartconstructorinjectie (aspnet/Aankondigingen #353) voor meer informatie.

Kestrel

• Kestrel de configuratie is bijgewerkt voor de migratie naar de algemene host. In 3.0 wordt Kestrel geconfigureerd op het webhostsysteem dat wordt geleverd door ConfigureWebHostDefaults.
• Verbindingsadapters zijn verwijderd uit Kestrel en vervangen door Connection Middleware, die vergelijkbaar is met HTTP Middleware in de ASP.NET Core-pijplijn, maar voor verbindingen op een lager niveau.
• De Kestrel transportlaag is beschikbaar gesteld als een openbare interface in Connections.Abstractions.
• Dubbelzinnigheid tussen headers en trailers is opgelost door volgheaders naar een nieuwe verzameling te verplaatsen.
• Synchrone I/O-API's, zoals HttpRequest.Body.Read, zijn een veelvoorkomende bron van thread-starvatie die leidt tot app-crashes. In 3.0 is AllowSynchronousIO standaard uitgeschakeld.

Zie Migreren van ASP.NET Core 2.2 naar 3.0 voor meer informatie.

HTTP/2 standaard ingeschakeld

HTTP/2 is standaard ingeschakeld in Kestrel voor HTTPS-eindpunten. HTTP/2-ondersteuning voor IIS of HTTP.sys wordt ingeschakeld wanneer dit wordt ondersteund door het besturingssysteem.

EventCounters op aanvraag

De Hosting EventSource, Microsoft.AspNetCore.Hostingverzendt de volgende nieuwe EventCounter typen met betrekking tot binnenkomende aanvragen:

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

Eindpuntroutering

Eindpuntroutering, waarmee frameworks (bijvoorbeeld MVC) goed kunnen werken met middleware, is verbeterd:

• De volgorde van middleware en eindpunten kan worden geconfigureerd in de pijplijn voor aanvraagverwerking van Startup.Configure.
• Eindpunten en middleware zijn goed samengesteld met andere ASP.NET Core-technologieën, zoals statuscontroles.
• Eindpunten kunnen een beleid, zoals CORS of autorisatie, implementeren in zowel middleware als MVC.
• Filters en kenmerken kunnen worden geplaatst op methoden in controllers.

Zie Routering in ASP.NET Core voor meer informatie.

Gezondheidscontroles

Statuscontroles gebruiken eindpuntroutering met de algemene host. Roep in Startup.ConfigureMapHealthChecks aan op de eindpuntbouwer met de eindpunt-URL of het relatieve pad:

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

Eindpunten voor gezondheidscontroles kunnen:

• Geef een of meer toegestane hosts/poorten op.
• Vereist autorisatie.
• CORS vereisen.

Zie de volgende artikelen voor meer informatie:

• Migreren van ASP.NET Core 2.2 naar 3.0
• Gezondheidscontroles in ASP.NET Core

Pipes op HttpContext

Het is nu mogelijk om de hoofdtekst van de aanvraag te lezen en de antwoordtekst te schrijven met behulp van de System.IO.Pipelines API. De HttpRequest.BodyReader eigenschap biedt een PipeReader eigenschap die kan worden gebruikt om de hoofdtekst van de aanvraag te lezen. De HttpResponse.BodyWriter eigenschap biedt een PipeWriter eigenschap die kan worden gebruikt om de hoofdtekst van het antwoord te schrijven. HttpRequest.BodyReader is een analoog van de HttpRequest.Body stroom. HttpResponse.BodyWriter is een analoog van de HttpResponse.Body stroom.

Verbeterde foutrapportage in IIS

Opstartfouten bij het hosten van ASP.NET Core-apps in IIS produceren nu uitgebreidere diagnostische gegevens. Deze fouten worden aan het Windows-gebeurtenislogboek gerapporteerd, met stacktraceringen waar van toepassing. Bovendien worden alle waarschuwingen, fouten en niet-verwerkte uitzonderingen vastgelegd in het Windows-gebeurtenislogboek.

Worker Service en Worker SDK

.NET Core 3.0 introduceert de nieuwe Worker Service-app-sjabloon. Deze sjabloon biedt een startpunt voor het schrijven van langlopende services in .NET Core.

Voor meer informatie, zie:

• .NET Core Workers als Windows Services
• Achtergrondtaken met gehoste services in ASP.NET Core
• Host ASP.NET Core in een Windows-service

Verbeteringen in Middleware voor doorgestuurde headers

In eerdere versies van ASP.NET Core was het aanroepen UseHsts en UseHttpsRedirection problematisch wanneer deze werd geïmplementeerd in een Azure Linux of achter een andere omgekeerde proxy dan IIS. De oplossing voor eerdere versies wordt beschreven in Doorsturen van het schema voor Linux- en niet-IIS reverse proxies.

Dit scenario is opgelost in ASP.NET Core 3.0. De host schakelt de Doorgestuurde Headers-middleware in wanneer de ASPNETCORE_FORWARDEDHEADERS_ENABLED omgevingsvariabele is ingesteld op true. ASPNETCORE_FORWARDEDHEADERS_ENABLED is ingesteld op true in onze containerafbeeldingen.

Prestatieverbeteringen

ASP.NET Core 3.0 bevat veel verbeteringen die het geheugengebruik verminderen en de doorvoer verbeteren:

• Vermindering van het geheugengebruik bij het gebruik van de ingebouwde container voor afhankelijkheidsinjectie voor scoped services.
• Vermindering van allocaties in het framework, waaronder middlewarescenario's en routeren.
• Vermindering van het geheugengebruik voor WebSocket-verbindingen.
• Geheugenreductie en doorvoerverbeteringen voor HTTPS-verbindingen.
• Nieuwe geoptimaliseerde en volledig asynchrone JSON-serializer.
• Vermindering van geheugengebruik en doorvoerverbeteringen in formulierparsering.

ASP.NET Core 3.0 wordt alleen uitgevoerd op .NET Core 3.0

Vanaf ASP.NET Core 3.0 is .NET Framework geen ondersteund doelframework meer. Projecten die gericht zijn op .NET Framework, kunnen op een volledig ondersteunde manier worden voortgezet met behulp van de .NET Core 2.1 LTS-release. De meeste ASP.NET Core 2.1.x gerelateerde pakketten worden voor onbepaalde tijd ondersteund, buiten de lts-periode van drie jaar voor .NET Core 2.1.

Zie Uw code overzetten van .NET Framework naar .NET Core voor informatie over migratie.

Het gedeelde ASP.NET Core-framework gebruiken

Voor het gedeelde ASP.NET Core 3.0-framework in de Microsoft.AspNetCore.App metapackage is geen expliciet <PackageReference /> element meer vereist in het projectbestand. Er wordt automatisch naar het gedeelde framework verwezen wanneer de Microsoft.NET.Sdk.Web SDK in het projectbestand wordt gebruikt:

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

Assembly's verwijderd uit het gedeelde ASP.NET Core-framework

De meest opvallende assembly's die zijn verwijderd uit het gedeelde framework ASP.NET Core 3.0 zijn:

• Newtonsoft.Json (Json.NET). Zie Ondersteuning voor JSON-indeling op basis van Newtonsoft.Json toevoegen om Json.NET toe te voegen aan ASP.NET Core 3.0. ASP.NET Core 3.0 introduceert System.Text.Json voor het lezen en schrijven van JSON. Zie Nieuwe JSON-serialisatie in dit document voor meer informatie.
• Entity Framework Core

Zie Assembly's die worden verwijderd uit Microsoft.AspNetCore.App 3.0 voor een volledige lijst met assembly's die zijn verwijderd uit het gedeelde framework. Zie Belangrijke wijzigingen in Microsoft.AspNetCore.App in 3.0 en een eerste blik op wijzigingen in ASP.NET Core 3.0 voor meer informatie over de motivatie voor deze wijziging.

Brekende wijzigingen

Gebruik de artikelen in Belangrijke wijzigingen in .NET om belangrijke wijzigingen te vinden die van toepassing kunnen zijn bij het upgraden van een app naar een nieuwere versie van .NET.