Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra le modifiche più significative in ASP.NET Core in .NET 11 con collegamenti alla documentazione pertinente.
Questo articolo verrà aggiornato man mano che vengono rese disponibili nuove versioni di anteprima.
Blazor
In questa sezione vengono descritte le nuove funzionalità per Blazor.
Nuovo DisplayName componente e supporto per gli attributi [Display] e [DisplayName]
Il DisplayName componente può essere usato per visualizzare i nomi delle proprietà dagli attributi dei metadati:
[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }
L'attributo[Display] nella proprietà della classe del modello è supportato:
[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }
Tra i due approcci, è consigliabile l'attributo [Display] , che rende disponibili proprietà aggiuntive. L'attributo abilita anche l'assegnazione [Display] di un tipo di risorsa per la localizzazione. Quando sono presenti entrambi gli attributi, [Display] ha la precedenza su [DisplayName]. Se nessun attributo è presente, il componente passa al nome della proprietà.
Usa il componente DisplayName nelle etichette o nelle intestazioni di tabella.
<label>
<DisplayName For="@(() => Model!.ProductionDate)" />
<InputDate @bind-Value="Model!.ProductionDate" />
</label>
Blazor Formato delle opzioni di avvio dello script Web ora supportato per gli script Blazor Server e Blazor WebAssembly
L'oggetto Blazor Web App opzioni script (blazor.web.js) passato a Blazor.start() utilizza il formato seguente a partire dal rilascio di .NET 8:
Blazor.start({
ssr: { ... },
circuit: { ... },
webAssembly: { ... },
});
Ora, Blazor Server gli script (blazor.server.js) e Blazor WebAssembly (blazor.webassembly.js) possono usare lo stesso formato di opzioni.
L'esempio seguente mostra il formato delle opzioni precedenti, che rimane supportato:
Blazor.start({
loadBootResource: function (...) {
...
},
});
Formato delle opzioni appena supportate per l'esempio precedente:
Blazor.start({
webAssembly: {
loadBootResource: function (...) {
...
},
},
});
Per altre informazioni, vedere ASP.NET Core Blazor startup.
Nuovo BasePath componente
Blazor Web Apps può usare il nuovo BasePath componente (<BasePath />) per eseguire automaticamente il rendering del tag HTML del percorso di base dell'app (<base href>). Per ulteriori informazioni, vedere il percorso di base dell'app ASP.NET Core.
Gestore eventi inline JS rimosso dal componente NavMenu
Il gestore eventi inline JS che attiva o disattiva la visualizzazione dei collegamenti di navigazione non è più presente nel componente NavMenu del modello di progetto Blazor Web App. Le app generate dal modello di progetto ora usano un approccio di modulo co-localizzato JS per mostrare o nascondere la barra di navigazione nella pagina sottoposta a rendering. Il nuovo approccio migliora la conformità al Content Security Policy (CSP) perché non richiede di includere un hash non sicuro per l'elemento inline JS.
Per eseguire la migrazione di un'app esistente a .NET 11, inclusa l'adozione del nuovo JS approccio per il selettore della barra di navigazione, consulta Eseguire la migrazione da ASP.NET Core in .NET 10 a ASP.NET Core in .NET 11.
Supporto di NavigateTo e NavLink per la navigazione relativa
Il nuovo RelativeToCurrentUri parametro (impostazione predefinita: false) per NavigationManager.NavigateTo e il NavLink componente consente di passare agli URI relativi al percorso della pagina corrente anziché all'URI di base dell'app.
Prendere in considerazione i seguenti endpoint annidati:
/docs/getting-started/installation/configuration
Quando l'URI del browser è /docs/getting-started/installation e vuoi navigare l'utente verso /docs/getting-started/configuration, NavigateTo("/configuration") reindirizza a /configuration, la radice dell'app, anziché al percorso relativo il /docs/getting-started/configuration. Imposta il RelativeToCurrentUri con NavigateTo o il componente NavLink per la navigazione desiderata.
Navigation.NavigateTo("/configuration", new NavigationOptions
{
RelativeToCurrentUri = true
});
<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>
Rendere persistenti i dati temporanei tra le richieste HTTP durante il rendering statico lato server (static SSR)
Per rendere persistenti i dati temporanei tra le richieste HTTP durante il rendering statico lato server (SSR statico), Blazor supporta TempData. TempData è ideale per scenari come i messaggi flash dopo gli invii di moduli, il passaggio dei dati durante i reindirizzamenti (modello POST-Redirect-GET) e le notifiche monouso.
TempData è disponibile quando AddRazorComponents viene chiamato nel file dell'app Program e viene fornito come valore a cascata con l'attributo [CascadingParameter].
[CascadingParameter]
public ITempData? TempData { get; set; }
Per ulteriori informazioni, vedere gestione dello stato lato server in ASP.NET CoreBlazor.
Blazor Hybrid
In questa sezione vengono descritte le nuove funzionalità per Blazor Hybrid.
Le note sulla versione vengono visualizzate in questa sezione man mano che diventano disponibili le funzionalità di anteprima.
SignalR
In questa sezione vengono descritte le nuove funzionalità per SignalR.
API minimali
Questa sezione descrive le nuove funzionalità per le API minime.
OpenAPI
Questa sezione descrive le nuove funzionalità per OpenAPI.
Descrivere le risposte ai file binari
ASP.NET Core 11 introduce il supporto per la generazione di descrizioni OpenAPI per le operazioni che restituiscono risposte di file binari. La funzionalità mappa il tipo di risultato FileContentResult a uno schema OpenAPI con type: string e format: binary.
Usare il Produces<T> metodo di estensione con T di FileContentResult per specificare il tipo di risposta e il tipo di contenuto:
app.MapPost("/filecontentresult", () =>
{
var content = "This endpoint returns a FileContentResult!"u8.ToArray();
return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);
Il documento OpenAPI generato descrive la risposta dell'endpoint come segue:
responses:
'200':
description: OK
content:
application/octet-stream:
schema:
$ref: '#/components/schemas/FileContentResult'
l'oggetto FileContentResult è definito in components/schemas come:
components:
schemas:
FileContentResult:
type: string
format: binary
Supporto di OpenAPI 3.2.0 (cambiamento significativo)
Microsoft.AspNetCore.OpenApi supporta ora OpenAPI 3.2.0 tramite una dipendenza aggiornata dalla Microsoft.OpenApi versione 3.3.1. Questo aggiornamento include modifiche di rilievo dalla libreria sottostante. Per altre informazioni, vedere la guida all'aggiornamento di Microsoft.OpenApi.
Per generare un documento OpenAPI 3.2.0, specificare la versione quando si chiama AddOpenApi:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});
Gli aggiornamenti successivi sfruttano le nuove funzionalità nella specifica 3.2.0, ad esempio il supporto dello schema degli elementi per gli eventi di streaming.
Grazie @baywet per questo contributo!
Autenticazione e autorizzazione
In questa sezione vengono descritte le nuove funzionalità per l'autenticazione e l'autorizzazione.
TimeProvider supporto in ASP.NET Core Identity
ASP.NET Core Identity usa TimeProvider ora anziché DateTime e DateTimeOffset per tutte le operazioni correlate al tempo. Questa modifica rende Identity i componenti più testabili e offre un migliore controllo nel tempo nei test e negli scenari specializzati.
L'esempio seguente illustra come usare un falso TimeProvider per le funzionalità di test Identity :
// In tests
var fakeTimeProvider = new FakeTimeProvider(
new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));
services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();
// Identity will now use the fake time provider
Usando TimeProvider, è possibile scrivere più facilmente test deterministici per funzionalità sensibili al Identity tempo, ad esempio la scadenza del token, la durata del blocco e la convalida dello stamp di sicurezza.
Dedurre il nome chiave di accesso visualizzato dall'autenticatore
ASP.NET Core Identity ora deduce automaticamente i nomi visualizzati amichevoli per le chiavi d'accesso in base al loro AAGUID (Authenticator Attestation GUID). I mapping predefiniti sono inclusi per gli autenticatori passkey usati più di frequente, tra cui Google Password Manager, iCloud Keychain, Windows Hello, 1Password e Bitwarden.
Per gli autenticatori noti, il nome viene assegnato automaticamente senza chiedere conferma all'utente. Per gli autenticatori sconosciuti, l'utente viene reindirizzato a una pagina di ridenominazione. Estendere i mapping aggiungendo voci al dizionario PasskeyAuthenticators nel progetto.
Miscellaneous
Questa sezione descrive varie nuove funzionalità di .NET 11.
interfaccia IOutputCachePolicyProvider
ASP.NET Core in .NET 11 fornisce l'interfaccia [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)' per implementare la logica di selezione dei criteri di memorizzazione nella cache dell'output personalizzata. Usando questa interfaccia, le app possono determinare i criteri di memorizzazione nella cache di base predefiniti, verificare l'esistenza di criteri denominati e supportare scenari avanzati in cui i criteri devono essere risolti in modo dinamico. Gli esempi includono il caricamento di criteri da fonti di configurazione esterne, dalle database, o l'applicazione di regole di caching specifiche per l'inquilino.
Il codice seguente illustra l'interfaccia IOutputCachePolicyProvider :
public interface IOutputCachePolicyProvider
{
IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}
Grazie @lqlive per questo contributo!
Certificati di sviluppo con attendibilità automatica in WSL
L'installazione del certificato di sviluppo considera automaticamente attendibili i certificati negli ambienti WSL (Sottosistema Windows per Linux). Quando si esegue dotnet dev-certs https --trust in WSL, il certificato viene installato e considerato attendibile automaticamente sia nell'ambiente WSL che in Windows, eliminando la configurazione dell'attendibilità manuale.
# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust
Questo miglioramento semplifica l'esperienza di sviluppo quando si usa WSL, rimuovendo un punto di attrito comune per gli sviluppatori che lavorano in ambienti Linux in Windows.
Grazie @StickFun per questo contributo!
Tracciamento OpenTelemetry nativo per ASP.NET Core
ASP.NET Core aggiunge ora in modo nativo gli attributi della convenzione semantica OpenTelemetry all'attività del server HTTP, in linea con la specifica dell'intervallo di server HTTP OpenTelemetry. Tutti gli attributi obbligatori sono inclusi per impostazione predefinita, corrispondenti ai metadati disponibili in precedenza solo tramite la OpenTelemetry.Instrumentation.AspNetCore libreria.
Per raccogliere i dati di tracciamento predefiniti, iscriversi all'origine di attività Microsoft.AspNetCore nella configurazione di OpenTelemetry.
builder.Services.AddOpenTelemetry()
.WithTracing(tracing => tracing
.AddSource("Microsoft.AspNetCore")
.AddConsoleExporter());
Non è necessaria alcuna libreria di strumentazione aggiuntiva, ad esempio OpenTelemetry.Instrumentation.AspNetCore. Il framework ora popola direttamente gli attributi della convenzione semantica per l'attività di richiesta, ad esempio http.request.method, url.path, http.response.status_codee server.address.
Se non si desidera aggiungere attributi OpenTelemetry all'attività, è possibile disattivarlo impostando l'opzione Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData AppContext su true.
Miglioramenti delle prestazioni
KestrelIl parser di richiesta HTTP/1.1 ora utilizza un percorso di codice che non genera eccezioni per la gestione delle richieste malformate. Anziché generare BadHttpRequestException in ogni errore di analisi, il parser restituisce una struttura di risultato che indica stati di successo, incompleti o di errore. Negli scenari con molte richieste malformate, come l'analisi delle porte, il traffico dannoso o i client configurati in modo errato, elimina il costoso sovraccarico di gestione delle eccezioni e migliora il throughput fino al 20-40%. Non c'è alcun impatto sull'elaborazione valida delle richieste.
Il middleware di registrazione HTTP ora utilizza pool per le ResponseBufferingStream istanze, riducendo le allocazioni per ogni richiesta quando il corpo di risposta o gli intercettori sono abilitati.
Modifiche radicali
Usare gli articoli in Modifiche di rilievo in .NET per trovare modifiche di rilievo che potrebbero essere applicate durante l'aggiornamento di un'app a una versione più recente di .NET.
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
