Linee guida sull'utilizzo

Microsoft.AspNetCore.SystemWebAdapters fornisce un livello di emulazione per simulare il comportamento dal framework di ASP.NET in ASP.NET Core. Di seguito sono riportate alcune linee guida per alcune considerazioni relative all'uso:

HttpContext vita

Gli adattatori sono supportati da HttpContext che non possono essere utilizzati oltre la durata di una richiesta. Pertanto, HttpContext quando viene eseguito in ASP.NET Core non può essere usato anche dopo una richiesta, mentre in ASP.NET Framework funzionerebbe a volte. Verrà generata un'eccezione ObjectDisposedException nei casi in cui viene usata oltre la fine di una richiesta.

Raccomandazione: archiviare i valori necessari in poco e tenerli in attesa.

Conversione in HttpContext

Esistono due modi per convertire un oggetto HttpContext in un HttpContextoggetto :

• Cast implicito
• Utilizzo del costruttore

Raccomandazione: per la maggior parte dei casi, il cast implicito deve essere preferito perché memorizza nella cache l'istanza creata e garantisce solo una singola HttpContext richiesta.

CurrentCulture non è impostato per impostazione predefinita

In ASP.NET Framework CurrentCulture è stato impostato per una richiesta, ma questa operazione non viene eseguita automaticamente in ASP.NET Core. È invece necessario aggiungere il middleware appropriato alla pipeline.

Raccomandazione: vedere ASP.NET Core Localization (Localizzazione principale di ASP.NET) per informazioni dettagliate su come abilitare questa funzionalità.

Il modo più semplice per abilitare questo comportamento con un comportamento simile a quello di ASP.NET Framework consiste nell'aggiungere quanto segue alla pipeline:

app.UseRequestLocalization();

CurrentPrincipal

In ASP.NET Framework CurrentPrincipal e Current verrebbe impostato sull'utente corrente. Questa opzione non è disponibile in ASP.NET Core predefinita. Il supporto per questa funzionalità è disponibile con questi adattatori aggiungendo ISetThreadCurrentPrincipal all'endpoint (disponibile per i controller tramite ).SetThreadCurrentPrincipalAttribute Tuttavia, deve essere usato solo se non è possibile effettuare il refactoring del codice per rimuovere l'utilizzo.

Raccomandazione: se possibile, usare la proprietà User o User passandola al sito di chiamata. Se non è possibile, abilitare l'impostazione dell'utente corrente e prendere in considerazione anche l'impostazione della richiesta come thread singolo logico (vedere di seguito per informazioni dettagliate).

Il thread di richiesta non esiste in ASP.NET Core

In ASP.NET Framework una richiesta aveva affinità di thread e Current sarebbe disponibile solo se in tale thread. ASP.NET Core non dispone di questa garanzia, pertanto Current sarà disponibile nello stesso contesto asincrono, ma non vengono effettuate garanzie sui thread.

Raccomandazione: se si legge o si scrive in HttpContext, è necessario assicurarsi di farlo in modo a thread singolo. È possibile forzare l'esecuzione simultanea di una richiesta in qualsiasi contesto asincrono impostando .ISingleThreadedRequestMetadata Ciò avrà implicazioni sulle prestazioni e deve essere usato solo se non è possibile effettuare il refactoring dell'utilizzo per garantire l'accesso non simultaneo. È disponibile un'implementazione per l'aggiunta ai controller con SingleThreadedRequestAttribute:

[SingleThreadedRequest]
public class SomeController : Controller
{
    ...
} 

Request potrebbe essere necessario prebufferare

Per impostazione predefinita, la richiesta in ingresso non è sempre ricercabile né completamente disponibile. Per ottenere un comportamento visualizzato in .NET Framework, è possibile acconsentire esplicitamente al prebuffering del flusso di input. In questo modo il flusso in ingresso verrà letto completamente e memorizzato nel buffer in memoria o su disco (a seconda delle impostazioni).

Raccomandazione: questa opzione può essere abilitata applicando i metadati dell'endpoint che implementano l'interfaccia IPreBufferRequestStreamMetadata . Questa opzione è disponibile come attributo PreBufferRequestStreamAttribute che può essere applicato a controller o metodi.

Per abilitare questa operazione in tutti gli endpoint MVC, è disponibile un metodo di estensione che può essere usato come segue:

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response potrebbe richiedere il buffering

Alcune API su Response richiedono che il flusso di output venga memorizzato nel buffer, ad esempio Output, Clear()End(), e SuppressContent.

Raccomandazione: per supportare il comportamento per Response che richiede il buffering della risposta prima dell'invio, gli endpoint devono acconsentire esplicitamente all'invio con i metadati dell'endpoint che implementano IBufferResponseStreamMetadata.

Per abilitare questa operazione in tutti gli endpoint MVC, è disponibile un metodo di estensione che può essere usato come segue:

app.MapDefaultControllerRoute()
    .BufferResponseStream();

Stato sessione condivisa

Per supportare Session, gli endpoint devono acconsentire esplicitamente tramite i metadati che implementano ISessionMetadata.

Raccomandazione: per abilitare questa funzionalità in tutti gli endpoint MVC, è disponibile un metodo di estensione che può essere usato come segue:

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Ciò richiede anche un'implementazione di un archivio sessioni. Per informazioni dettagliate sulle opzioni, vedere qui.

La sessione remota espone un endpoint aggiuntivo per l'applicazione

Il supporto sessione remota espone un endpoint che consente all'app principale di recuperare le informazioni sulla sessione. Ciò può causare la presenza di una richiesta di lunga durata tra l'app principale e l'app framework, ma si verifica un timeout con la richiesta corrente o il timeout della sessione (per impostazione predefinita è 20 minuti).

Raccomandazione: assicurarsi che la chiave API usata sia una complessa e che la connessione con l'app framework venga eseguita tramite SSL.

Le directory virtuali devono essere identiche per le applicazioni di base e framework

La configurazione della directory virtuale viene usata per la generazione di route, l'autorizzazione e altri servizi all'interno del sistema. A questo punto, non è stato trovato alcun metodo affidabile per abilitare directory virtuali diverse a causa del funzionamento di ASP.NET Framework.

Raccomandazione: assicurarsi che le due applicazioni si trovino in siti diversi (host e/o porte) con lo stesso layout di directory virtuale/applicazione.