Out-of-Process-Hosting mit IIS und ASP.NET Core

Da ASP.NET Core-Apps in einem Prozess getrennt vom IIS-Arbeitsprozess ausgeführt werden, führt das ASP.NET Core-Modul die Prozessverwaltung durch. Das Modul startet den Prozess für die ASP.NET Core-App, wenn die erste Anforderung eingeht und startet die App neu, wenn sie heruntergefahren wird oder abstürzt. Dies ist im Prinzip das gleiche Verhalten wie bei Apps, die prozessintern ausgeführt und durch den Windows-Prozessaktivierungsdienst (WAS) verwaltet werden.

Das folgende Diagramm zeigt die Beziehung zwischen IIS, dem ASP.NET Core-Modul und einer Out-of-Process gehosteten App:

1. Anforderungen gehen aus dem Internet an den Treiber „HTTP.sys“ ein, der im Kernelmodus betrieben wird.
2. Der Treiber leitet die Anforderungen an IIS auf dem konfigurierten Port der Webseite weiter. Der konfigurierte Port ist normalerweise 80 (HTTP) oder 443 (HTTPS).
3. Das Modul leitet die Anforderung über einen zufälligen Port für die App an Kestrel weiter. Der zufällige Port entspricht nicht Port 80 oder 443.

Das ASP.NET Core-Modul gibt den Port beim Start über eine Umgebungsvariable an. Mit der UseIISIntegration-Erweiterung wird der Server so konfiguriert, dass er an http://localhost:{PORT} lauscht. Zusätzliche Überprüfungen werden durchgeführt. Anforderungen, die nicht vom Modul stammen, werden abgelehnt. Das Modul unterstützt die HTTPS-Weiterleitung nicht. Deshalb werden Anforderungen über HTTP weitergeleitet, selbst wenn sie von IIS über HTTPS empfangen wurden.

Nachdem Kestrel die Anforderung vom Modul empfangen hat, wird die Anforderung an die Middlewarepipeline von ASP.NET Core weitergeleitet. Die Middleware-Pipeline behandelt die Anforderung und gibt sie als HttpContext-Instanz an die App-Logik weiter. Die durch die IIS-Integration hinzugefügte Middleware aktualisiert das Schema, die Remote-IP und die Pfadbasis, um die Anforderung an Kestrel weiterzuleiten. Die Antwort der App wird dann an IIS zurückgegeben und an den HTTP-Client weitergeleitet, der die Anforderung initiiert hat.

Einen Konfigurationsleitfaden für das ASP.NET Core-Modul finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

Weitere Informationen zum Hosten finden Sie unter Hosten in ASP.NET Core.

Anwendungskonfiguration

Aktivieren der IISIntegration-Komponenten

Rufen Sie beim Erstellen eines Hosts in CreateHostBuilder (Program.cs) CreateDefaultBuilder ab, um die IIS-Integration zu aktivieren:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

Weitere Informationen zu CreateDefaultBuilder finden Sie unter CreateDefaultBuilder.

Out-of-Process-Hostingmodell

Schließen Sie zur Konfiguration von IIS-Optionen eine Dienstkonfiguration für IISOptions in ConfigureServices ein. Im folgenden Beispiel wird Verhindert, dass die App HttpContext.Connection.ClientCertificate auffüllt:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Option	Standard	Einstellung
AutomaticAuthentication	true	Bei Festlegung auf true legt die Middleware für die IIS-Integration den per Windows-Authentifizierung authentifizierten HttpContext.User fest. Bei Festlegung auf false stellt die Middleware nur eine Identität für HttpContext.User bereit und antwortet auf explizite Anforderungen durch AuthenticationScheme. Die Windows-Authentifizierung muss in IIS aktiviert sein, damit AutomaticAuthentication funktioniert. Weitere Informationen finden Sie im Thema Windows-Authentifizierung.
AuthenticationDisplayName	null	Legt den Anzeigename fest, der Benutzern auf Anmeldungsseiten angezeigt wird
ForwardClientCertificate	true	Wenn diese Option true ist und der Anforderungsheader MS-ASPNETCORE-CLIENTCERT vorhanden ist, wird das HttpContext.Connection.ClientCertificate aufgefüllt.

Proxyserver und Lastenausgleichsszenarien

Die Middleware für die IIS-Integration und das ASP.NET Core-Modul sind zur Weiterleitung des

• Schemas (HTTP/HTTPS)
• und der Remote-IP-Adresse konfiguriert, von der die Anforderung stammt.

Die Middleware für die IIS-Integration konfiguriert die Middleware für weitergeleitete Header.

Möglicherweise ist zusätzliche Konfiguration für Apps erforderlich, die hinter weiteren Proxyservern und Lastenausgleichsmodulen (Load Balancer) gehostet werden. Weitere Informationen hierzu feinden Sie unter Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich.

Out-of-Process-Hostingmodell

Um eine App für Out-of-Process-Hosting zu konfigurieren, legen Sie den Wert der <AspNetCoreHostingModel>-Eigenschaft in der Projektdatei ( .csproj) auf OutOfProcess fest:

<PropertyGroup>
  <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

Das In-Process-Hosting wird mithilfe von InProcess (Standardwert) festgelegt.

Beim Wert von <AspNetCoreHostingModel> wird die Groß-/Kleinschreibung nicht beachtet, sodass inprocess und outofprocess gültige Werte sind.

Der Kestrel-Server wird anstelle des IIS-HTTP-Servers (IISHttpServer) verwendet.

Bei Out-of-Process ruft CreateDefaultBuilderUseIISIntegration auf, um Folgendes zu tun:

• Konfigurieren des Ports und des Basispfads, den der Server überwachen soll, wenn er hinter dem ASP.NET Core-Modul ausgeführt wird.
• Konfigurieren des Hosts zum Erfassen von Startfehlern.

Prozessname

Process.GetCurrentProcess().ProcessName meldet w3wp/iisexpress (In-Process) oder dotnet (Out-of-Process).

Viele native Module, z.B. die Windows-Authentifizierung, bleiben aktiv. Weitere Informationen zu IIS-Modulen, die im ASP.NET Core-Modul aktiv sind, finden Sie unter IIS-Module mit ASP.NET Core.

Das ASP.NET Core-Modul kann außerdem:

• Umgebungsvariablen für den Arbeitsprozess festlegen
• Die stdout-Ausgabe im Dateispeicher protokollieren, um Probleme beim Start zu beheben
• Windows-Authentifizierungstoken weiterleiten