Novità di ASP.NET Core 3.0

Questo articolo illustra le modifiche più significative in ASP.NET Core 3.0 con collegamenti alla documentazione pertinente.

Blazor

Blazor è un nuovo framework in ASP.NET Core per la creazione di un'interfaccia utente Web sul lato client interattiva con .NET:

• Creare interfacce utente interattive avanzate con C#.
• Condividere la logica dell'app scritta in .NET sul lato client e sul lato server.
• Eseguire il rendering dell'interfaccia utente come HTML e CSS per un ampio supporto dei browser, inclusi i browser per dispositivi mobili.

Blazor scenari supportati dal framework:

• Componenti dell'interfaccia utente riutilizzabili (Razor componenti)
• Routing a lato client
• Layout dei componenti
• Supporto per l'inserimento delle dipendenze
• Moduli e convalida
• Fornire Razor componenti nelle Razor librerie di classi
• Interoperabilità JavaScript

Per altre informazioni, vedere ASP.NET CoreBlazor.

Blazor Server

Blazor separa la logica di rendering dei componenti dalla modalità di applicazione degli aggiornamenti dell'interfaccia utente. Blazor Server fornisce il supporto per ospitare componenti Razor nel server in un'app ASP.NET Core. Gli aggiornamenti dell'interfaccia utente vengono gestiti tramite una connessione SignalR. Blazor Server è supportato in ASP.NET Core 3.0.

Blazor WebAssembly (Anteprima)

Blazor Le app possono essere eseguite direttamente nel browser usando un runtime .NET basato su WebAssembly. Blazor WebAssembly è in anteprima e non è supportato in ASP.NET Core 3.0. Blazor WebAssembly sarà supportato in una versione futura di ASP.NET Core.

Componenti di Razor

Blazor le app vengono create dai componenti. I componenti sono blocchi autonomi dell'interfaccia utente, ad esempio una pagina, una finestra di dialogo o un modulo. I componenti sono classi .NET normali che definiscono la logica di rendering dell'interfaccia utente e i gestori eventi lato client. È possibile creare app Web interattive avanzate senza JavaScript.

I componenti in Blazor vengono in genere creati usando Razor la sintassi, una miscela naturale di HTML e C#. Razor i componenti sono simili alle Razor visualizzazioni Pages e MVC in quanto usano Razorentrambi . A differenza delle pagine e delle visualizzazioni, basate su un modello di richiesta-risposta, i componenti vengono usati in modo specifico per la gestione della composizione dell'interfaccia utente.

gRPC

gRPC:

• È un framework RPC (remote procedure call) a prestazioni elevate.

• Offre un approccio con contratto-primo parere allo sviluppo di API.

• Usa tecnologie moderne, ad esempio:

  • HTTP/2 per il trasporto.
  • Buffer di protocollo come linguaggio di descrizione dell'interfaccia.
  • Formato di serializzazione binaria.

• Fornisce funzionalità come:

  • Autenticazione
  • Flusso bidirezionale e controllo del flusso.
  • Annullamento e timeout.

La funzionalità gRPC in ASP.NET Core 3.0 include:

• Grpc.AspNetCore: framework ASP.NET Core per l'hosting di servizi gRPC. gRPC in ASP.NET Core si integra con funzionalità standard ASP.NET Core come la registrazione, l'inserimento delle dipendenze (DI), l'autenticazione e l'autorizzazione.
• Grpc.Net.Client: un client gRPC per .NET Core basato su HttpClient.
• Grpc.Net.ClientFactory: integrazione client gRPC con HttpClientFactory.

Per altre informazioni, vedere Panoramica di gRPC in .NET.

SignalR

Per istruzioni sulla migrazione, vedere Aggiornare SignalR il codice . SignalR ora usa System.Text.Json per serializzare/deserializzare i messaggi JSON. Vedere Passare a Newtonsoft.Json per istruzioni sul ripristino del Newtonsoft.Jsonserializzatore basato su .

Nel client JavaScript e .NET per SignalRè stato aggiunto il supporto per la riconnessione automatica. Per impostazione predefinita, il client tenta di riconnettersi immediatamente e riprovare dopo 2, 10 e 30 secondi, se necessario. Se il client si riconnette correttamente, riceve un nuovo ID connessione. La riconnessione automatica è il consenso esplicito:

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

È possibile specificare gli intervalli di riconnessione passando una matrice di durate basate su millisecondi:

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

È possibile passare un'implementazione personalizzata per il controllo completo degli intervalli di riconnessione.

Se la riconnessione non riesce dopo l'ultimo intervallo di riconnessione:

• Il client considera la connessione offline.
• Il client smette di tentare di riconnettersi.

Durante i tentativi di riconnessione, aggiornare l'interfaccia utente dell'app per notificare all'utente che viene tentata la riconnessione.

Per fornire feedback sull'interfaccia utente quando la connessione viene interrotta, l'API SignalR client è stata espansa per includere i gestori eventi seguenti:

• onreconnecting: consente agli sviluppatori di disabilitare l'interfaccia utente o di informare gli utenti che l'app è offline.
• onreconnected: offre agli sviluppatori l'opportunità di aggiornare l'interfaccia utente una volta ristabilita la connessione.

Il codice seguente usa onreconnecting per aggiornare l'interfaccia utente durante il tentativo di connessione:

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

Il codice seguente usa onreconnected per aggiornare l'interfaccia utente alla connessione:

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 e versioni successive fornisce una risorsa personalizzata per i gestori di autorizzazione quando un metodo hub richiede l'autorizzazione. La risorsa è un'istanza di HubInvocationContext. Include HubInvocationContext :

• HubCallerContext
• Nome del metodo hub richiamato.
• Argomenti per il metodo hub.

Si consideri l'esempio seguente di un'app chat room che consente l'accesso a più organizzazioni tramite Azure Active Directory. Chiunque abbia un account Microsoft può accedere alla chat, ma solo i membri dell'organizzazione proprietaria possono impedire agli utenti o visualizzare le cronologie delle chat degli utenti. L'app potrebbe limitare determinate funzionalità da utenti specifici.

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

Nel codice precedente funge DomainRestrictedRequirement da oggetto personalizzato IAuthorizationRequirement. Poiché il HubInvocationContext parametro della risorsa viene passato, la logica interna può:

• Esaminare il contesto in cui viene chiamato l'hub.
• Prendere decisioni su come consentire all'utente di eseguire singoli metodi hub.

I singoli metodi hub possono essere contrassegnati con il nome del criterio, i controlli del codice in fase di esecuzione. Quando i client tentano di chiamare singoli metodi hub, il DomainRestrictedRequirement gestore esegue e controlla l'accesso ai metodi. In base al modo in cui controlla l'accesso DomainRestrictedRequirement :

• Tutti gli utenti connessi possono chiamare il SendMessage metodo .
• Solo gli utenti che hanno eseguito l'accesso con un @jabbr.net indirizzo di posta elettronica possono visualizzare le cronologie degli utenti.
• Solo bob42@jabbr.net gli utenti possono essere vietati dalla chat room.

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

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

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

La creazione dei criteri DomainRestricted potrebbe comportare:

• In Startup.csaggiungere i nuovi criteri.
• Specificare il requisito personalizzato DomainRestrictedRequirement come parametro.
• Registrazione DomainRestricted con il middleware di autorizzazione.

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

SignalR gli hub usano il routing degli endpoint. SignalR La connessione hub è stata eseguita in precedenza in modo esplicito:

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

Nella versione precedente, gli sviluppatori hanno bisogno di collegare controller, Razor pagine e hub in un'ampia gamma di posizioni. La connessione esplicita comporta una serie di segmenti di routing quasi identici:

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

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

SignalR Gli hub 3.0 possono essere instradati tramite il routing degli endpoint. Con il routing degli endpoint, in genere è possibile configurare tutto il routing in UseRouting:

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

ASP.NET Core 3.0 SignalR aggiunto:

Streaming da client a server. Con lo streaming da client a server, i metodi lato server possono accettare istanze di o IAsyncEnumerable<T> ChannelReader<T>. Nell'esempio C# seguente, il UploadStream metodo nell'hub riceverà un flusso di stringhe dal client:

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

Le app client .NET possono passare un'istanza IAsyncEnumerable<T> o ChannelReader<T> come stream argomento del UploadStream metodo Hub precedente.

Al termine del for ciclo e al termine della funzione locale, viene inviato il completamento del flusso:

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

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

Le app client JavaScript usano ( SignalRSubject o un oggetto RxJS) per l'argomento stream del UploadStream metodo Hub precedente.

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

Il codice JavaScript può usare il subject.next metodo per gestire le stringhe durante l'acquisizione e la preparazione per l'invio al server.

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

Usando codice come i due frammenti di codice precedenti, è possibile creare esperienze di streaming in tempo reale.

Nuova serializzazione JSON

ASP.NET Core 3.0 ora usa System.Text.Json per impostazione predefinita per la serializzazione JSON:

• Legge e scrive JSON in modo asincrono.
• È ottimizzato per il testo UTF-8.
• In genere prestazioni più elevate rispetto a Newtonsoft.Json.

Per aggiungere Json.NET a ASP.NET Core 3.0, vedere Aggiungere il supporto per il formato JSON basato su Newtonsoft.Json.

Nuove Razor direttive

L'elenco seguente contiene nuove Razor direttive:

• @attribute: la @attribute direttiva applica l'attributo specificato alla classe della pagina o della vista generata. Ad esempio: @attribute [Authorize].
• @implements: la @implements direttiva implementa un'interfaccia per la classe generata. Ad esempio: @implements IDisposable.

IdentityServer4 supporta l'autenticazione e l'autorizzazione per le API Web e gli account di servizio

ASP.NET Core 3.0 offre l'autenticazione in App a pagina singola usando il supporto per l'autorizzazione api Web. ASP.NET Core Identity per l'autenticazione e l'archiviazione degli utenti viene combinato con IdentityServer4 per l'implementazione di OpenID Connect.

IdentityServer4 è un framework OpenID Connect e OAuth 2.0 per ASP.NET Core 3.0. Abilita le funzionalità di sicurezza seguenti:

• Autenticazione come servizio (AaaS)
• Single Sign-On/off (SSO) su più tipi di applicazione
• Controllo di accesso per le API
• Gateway federativo

Per altre informazioni, vedere la documentazione di IdentityServer4 o Autenticazione e autorizzazione per le applicazioni a pagina singola.

Autenticazione di certificati e Kerberos

L'autenticazione del certificato richiede:

• Configurazione del server per accettare i certificati.
• Aggiunta del middleware di autenticazione in Startup.Configure.
• Aggiunta del servizio di autenticazione del certificato 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.
}

Le opzioni per l'autenticazione del certificato includono la possibilità di:

• Accettare certificati autofirmato.
• Verificare la revoca dei certificati.
• Verificare che nel certificato proffered siano presenti i flag di utilizzo corretti.

Un'entità utente predefinita viene costruita dalle proprietà del certificato. L'entità utente contiene un evento che consente di integrare o sostituire l'entità. Per altre informazioni, vedere Configurare l'autenticazione del certificato in ASP.NET Core.

L'autenticazione di Windows è stata estesa a Linux e macOS. Nelle versioni precedenti, l'autenticazione di Windows era limitata a IIS e HTTP.sys. In ASP.NET Core 3.0 è Kestrel possibile usare Negotiate, Kerberos e NTLM in Windows, Linux e macOS per gli host aggiunti a un dominio Windows. Kestrel il supporto di questi schemi di autenticazione viene fornito dal pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate. Come con gli altri servizi di autenticazione, configurare l'app di autenticazione a livello di app, quindi configurare il servizio:

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

Requisiti dell'host:

• Gli host di Windows devono avere nomi SPN (Service Principal Names ) aggiunti all'account utente che ospita l'app.
• I computer Linux e macOS devono essere aggiunti al dominio.
  • I nomi SPN devono essere creati per il processo Web.
  • I file Keytab devono essere generati e configurati nel computer host.

Per altre informazioni, vedere Configurare l'autenticazione di Windows in ASP.NET Core.

Modifiche del modello

I modelli di interfaccia utente Web (Razor Pagine, MVC con controller e visualizzazioni) hanno rimosso quanto segue:

• L'interfaccia cookie utente del consenso non è più inclusa. Per abilitare la cookie funzionalità di consenso in un'app generata dal modello di ASP.NET Core 3.0, vedere Supporto del Regolamento generale sulla protezione dei dati (GDPR) in ASP.NET Core.
• Gli script e gli asset statici correlati vengono ora indicati come file locali invece di usare reti CDN. Per altre informazioni, vedere Gli script e gli asset statici correlati vengono ora indicati come file locali anziché usare reti CDN basate sull'ambiente corrente (dotnet/AspNetCore.Docs #14350).

Il modello Angular è stato aggiornato per l'uso di Angular 8.

Per impostazione predefinita, il Razor modello della libreria di classi (RCL) è Razor lo sviluppo di componenti. Una nuova opzione di modello in Visual Studio offre il supporto dei modelli per pagine e visualizzazioni. Quando si crea un RCL dal modello in una shell dei comandi, passare l'opzione --support-pages-and-views (dotnet new razorclasslib --support-pages-and-views).

Host generico

I modelli di ASP.NET Core 3.0 usano l'host generico .NET in ASP.NET Core. Le versioni precedenti usano WebHostBuilder. L'uso dell'host generico .NET Core (HostBuilder) offre una migliore integrazione delle app ASP.NET Core con altri scenari server non specifici del Web. Per altre informazioni, vedere HostBuilder sostituisce WebHostBuilder.

Configurazione dell'host

Prima del rilascio di ASP.NET Core 3.0, le variabili di ambiente con prefisso ASPNETCORE_ sono state caricate per la configurazione host dell'host. Nella versione 3.0 viene AddEnvironmentVariables usato per caricare le variabili di ambiente precedute DOTNET_ da per la configurazione dell'host con CreateDefaultBuilder.

Modifiche all'inserimento del costruttore di avvio

L'host generico supporta solo i tipi seguenti per Startup l'inserimento del costruttore:

• IHostEnvironment
• IWebHostEnvironment
• IConfiguration

Tutti i servizi possono comunque essere inseriti direttamente come argomenti al Startup.Configure metodo . Per altre informazioni, vedere Generic Host restricts Startup constructor injection (aspnet/Announcements #353).

Kestrel

• Kestrel la configurazione è stata aggiornata per la migrazione all'host generico. Nella versione 3.0, Kestrel è configurato nel generatore di host Web fornito da ConfigureWebHostDefaults.
• Le schede di connessione sono state rimosse da Kestrel e sostituite con il middleware di connessione, simile al middleware HTTP nella pipeline ASP.NET Core, ma per le connessioni di livello inferiore.
• Il Kestrel livello di trasporto è stato esposto come interfaccia pubblica in Connections.Abstractions.
• L'ambiguità tra intestazioni e trailer è stata risolta spostando le intestazioni finali in una nuova raccolta.
• Le API di I/O sincrone, ad esempio HttpRequest.Body.Read, sono un'origine comune di fame di thread che causa arresti anomali dell'app. La versione 3.0 AllowSynchronousIO è disabilitata per impostazione predefinita.

Per altre informazioni, vedere Eseguire la migrazione da ASP.NET Core 2.2 a 3.0.

HTTP/2 abilitato per impostazione predefinita

HTTP/2 è abilitato per impostazione predefinita in Kestrel per gli endpoint HTTPS. Il supporto HTTP/2 per IIS o HTTP.sys è abilitato se supportato dal sistema operativo.

EventCounters su richiesta

Hosting EventSource, Microsoft.AspNetCore.Hosting, genera i nuovi EventCounter tipi seguenti correlati alle richieste in ingresso:

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

Routing degli endpoint

Il routing degli endpoint, che consente ai framework (ad esempio, MVC) di funzionare correttamente con il middleware, è stato migliorato:

• L'ordine dei middleware e degli endpoint è configurabile nella pipeline di elaborazione delle richieste di Startup.Configure.
• Gli endpoint e il middleware si compongono bene con altre tecnologie basate su core ASP.NET, ad esempio controlli di integrità.
• Gli endpoint possono implementare criteri, ad esempio CORS o autorizzazione, sia nel middleware che in MVC.
• I filtri e gli attributi possono essere inseriti nei metodi nei controller.

Per altre informazioni, vedere Routing in ASP.NET Core.

Controlli di integrità

I controlli di integrità usano il routing degli endpoint con l'host generico. In Startup.Configurechiamare MapHealthChecks sul generatore di endpoint con l'URL dell'endpoint o il percorso relativo:

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

Gli endpoint dei controlli di integrità possono:

• Specificare uno o più host/porte consentiti.
• Richiedere l'autorizzazione.
• Richiedere CORS.

Per altre informazioni, vedere gli articoli seguenti:

• Eseguire la migrazione da ASP.NET Core 2.2 a 3.0
• Controlli di integrità in ASP.NET Core

Pipe su HttpContext

È ora possibile leggere il corpo della richiesta e scrivere il corpo della risposta usando l'API System.IO.Pipelines . La HttpRequest.BodyReader proprietà fornisce un PipeReader oggetto che può essere utilizzato per leggere il corpo della richiesta. La HttpResponse.BodyWriter proprietà fornisce un PipeWriter oggetto che può essere utilizzato per scrivere il corpo della risposta. HttpRequest.BodyReader è un analogo del HttpRequest.Body flusso. HttpResponse.BodyWriter è un analogo del HttpResponse.Body flusso.

Miglioramento della segnalazione degli errori in IIS

Gli errori di avvio quando si ospitano ASP.NET app Core in IIS ora producono dati di diagnostica più avanzati. Questi errori vengono segnalati al registro eventi di Windows con le tracce dello stack, ovunque applicabile. Inoltre, tutti gli avvisi, gli errori e le eccezioni non gestite vengono registrati nel registro eventi di Windows.

Worker Service and Worker SDK

.NET Core 3.0 introduce il nuovo modello di app del servizio di lavoro. Questo modello fornisce un punto di partenza per la scrittura di servizi a esecuzione prolungata in .NET Core.

Per altre informazioni, vedi:

• Ruoli di lavoro .NET Core come servizi Windows
• Attività in background con servizi ospitati in ASP.NET Core
• Ospitare ASP.NET Core in un servizio Windows

Miglioramenti del middleware delle intestazioni inoltrate

Nelle versioni precedenti di ASP.NET Core, la chiamata UseHsts e UseHttpsRedirection sono stati problematici quando sono stati distribuiti in Un Linux di Azure o dietro qualsiasi proxy inverso diverso da IIS. La correzione per le versioni precedenti è documentata in Inoltrare lo schema per i proxy inversi di Linux e non IIS.

Questo scenario è stato risolto in ASP.NET Core 3.0. L'host abilita il middleware delle intestazioni inoltrate quando la ASPNETCORE_FORWARDEDHEADERS_ENABLED variabile di ambiente è impostata su true. ASPNETCORE_FORWARDEDHEADERS_ENABLED è impostato su true nelle immagini del contenitore.

Miglioramenti delle prestazioni

ASP.NET Core 3.0 include numerosi miglioramenti che riducono l'utilizzo della memoria e migliorano la velocità effettiva:

• Riduzione dell'utilizzo della memoria quando si usa il contenitore di inserimento delle dipendenze predefinito per i servizi con ambito.
• Riduzione delle allocazioni nel framework, inclusi scenari middleware e routing.
• Riduzione dell'utilizzo della memoria per le connessioni WebSocket.
• Miglioramenti della riduzione della memoria e velocità effettiva per le connessioni HTTPS.
• Nuovo serializzatore JSON ottimizzato e completamente asincrono.
• Riduzione dell'utilizzo della memoria e dei miglioramenti della velocità effettiva nell'analisi dei moduli.

ASP.NET Core 3.0 viene eseguito solo in .NET Core 3.0

A partire da ASP.NET Core 3.0, .NET Framework non è più un framework di destinazione supportato. I progetti destinati a .NET Framework possono continuare in modo completamente supportato usando la versione LTS di .NET Core 2.1. La maggior parte dei pacchetti correlati ASP.NET Core 2.1.x sarà supportata a tempo indeterminato, oltre il periodo LTS di tre anni per .NET Core 2.1.

Per informazioni sulla migrazione, vedere Convertire il codice da .NET Framework a .NET Core.

Usare il framework condiviso ASP.NET Core

Il framework condiviso ASP.NET Core 3.0, contenuto nel metapacchetto Microsoft.AspNetCore.App, non richiede più un elemento esplicito <PackageReference /> nel file di progetto. Il framework condiviso viene fatto automaticamente riferimento quando si usa l'SDK Microsoft.NET.Sdk.Web nel file di progetto:

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

Assembly rimossi dal framework condiviso ASP.NET Core

Gli assembly più importanti rimossi dal framework condiviso ASP.NET Core 3.0 sono:

• Newtonsoft.Json (Json.NET). Per aggiungere Json.NET a ASP.NET Core 3.0, vedere Aggiungere il supporto per il formato JSON basato su Newtonsoft.Json. ASP.NET Core 3.0 introduce System.Text.Json la lettura e la scrittura di JSON. Per altre informazioni, vedere Nuova serializzazione JSON in questo documento.
• Entity Framework Core

Per un elenco completo degli assembly rimossi dal framework condiviso, vedere Assembly rimossi da Microsoft.AspNetCore.App 3.0. Per altre informazioni sulla motivazione di questa modifica, vedere Modifiche di rilievo a Microsoft.AspNetCore.App nella versione 3.0 e Un primo sguardo alle modifiche in arrivo in ASP.NET Core 3.0.