Verwendungsleitfaden

Microsoft.AspNetCore.SystemWebAdapters stellt eine Emulationsebene bereit, um das Verhalten des ASP.NET Frameworks auf ASP.NET Core nachzuahmen. Im Folgenden finden Sie Richtlinien für einige der Überlegungen bei der Verwendung:

Lebensdauer von HttpContext

Die Adapter werden von HttpContext unterstützt, die Verwendung ist aber nicht über die Lebensdauer einer Anforderung hinaus möglich. Daher kann HttpContext bei der Ausführung auf ASP.NET Core auch nicht über eine Anforderung hinaus verwendet werden, während dies beim ASP.NET Framework manchmal funktioniert. Ein ObjectDisposedException wird bei der Verwendung über das Ende einer Anforderung hinaus ausgelöst.

Empfehlung: Speichern Sie die erforderlichen Werte in einem POCO, und behalten Sie es bei.

Konvertierung zu HttpContext

Es gibt zwei Möglichkeiten, um HttpContext in HttpContextzu konvertieren:

• Implizite Umwandlung
• Verwendung eines Konstruktors

Empfehlung: In den meisten Fällen ist die implizite Umwandlung zu bevorzugen, da so die erstellte Instanz zwischengespeichert und sichergestellt wird, dass nur pro Anforderung nur ein HttpContext erzeugt wird.

CurrentCulture ist nicht standardmäßig festgelegt

In ASP.NET Framework wurde CurrentCulture für eine Anforderung festgelegt, in ASP.NET Core erfolgt dies aber nicht automatisch. Stattdessen müssen Sie die entsprechende Middleware zur Pipeline hinzufügen.

Empfehlung: Weitere Informationen zur Aktivierung finden Sie unter ASP.NET Core-Lokalisierung.

Die einfachste Möglichkeit, dies mit einem ähnlichem Verhalten wie im ASP.NET Framework zu aktivieren, bestünde darin, Folgendes zu Ihrer Pipeline hinzuzufügen:

app.UseRequestLocalization();

CurrentPrincipal

In ASP.NET Framework würden CurrentPrincipal und Current auf den aktuellen Benutzer festgelegt. Dies ist für ASP.NET Core nicht ohne Weiteres verfügbar. Unterstützung hierfür ist mit diesen Adaptern verfügbar, indem sie ISetThreadCurrentPrincipal zum Endpunkt hinzufügen (über SetThreadCurrentPrincipalAttribute für Controller verfügbar). Sie sollten diese Möglichkeit jedoch nur nutzen, wenn der Code nicht umgestaltet werden kann, um die Verwendung zu entfernen.

Empfehlung: Verwenden Sie nach Möglichkeit stattdessen die Eigenschaften „User“ oder „User“, in dem Sie sie an die Aufrufsite übergeben. Wenn dies nicht möglich ist, aktivieren Sie das Festlegen des aktuellen Benutzers, und erwägen Sie auch, die Anforderung als logischen einzelnen Thread festzulegen. (Details dazu finden Sie weiter unten.)

In ASP.NET Core ist kein Anforderungsthread vorhanden

Wenn im ASP.NET Framework eine Anforderung Threadaffinität und Current hätte, wäre sie nur verfügbar, wenn sie auf diesem Thread ist. ASP.NET Core bietet diese Garantie nicht, also wird Current innerhalb desselben asynchronen Kontexts verfügbar sein. Für Threads gibt es hingegen keine Garantie.

Empfehlung: Wenn Sie auf HttpContext lesen/schreiben, müssen Sie sicherstellen, dass Sie im Rahmen eines Singlethreads tun. Sie können erzwingen, dass eine Anforderung nie gleichzeitig in einem asynchronen Kontext ausgeführt wird, indem Sie ISingleThreadedRequestMetadata festlegen. Dies wirkt sich allerdings auf die Leistung aus und sollte nur angewendet werden, wenn Sie die Verwendung nicht umgestalten können, um einen nicht gleichzeitigen Zugriff sicherzustellen. Mit SingleThreadedRequestAttribute ist eine Implementierung zum Hinzufügen zu Controllern verfügbar:

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

Request muss ggf. vorab gepuffert werden

Standardmäßig ist die eingehende Anforderung nicht immer suchbar oder vollständig verfügbar. Um das Verhalten in .NET Framework zu erhalten, können Sie sich entscheiden, den Eingabestream vorab zu puffern. Dadurch wird der eingehende Stream vollständig gelesen und (abhängig von den Einstellungen) im Arbeitsspeicher oder auf dem Datenträger gepuffert.

Empfehlung: Dies kann durch Anwenden von Endpunktmetadaten aktiviert werden, die die IPreBufferRequestStreamMetadata-Schnittstelle implementieren. Diese Lösung ist als PreBufferRequestStreamAttribute-Attribut verfügbar, das auf Controller oder Methoden angewendet werden kann.

Um dies auf allen MVC-Endpunkten zu aktivieren, gibt es eine Erweiterungsmethode, die folgendermaßen verwendet werden kann:

app.MapDefaultControllerRoute()
    .PreBufferRequestStream();

Response erfordert möglicherweise Pufferung

Einige APIs auf Response erfordern, dass der Ausgabestream gepuffert wird, z. B. Output, End(), Clear()und SuppressContent.

Empfehlung: Um das Verhalten für Response zu unterstützen, das das Puffern der Antwort vor dem Senden erfordert, müssen Endpunkte dies durch Implementieren von IBufferResponseStreamMetadata mithilfe von Endpunktmetadaten aktivieren.

Um dies auf allen MVC-Endpunkten zu aktivieren, gibt es eine Erweiterungsmethode, die folgendermaßen verwendet werden kann:

app.MapDefaultControllerRoute()
    .BufferResponseStream();

Freigegebener Sitzungszustand

Zur Unterstützung von Session müssen Endpunkte dies durch das Implementieren von ISessionMetadata mithilfe von Metadaten aktivieren.

Empfehlung: Um dies auf allen MVC-Endpunkten zu aktivieren, gibt es eine Erweiterungsmethode, die folgendermaßen verwendet werden kann:

app.MapDefaultControllerRoute()
    .RequireSystemWebAdapterSession();

Dies erfordert auch eine gewisse Implementierung eines Sitzungsspeichers. Ausführliche Informationen zu den Optionen finden Sie hier.

Die Remotesitzung macht einen zusätzlichen Endpunkt für die Anwendung verfügbar

Die Unterstützung für Remotesitzungen macht einen Endpunkt verfügbar, mit dessen Hilfe die Core-App Sitzungsinformationen abrufen kann. Dies kann dazu führen, dass eine potenziell langlebige Anforderung zwischen der Core-App und der Framework-App vorhanden ist, jedoch ein Timeout bei der aktuellen Anforderung oder beim Sitzungstimeout (standardmäßig 20 Minuten) auftritt.

Empfehlung: Stellen Sie sicher, dass der verwendete API-Schlüssel stark ist und dass die Verbindung mit der Framework-App über SSL hergestellt wird.

Virtuelle Verzeichnisse müssen für Framework- und Core-Anwendungen identisch sein

Die Einrichtung des virtuellen Verzeichnisses wird für die Routengenerierung, Autorisierung und andere Dienste im System verwendet. Bis jetzt wurde aufgrund der Funktionsweise des ASP.NET Frameworks noch keine zuverlässige Methode gefunden, um verschiedene virtuelle Verzeichnisse zu aktivieren.

Empfehlung: Stellen Sie sicher, dass sich Ihre beiden Anwendungen an verschiedenen Standorten (Hosts und/oder Ports) mit demselben Layout für Anwendungen und virtuelle Verzeichnisse befinden.