Hosten von ASP.NET Core unter Windows mit IIS

IIS (Internetinformationsdienste) stellen einen flexiblen, sicheren und verwaltbaren Webserver für das Hosten von Web-Apps (einschließlich ASP.NET Core) dar.

Unterstützte Plattformen

Die folgenden Betriebssysteme werden unterstützt:

• Windows 7 oder höher
• Windows Server 2012 R2 oder höher

Apps, die für Bereitstellungen für 32-Bit-Systeme (x86) oder 64-Bit-Systeme (x64) veröffentlicht wurden, werden unterstützt. Stellen Sie eine 32-Bit-App mit einem .NET Core SDK für 32-Bit (x86) bereit, es sei denn:

• Die App benötigt den größeren Adressraum des virtuellen Arbeitsspeichers, der 64-Bit-Apps zur Verfügung steht.
• Die App erfordert den größeren IIS-Stapel.
• Die App weist native 64-Bit-Abhängigkeiten auf.

Installieren des ASP.NET Core-Moduls/Hostingpakets

Laden Sie den neuesten Installer über folgenden Link herunter:

Aktueller Installer für das .NET Core Hosting-Paket (direkter Download)

Ausführlichere Anweisungen zum Installieren des ASP.NET Core-Moduls oder einer anderen Version finden Sie unter Installieren des .NET Core-Hostingpakets.

Informationen zum Herunterladen früherer Versionen des Hostingpakets finden Sie unter diesem GitHub-Problem.

Erste Schritte

Eine Einführung in das Hosten einer Website auf IIS finden Sie in unserem Leitfaden zu den ersten Schritten.

Eine Einführung in das Hosten einer Website in Azure App Service finden Sie im Bereitstellungsleitfaden für Azure App Service.

Konfiguration

Anleitungen zur Konfiguration finden Sie unter Erweiterte Konfiguration.

Bereitstellungsressourcen für IIS-Administratoren

• IIS-Dokumentation
• Erste Schritte mit IIS-Manager in IIS
• .NET Core-Anwendungsbereitstellung
• ASP.NET Core-Modul (ANCM) für IIS
• Verzeichnisstruktur für ASP.NET Core
• IIS-Module mit ASP.NET Core
• Problembehandlung bei ASP.NET Core in Azure App Service und IIS
• Problembehandlung für häufige Fehler bei Azure App Service und IIS mit ASP.NET Core

Überlappende Wiederverwendung

Im Allgemeinen wird empfohlen, ein Muster wie die blau-grünen-Bereitstellungen (BlueGreenDeployment) für Bereitstellungen ohne Ausfallzeiten zu verwenden. Features wie die überlappende Wiederverwendung (Overlapped Recycle) können zwar helfen, garantieren aber keine Bereitstellung ohne Ausfallzeiten. Weitere Informationen finden Sie in diesem GitHub-Issue.

Optionale Clientzertifikate

Informationen zu Apps, die eine Teilmenge der App mit einem Zertifikat schützen müssen, finden Sie unter Optionale Clientzertifikate.

Zusätzliche Ressourcen

• Problembehandlung und Debuggen von ASP.NET Core-Projekten
• Übersicht über ASP.NET Core
• Die offizielle Microsoft IIS-Website
• Bibliothek mit technischem Inhalt zu Windows Server
• HTTP/2 unter IIS
• Transformieren von web.config

Ein Tutorial zum Veröffentlichen einer ASP.NET Core-App auf einem IIS-Server finden Sie unter Veröffentlichen einer ASP.NET Core-App in IIS.

Installieren des .NET Core Hosting-Pakets

Unterstützte Betriebssysteme

Die folgenden Betriebssysteme werden unterstützt:

• Windows 7 oder höher
• Windows Server 2012 R2 oder höher

Der HTTP.sys-Server (zuvor WebListener genannt) funktioniert nicht in einer Reverseproxykonfiguration mit IIS. Verwenden Sie den Kestrel-Server.

Informationen zum Hosting in Azure finden Sie unter Bereitstellen von ASP.NET Core-Apps in Azure App Service.

Anleitungen zur Problembehandlung finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Unterstützte Plattformen

Apps, die für Bereitstellungen für 32-Bit-Systeme (x86) oder 64-Bit-Systeme (x64) veröffentlicht wurden, werden unterstützt. Stellen Sie eine 32-Bit-App mit einem .NET Core SDK für 32-Bit (x86) bereit, es sei denn:

• Die App benötigt den größeren Adressraum des virtuellen Arbeitsspeichers, der 64-Bit-Apps zur Verfügung steht.
• Die App erfordert den größeren IIS-Stapel.
• Die App weist native 64-Bit-Abhängigkeiten auf.

Für Apps, die für 32 Bit (x86) veröffentlicht wurden, müssen 32 Bit für ihre IIS-Anwendungspools aktiviert sein. Weitere Informationen finden Sie im Abschnitt Erstellen der IIS-Website.

Verwenden Sie ein .NET Core SDK für 64-Bit (x64), um eine 64-Bit-App zu veröffentlichen. Auf dem Hostsystem muss eine 64-Bit-Runtime vorhanden sein.

Hostingmodelle

In-Process-Hostingmodell

Beim Einsatz von In-Process-Hosting wird eine ASP.NET Core-App im gleichen Prozess wie ihr IIS-Arbeitsprozess ausgeführt. Durch das In-Process-Hosting wird die Leistung des Out-of-Process-Hosting verbessert, da Anforderungen nicht per Proxy über den Loopbackadapter weitergeleitet werden. Dabei handelt es sich um eine Netzwerkschnittstelle, die ausgehenden Netzwerkdatenverkehr zum selben Computer zurück leitet. IIS erledigt das Prozessmanagement mit dem Windows-Prozessaktivierungsdienst (Process Activation Service, WAS).

Das ASP.NET Core-Modul:

• Führt die Initialisierung von Apps aus.
  • Lädt die CoreCLR.
  • Ruft Program.Main.
• Behandelt die Lebensdauer der nativen IIS-Anforderung.

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

1. Eine Anforderung geht aus dem Web beim HTTP.sys-Treiber im Kernelmodus ein.
2. Der Treiber leitet die native Anforderung an IIS auf dem konfigurierten Port der Webseite weiter, normalerweise 80 (HTTP) oder 443 (HTTPS).
3. Das ASP.NET Core-Modul empfängt die native Anforderung und übergibt sie an den IIS-HTTP-Server (IISHttpServer). Der IIS-HTTP-Server ist eine prozessinterne Serverimplementierung für IIS, die die Anforderung vom nativen Modus in den verwalteten Modus konvertiert.

Nach der Verarbeitung der Anforderung durch den IIS-HTTP-Server:

1. Die Anforderung wird an die ASP.NET Core-Middlewarepipeline gesendet.
2. Die Middleware-Pipeline behandelt die Anforderung und gibt sie als HttpContext-Instanz an die App-Logik weiter.
3. Die Antwort der App wird über den IIS-HTTP-Server zurück an IIS übergeben.
4. IIS übermittelt die Antwort an den Client, der die Anforderung initiiert hat.

Das In-Process-Hosting ist eine wählbare Option für vorhandene Apps. Die ASP.NET Core-Webvorlagen verwenden das In-Process-Hostingmodell.

CreateDefaultBuilder fügt eine IServer-Instanz hinzu, indem die UseIIS-Methode aufgerufen wird, um die CoreCLR zu starten und die App im IIS-Workerprozess zu hosten (w3wp.exe oder iisexpress.exe). Leistungstests weisen darauf hin, dass das In-Process-Hosting einer .NET Core-App einen weitaus höheren Anforderungsdurchsatz bietet als das Out-of-Process-Hosting der App mit Weiterleitung der Anforderungen über einen Proxy an Kestrel.

Apps, die als einzelne ausführbare Datei veröffentlicht wurden, können vom In-Prozess-Hostingmodell nicht geladen werden.

Out-of-Process-Hostingmodell

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 Generischer .NET-Host in ASP.NET Core.

IIS-Optionen

In-Process-Hostingmodell

Schließen Sie zur Konfiguration von IIS-Serveroptionen eine Dienstkonfiguration für IISServerOptions in ConfigureServices ein. Mit dem folgenden Beispiel wird AutomaticAuthentication deaktiviert:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});

Option	Standard	Einstellung
AutomaticAuthentication	true	Bei Festlegung auf true legt der Server den per Windows-Authentifizierung authentifizierten HttpContext.User fest. Bei Festlegung auf false stellt der Server nur eine Identität für HttpContext.User bereit und antwortet auf explizite Anforderungen durch das AuthenticationScheme. Die Windows-Authentifizierung muss in IIS aktiviert sein, damit AutomaticAuthentication funktioniert. Weitere Informationen finden Sie unter Windows-Authentifizierung.
AuthenticationDisplayName	null	Legt den Anzeigename fest, der Benutzern auf Anmeldungsseiten angezeigt wird
AllowSynchronousIO	false	Steuert, ob synchrone E/A-Vorgänge für HttpContext.Request und HttpContext.Response zulässig sind.
MaxRequestBodySize	30000000	Dient zum Abrufen oder Festlegen der maximalen Größe des Anforderungstexts für HttpRequest. Beachten Sie, dass IIS selbst das Limit maxAllowedContentLength aufweist, das vor der in den IISServerOptions festgelegten MaxRequestBodySize verarbeitet wird. Das Ändern von MaxRequestBodySize hat keine Auswirkungen auf maxAllowedContentLength. Zum Erhöhen von maxAllowedContentLength fügen Sie einen Eintrag in web.config hinzu, um maxAllowedContentLength auf einen höheren Wert festzulegen. Weitere Informationen hierzu finden Sie unter Konfiguration.

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

web.config-Datei

Mit der Datei web.config wird das ASP.NET Core-Modul konfiguriert. Die Erstellung, Transformation und Veröffentlichung der Datei web.config wird bei der Projektveröffentlichung von einem MSBuild-Ziel (_TransformWebConfig) abgewickelt. Dieses Ziel ist in den Web SDK-Zielen (Microsoft.NET.Sdk.Web) vorhanden. Das SDK wird am Anfang der Projektdatei festgelegt:

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

Wenn im Projekt keine Datei namens web.config vorhanden ist, wird sie zur Konfiguration des ASP.NET Core-Moduls mit dem richtigen processPath- und arguments-Attribut erstellt und in die veröffentlichte Ausgabe verschoben.

Ist eine Datei namens web.config im Projekt vorhanden, wird sie zur Konfiguration des ASP.NET Core-Moduls mit dem richtigen processPath- und arguments-Attribut transformiert und in die veröffentlichte Ausgabe verschoben. Die Transformation ändert die IIS-Konfigurationseinstellungen in der Datei nicht.

Die Datei web.config kann zusätzliche IIS-Konfigurationseinstellungen zum Steuern der aktiven IIS-Module bereitstellen. Informationen zu IIS-Modulen, die Anforderungen mit ASP.NET Core-Apps verarbeiten können, finden Sie im Thema IIS-Module.

Verwenden Sie die Eigenschaft <IsTransformWebConfigDisabled> in der Projektdatei, um zu verhindern, dass das Web-SDK die Datei web.config transformiert:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Wenn die Transformation der Datei durch das Web-SDK deaktiviert wird, müssen die Attribute processPath und arguments manuell durch den Entwickler festgelegt werden. Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Speicherort der Datei web.config

Zum Erstellen des ASP.NET Core-Moduls muss die Datei web.config im Inhaltsstammpfad (normalerweise dem App-Basispfad) der bereitgestellten App vorhanden sein. Dies ist der physische Pfad der Website, der in IIS bereitgestellt wurde. Die Datei web.config wird im Stammverzeichnis der App benötigt, um die Veröffentlichung mehrerer Apps mit Web Deploy zu ermöglichen.

Vertrauliche Dateien wie {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (Kommentare zur XML-Dokumentation) und {ASSEMBLY}.deps.json sind im physischen Pfad der App vorhanden. Der Platzhalter {ASSEMBLY} steht hierbei für den Assemblynamen. Wenn die web.config-Datei vorhanden ist und die Website normal startet, werden diese vertraulichen Dateien bei Anforderung nicht offengelegt. Wenn die Datei web.config fehlt, falsch benannt wurde oder die Website nicht für den normalen Start konfigurieren kann, macht IIS vertrauliche Dateien möglicherweise öffentlich verfügbar.

Die Datei web.config muss immer in der Bereitstellung vorhanden, richtig benannt und in der Lage sein, die Website für einen normalen Start zu konfigurieren. Entfernen Sie die Datei web.config niemals aus einer Produktionsbereitstellung.

Transformieren von web.config

Wenn Sie web.config beim Veröffentlichen transformieren müssen, finden Sie unter Transformieren von web.config weitere Informationen. Möglicherweise müssen Sie web.config beim Veröffentlichen transformieren, um Umgebungsvariablen basierend auf der Konfiguration, dem Profil oder der Umgebung festzulegen.

IIS-Konfiguration

Windows Server-Betriebssysteme

Aktivieren Sie die Serverrolle Webserver (IIS) , und richten Sie Rollendienste ein.

1. Verwenden Sie den Assistenten Rollen und Features hinzufügen im Menü Verwalten oder den Link in Server-Manager. Aktivieren Sie im Schritt Serverrollen das Kontrollkästchen für Webserver (IIS) .

   

2. Nach dem Schritt Features wird der Schritt Rollendienste für Webserver (IIS) geladen. Wählen Sie die gewünschten IIS-Rollendienste aus, oder übernehmen Sie die bereitgestellten Standardrollendienste.

   

   Windows-Authentifizierung (optional)
   Um die Windows-Authentifizierung zu aktivieren, erweitern Sie die folgenden Knoten: Webserver>Sicherheit. Wählen Sie das Feature Windows-Authentifizierung aus. Weitere Informationen finden Sie unter Windows-Authentifizierung <windowsAuthentication> und Konfigurieren der Windows-Authentifizierung.

   WebSockets (optional)
   WebSockets wird mit ASP.NET Core 1.1 oder höher unterstützt. Um WebSockets zu aktivieren, erweitern Sie die folgenden Knoten: Webserver>Anwendungsentwicklung. Wählen Sie das Feature WebSocket-Protokoll aus. Weitere Informationen finden Sie unter WebSockets.

3. Fahren Sie mit dem Schritt Bestätigung fort, um die Webserverrolle und die Dienste zu installieren. Ein Server-/IIS-Neustart ist nach der Installation der Rolle Webserver (IIS) nicht erforderlich.

Windows-Desktopbetriebssysteme

Aktivieren Sie die IIS-Verwaltungskonsole und die WWW-Dienste.

1. Navigieren Sie zu Systemsteuerung>Programme>Programme und Features>Windows-Features aktivieren oder deaktivieren (links auf dem Bildschirm).

2. Öffnen Sie den Knoten Internetinformationsdienste. Öffnen Sie den Knoten Webverwaltungstools.

3. Aktivieren Sie das Kontrollkästchen für IIS-Verwaltungskonsole.

4. Aktivieren Sie das Kontrollkästchen für WWW-Dienste.

5. Akzeptieren Sie die Standardfeatures für WWW-Dienste, oder passen Sie die IIS-Features an.

   Windows-Authentifizierung (optional)
   Um die Windows-Authentifizierung zu aktivieren, erweitern Sie die folgenden Knoten: WWW-Dienste>Sicherheit. Wählen Sie das Feature Windows-Authentifizierung aus. Weitere Informationen finden Sie unter Windows-Authentifizierung <windowsAuthentication> und Konfigurieren der Windows-Authentifizierung.

   WebSockets (optional)
   WebSockets wird mit ASP.NET Core 1.1 oder höher unterstützt. Um WebSockets zu aktivieren, erweitern Sie die folgenden Knoten: WWW-Dienste>Anwendungsentwicklungsfeatures. Wählen Sie das Feature WebSocket-Protokoll aus. Weitere Informationen finden Sie unter WebSockets.

6. Wenn die IIS-Installation einen Neustart erfordert, starten Sie das System neu.

Installieren des .NET Core Hosting-Pakets

Installieren Sie das Paket „.NET Core Hosting“ im Hostsystem. Das Paket installiert die .NET Core-Runtime, die .NET Core-Bibliothek und das ASP.NET Core-Modul. Mit dem Modul können ASP.NET Core-Apps hinter IIS ausgeführt werden.

Direkter Download (aktuelle Version)

Laden Sie den Installer über folgenden Link herunter:

Aktueller Installer für das .NET Core Hosting-Paket (direkter Download)

Frühere Versionen des Installers

So erhalten Sie eine frühere Version des Installers:

1. Navigieren Sie zur .NET Core-Downloadseite.
2. Wählen Sie die gewünschte .NET Core-Version aus.
3. Suchen Sie in der Spalte Run apps - Runtime (Apps ausführen – Runtime) die Zeile mit der gewünschten .NET Core-RuntimeRuntime-Version.
4. Laden Sie den Installer über den Link das Hosting Bundle (Hosting-Paket) herunter.

Installieren des Hosting-Pakets

1. Führen Sie das Installationsprogramm auf dem Server aus. Die folgenden Parameter sind verfügbar, wenn Sie das Installationsprogramm über eine Administratorbefehlsshell ausführen.

   • OPT_NO_ANCM=1: Überspringen Sie die Installation des ASP.NET Core-Moduls.
   • OPT_NO_RUNTIME=1: Überspringen Sie die Installation der .NET Core-Runtime. Wird verwendet, wenn der Server nur eigenständige Bereitstellungen (Self-contained Deployments, SCD) hostet.
   • OPT_NO_SHAREDFX=1: Überspringen Sie die Installation des freigegebenen ASP.NET-Frameworks (ASP.NET-Runtime). Wird verwendet, wenn der Server nur eigenständige Bereitstellungen (Self-contained Deployments, SCD) hostet.
   • OPT_NO_X86=1: Überspringen Sie die Installation von x86-Runtimes. Verwenden Sie diesen Parameter, wenn Sie wissen, dass Sie keine 32-Bit-Apps hosten. Sollte die Möglichkeit bestehen, dass Sie sowohl 32-Bit- als auch 64-Bit-Apps hosten könnten, verwenden Sie diesen Parameter nicht, und installieren Sie beide Runtimes.
   • OPT_NO_SHARED_CONFIG_CHECK=1: Deaktivieren Sie die Überprüfung auf Verwendung einer gemeinsamen IIS-Konfiguration, wenn sich die gemeinsam genutzte Konfiguration (applicationHost.config) auf demselben Computer wie die IIS-Installation befindet. Nur für Installationsprogramme für Hostingbundles für ASP.NET Core 2.2 oder höher verfügbar. Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

2. Durch den Neustart von IIS wird eine Änderung an der PATH-Systemeinstellung – einer Umgebungsvariable – angewendet, die durch den Installer vorgenommen wurde. Beenden Sie den Windows-Prozessaktivierungsdienst (Windows Process Activation Service, WAS), und starten Sie den WWW-Publishingdienst (W3SVC) neu, um den Webserver neu zu starten. Starten Sie das System neu, oder führen Sie die folgenden Befehle in einer Befehlsshell mit erhöhten Rechten aus:

   net stop was /y
   net start w3svc
   

ASP.NET Core wendet kein Rollforwardverhalten für Patchversionen freigegebener Frameworkpakete an. Nach einem Upgrade des freigegebene Frameworks durch Installation eines neuen Hostingpakets starten Sie das System neu, oder führen Sie die folgenden Befehle in einer Befehlsshell mit erhöhten Rechten aus:

net stop was /y
net start w3svc

Installieren von Web Deploy beim Veröffentlichen mit Visual Studio

Wenn Sie Apps auf Servern mit Web Deploy bereitstellen, installieren Sie die neueste Version von Web Deploy auf dem Server. Verwenden Sie den Webplattform-Installer (WebPI), um Web Deploy zu installieren. Weitere Informationen finden Sie unter IIS-Downloads: Web Deploy. Die bevorzugte Methode ist die Verwendung von WebPI. WebPI bietet ein eigenständiges Setup und eine Konfiguration für Hostinganbieter.

Erstellen der IIS-Website

1. Erstellen Sie auf dem Hostingsystem einen Ordner zum Speichern der veröffentlichten Ordner und Dateien der App. In einem späteren Schritt wird der Ordnerpfad als physischer App-Pfad in IIS angegeben. Weitere Informationen zum Bereitstellungsordner und zum Dateilayout einer App finden Sie unter ASP.NET Core-Verzeichnisstruktur.

2. Öffnen Sie in IIS-Manager den Serverknoten im Bereich Verbindungen. Klicken Sie mit der rechten Maustaste auf den Ordner Websites. Klicken Sie im Kontextmenü auf Website hinzufügen.

3. Geben Sie einen Websitenamen an, und legen Sie den physischen Pfad auf den Bereitstellungsordner der App fest. Geben Sie die Konfiguration unter Bindung an, und erstellen Sie die Website, indem Sie auf OK klicken:

   

   Warnung

   Allgemeine Platzhalterbindungen (http://*:80/ und http://+:80) dürfen nicht verwendet werden. Platzhalterbindungen auf oberster Ebene gefährden die Sicherheit Ihrer App. Dies gilt für starke und schwache Platzhalter. Verwenden Sie statt Platzhaltern explizite Hostnamen. Platzhalterbindungen in untergeordneten Domänen (z.B. *.mysub.com) verursachen kein Sicherheitsrisiko, wenn Sie die gesamte übergeordnete Domäne steuern (im Gegensatz zu *.com, das angreifbar ist). Weitere Informationen finden Sie unter RFC 9110: HTTP-Semantik (Abschnitt 7.2. Host und :authority).

4. Wählen Sie unter dem Serverknoten Anwendungspools aus.

5. Klicken Sie mit der rechten Maustaste auf den App-Pool der Website, und wählen Sie im Kontextmenü Grundeinstellungen aus.

6. Legen Sie im Fenster Anwendungspool bearbeiten die .NET CLR-Version auf Kein verwalteter Code fest:

   

   ASP.NET Core wird in einem separaten Prozess ausgeführt und verwaltet die Runtime. Für ASP.NET Core ist das Laden der Desktop-CLR (.NET CLR) nicht erforderlich. Die Core Common Language Runtime (CoreCLR) für .NET Core wird gestartet, um die App im Workerprozess zu hosten. Das Festlegen der .NET CLR-Version auf Kein verwalteter Code ist optional, wird aber empfohlen.

7. ASP.NET Core 2.2 oder höher:

   • Deaktivieren Sie für eine eigenständige Bereitstellung für 32-Bit-Systeme (x86), die mit einem 32-Bit-SDK veröffentlicht wurde und die das In-Process-Hostingmodell verwendet, den Anwendungspool für 32 Bit. Navigieren Sie im IIS-Manager zu Anwendungspools auf der Randleiste Verbindungen. Wählen Sie den Anwendungspool der App aus. Wählen Sie auf der Randleiste Aktionen die Option Erweiterte Einstellungen aus. Legen Sie 32-Bit-Anwendungen aktivieren auf True fest.

   • Deaktivieren Sie für eine eigenständige Bereitstellung für 64-Bit-Systeme (x64), die das In-Process-Hostingmodell verwendet, den App-Pool für 32-Bit-Prozesse (x86). Navigieren Sie im IIS-Manager zu Anwendungspools auf der Randleiste Verbindungen. Wählen Sie den Anwendungspool der App aus. Wählen Sie auf der Randleiste Aktionen die Option Erweiterte Einstellungen aus. Legen Sie 32-Bit-Anwendungen aktivieren auf False fest.

8. Vergewissern Sie sich, dass die Prozessmodellidentität über die richtigen Berechtigungen verfügt.

   Wenn die Standardidentität des App-Pools (Prozessmodell>Identity) von ApplicationPoolIdentity in eine andere Identität geändert wird, sollten Sie sicherstellen, dass die neue Identität über die erforderlichen Berechtigungen zum Zugriff auf den Ordner, die Datenbank und andere erforderliche Ressourcen der App verfügt. Der App-Pool benötigt beispielsweise Lese- und Schreibzugriff für Ordner, in denen die App Lese- und Schreibvorgänge für Dateien ausführt.

Konfigurieren der Windows-Authentifizierung (optional)
Weitere Informationen finden Sie unter Konfigurieren der Windows-Authentifizierung.

Bereitstellen der App

Stellen Sie die App im IIS-Ordner Physischer Pfad bereit, der im Abschnitt Erstellen der IIS-Website eingerichtet wurde. Web Deploy ist die empfohlene Methode für die Bereitstellung, aber es gibt verschiedene Optionen, um die Anwendung aus dem Ordner publish des Projekts in den Bereitstellungsordner des Hostsystems zu verschieben.

Web Deploy mit Visual Studio

Informationen zum Erstellen eines Veröffentlichungsprofils zur Verwendung mit Web Deploy finden Sie im Thema Visual Studio publish profiles for ASP.NET Core app deployment (Visual Studio-Veröffentlichungsprofile zum Bereitstellen von ASP.NET Core-Apps). Wenn der Hostinganbieter ein Veröffentlichungsprofil oder Unterstützung für das Erstellen eines solchen Profils bereitstellt, laden Sie dessen Profil herunter, und importieren Sie es mithilfe des Visual Studio-Dialogfelds Veröffentlichen:

Web Deploy außerhalb von Visual Studio

Web Deploy kann über die Befehlszeile auch außerhalb von Visual Studio verwendet werden. Weitere Informationen finden Sie unter Web Deployment Tool (Webbereitstellungstool).

Alternativen zu Web Deploy

Verwenden Sie eine der folgenden Methoden, um die App in das Hostsystem zu verschieben: manuelles Kopieren, Xcopy, Robocopy oder PowerShell.

Weitere Informationen zum Bereitstellen von ASP.NET Core in IIS finden Sie im nachfolgenden Abschnitt Bereitstellungsressourcen für IIS-Administratoren.

Navigieren auf der Website

Senden Sie nach Abschluss der App-Bereitstellung auf dem Hostsystem eine Anforderung an einen der öffentlichen Endpunkte der App.

Im folgenden Beispiel ist die Website an den IIS-Hostnamen von www.mysite.com auf Port 80 gebunden. Es wird eine Anforderung an http://www.mysite.com gesendet:

Gesperrte Bereitstellungsdateien

Die Dateien im Bereitstellungsordner werden gesperrt, wenn die App ausgeführt wird. Gesperrte Dateien können während der Bereitstellung nicht überschrieben werden. Um gesperrte Dateien in einer Bereitstellung freizugeben, beenden Sie den App-Pool mit einer der folgenden Methoden:

• Verwenden Sie Web Deploy, und verweisen Sie auf Microsoft.NET.Sdk.Web in der Projektdatei. Eine Datei namens app_offline.htm befindet sich im Stammverzeichnis des Web-App-Verzeichnisses. Wenn die Datei vorhanden ist, fährt das ASP.NET Core Module die App ordnungsgemäß herunter und verarbeitet die Datei app_offline.htm während der Bereitstellung. Weitere Informationen finden Sie unter Konfigurationsreferenz für das ASP.NET Core-Modul.

• Beenden Sie den App-Pool im IIS-Manager auf dem Server manuell.

• Verwenden Sie PowerShell, um app_offline.htm abzulegen (erfordert PowerShell 5 oder höher):

  $pathToApp = 'PATH_TO_APP'
  
  # Stop the AppPool
  New-Item -Path $pathToApp app_offline.htm
  
  # Provide script commands here to deploy the app
  
  # Restart the AppPool
  Remove-Item -Path $pathToApp app_offline.htm
  

Schutz von Daten

Der ASP.NET Core-Stapel zum Schutz von Daten wird von mehreren ASP.NET-Middlewarekomponenten genutzt, darunter auch von Middleware, die bei der Authentifizierung verwendet wird. Selbst wenn die APIs zum Schutz von Daten nicht aus dem Benutzercode aufgerufen werden, sollte der Schutz von Daten mit einem Bereitstellungsskript oder im Benutzercode konfiguriert werden, um einen persistenten kryptografischen Schlüsselspeicher zu erstellen. Wenn der Schutz von Daten nicht konfiguriert ist, werden die Schlüssel beim Neustarten der App im Arbeitsspeicher gespeichert und verworfen.

Falls der Schlüsselbund im Arbeitsspeicher gespeichert wird, wenn die App neu gestartet wird, gilt Folgendes:

• Alle cookiebasierten Authentifizierungstoken werden für ungültig erklärt.
• Benutzer müssen sich bei ihrer nächsten Anforderung erneut anmelden.
• Alle mit dem Schlüsselbund geschützte Daten können nicht mehr entschlüsselt werden. Dies kann CSRF-Token und ASP.NET Core-MVC-TempData-Cookies einschließen.

Zum Konfigurieren des Schutzes von Daten unter IIS mithilfe des persistenten Schlüsselbunds verwenden Sie einen der folgenden Ansätze:

• Erstellen einer Registrierungsstruktur für den Schutz von Daten

  Schlüssel für den Schutz von Daten, die von ASP.NET Core-Apps verwendet werden, werden in der Registrierung außerhalb der Apps gespeichert. Um die Schlüssel für eine bestimmte App zu dauerhaft zu speichern, müssen Sie Registrierungsschlüssel für den App-Pool erstellen.

  Bei eigenständigen IIS-Installationen, die ohne Webfarm vorgesehen sind, kann das PowerShell-Skript „Provision-AutoGenKeys.ps1“ für den Schutz von Daten für jeden App-Pool genutzt werden, das mit einer ASP.NET Core-App verwendet wird. Dieses Skript erstellt einen Registrierungsschlüssel in der HKLM-Registrierung, der nur für das Workerprozesskonto des App-Pools der App zugänglich ist. Schlüssel werden in ruhendem Zustand mit DPAPI mit einem computerweiten Schlüssel verschlüsselt.

  In Webfarmszenarios kann eine App so konfiguriert werden, dass sie einen UNC-Pfad verwendet, um den Schlüsselbund für den Schutz von Daten zu speichern. Standardmäßig werden die Schlüssel für den Schutz von Daten nicht verschlüsselt. Stellen Sie sicher, dass die Dateiberechtigungen für die Netzwerkfreigabe auf das Windows-Konto beschränkt sind, mit dem die App ausgeführt wird. Ein X.509-Zertifikat kann zum Schutz von Schlüsseln im ruhenden Zustand verwendet werden. Richten Sie ggf. einen Mechanismus ein, um es Benutzern zu ermöglichen, Zertifikate hochzuladen: Platzieren Sie Zertifikate im Zertifikatspeicher des Benutzers für vertrauenswürdige Anbieter, und stellen Sie sicher, dass sie auf allen Computern verfügbar sind, auf denen die App des Benutzers ausgeführt wird. Details finden Sie unter Konfigurieren des Schutzes von Daten in ASP.NET Core.

• Konfigurieren des IIS-Anwendungspools zum Laden des Benutzerprofils

  Diese Einstellung befindet sich im Abschnitt Prozessmodell unter Erweiterte Einstellungen für den App-Pool. Legen Sie Benutzerprofil laden auf True fest. Wenn diese Option auf True festgelegt ist, werden Schlüssel im Benutzerprofilverzeichnis gespeichert und mit DPAPI mit einem für das Benutzerkonto spezifischen Schlüssel geschützt. Schlüssel werden im Ordner %LOCALAPPDATA%/ASP.NET/DataProtection-Keys gespeichert.

  Das setProfileEnvironment-Attribut des App-Pools muss ebenfalls aktiviert sein. Der Standardwert von setProfileEnvironment ist true. In einigen Szenarien (z.B. Windows-Betriebssystem) ist setProfileEnvironment auf false festgelegt. Gehen Sie folgendermaßen vor, wenn Schlüssel nicht wie erwartet im Benutzerprofilverzeichnis gespeichert werden:

  1. Navigieren Sie zum Ordner %windir%/system32/inetsrv/config.
  2. Öffnen Sie die Datei applicationHost.config.
  3. Suchen Sie das Element <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
  4. Bestätigen Sie, dass das setProfileEnvironment-Attribut nicht vorhanden ist, das standardmäßig den Wert true aufweist, oder legen Sie den Wert des Attributs explizit auf true fest.

• Verwenden des Dateisystems als Schlüsselbundspeicher

  Passen Sie den App-Code so an, dass er das Dateisystem als Schlüsselbundspeicher verwendet. Verwenden Sie ein X.509-Zertifikat, um den Schlüsselbund zu schützen, und stellen Sie sicher, dass es sich bei dem Zertifikat um ein vertrauenswürdiges Zertifikat handelt. Wenn es sich um ein selbstsigniertes Zertifikat handelt, müssen Sie es im vertrauenswürdigen Stammspeicher platzieren.

  Wenn IIS in einer Webfarm verwendet wird:

  • Verwenden Sie eine Dateifreigabe, auf die alle Computer zugreifen können.
  • Stellen Sie ein X509-Zertifikat auf jedem Computer bereit. Konfigurieren Sie den Schutz von Daten im Code.

• Festlegen einer computerweiten Richtlinie für den Schutz von Daten

  Das System zum Schutz von Daten verfügt über eine eingeschränkte Unterstützung zum Festlegen einer computerweiten Standardrichtlinie für alle Apps, die die Datenschutz-APIs nutzen. Weitere Informationen finden Sie unter ASP.NET Core-Datenschutz: Übersicht.

Virtuelle Verzeichnisse

Virtuelle IIS-Verzeichnisse werden mit ASP.NET Core-Apps nicht unterstützt. Eine App kann als untergeordnete Anwendung gehostet werden.

Untergeordnete Anwendungen

Eine ASP.NET Core-App kann als untergeordnete IIS-Anwendung (untergeordnete App) gehostet werden. Der Pfad der untergeordneten App wird ein Teil der URL der Stamm-App.

Statische Assetlinks in der untergeordneten App sollten die Tilde/Schrägstrich-Notation verwenden (~/). Die Tilde/Schrägstrich-Notation löst ein Taghilfsprogramm aus, um die Pfadbasis der untergeordneten App dem gerenderten relativen Link voranzustellen. Für eine untergeordnete App unter /subapp_path wird ein mit src="~/image.png" verknüpftes Bild als src="/subapp_path/image.png" gerendert. Die Static File Middleware verarbeitet die Anforderung der statischen Datei nicht. Die Anforderung wird von der Static File Middleware der untergeordneten App verarbeitet.

Wenn das src-Attribut eines statischen Objekts auf einen absoluten Pfad festgelegt wird (z.B. src="/image.png"), wird der Link ohne die Pfadbasis der untergeordneten App gerendert. Die Middleware für statische Dateien der Stamm-App versucht, das Objekt vom Webstamm der Stamm-App aus bereitzustellen, was zu einer 404 Nicht gefunden-Antwort führt, solange das statische Objekt in der Stamm-App nicht verfügbar ist.

So hosten Sie eine ASP.NET Core-App als untergeordnete App unter einer anderen ASP.NET Core-App:

1. Richten Sie einen App-Pool für die untergeordnete App ein. Legen Sie die .NET CLR-Version auf Kein verwalteter Code fest, weil die Core Common Language Runtime (CoreCLR) für .NET Core gestartet wird, um die App im Workerprozess zu hosten, nicht der Desktop-CLR (.NET CLR).

2. Fügen Sie die Stammwebsite im IIS-Manager mit der untergeordneten App in einem unter der Stammwebsite liegenden Ordner hinzu.

3. Klicken Sie mit der rechten Maustaste im IIS-Manager auf den Ordner der untergeordneten App, und wählen Sie In Anwendung konvertieren aus.

4. Weisen Sie im Dialogfeld Anwendung hinzufügen mit der Schaltfläche Auswählen den Anwendungspool dem App-Pool zu, den Sie für die untergeordnete App erstellt haben. Klicken Sie auf OK.

Die Zuweisung eines separaten App-Pools zur untergeordneten App ist eine Anforderung, wenn Sie das In-Process-Hostingmodell verwenden.

Weitere Informationen zum In-Process-Hostingmodell und zum Konfigurieren des ASP.NET Core-Moduls finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

Konfiguration von IIS mit der Datei „web.config“

Die IIS-Konfiguration wird von dem Abschnitt <system.webServer> der Datei web.config für IIS-Szenarien beeinflusst, die für ASP.NET Core-Apps mit dem ASP.NET Core-Modul funktional sind. Beispielsweise eignet sich die IIS-Konfiguration für dynamische Komprimierung. Wenn IIS auf Serverebene für die Verwendung der dynamischen Komprimierung konfiguriert ist, kann diese Einstellung mit dem <urlCompression>-Element in der Datei web.config der App für eine ASP.NET Core-App deaktiviert werden.

Weitere Informationen finden Sie unter den folgenden Themen:

• Konfigurationsreferenz für <system.webServer>
• ASP.NET Core-Modul (ANCM) für IIS
• IIS-Module mit ASP.NET Core

Um Umgebungsvariablen für einzelne Apps festzulegen, die in isolierten App-Pools ausgeführt werden (unterstützt für IIS 10.0 oder höher), lesen Sie den Abschnitt zum Befehl „AppCmd.exe“ im Thema Umgebungsvariablen <environmentVariables> in der IIS-Referenzdokumentation.

Abschnitte, die nicht von ASP.NET Core verwendet werden

Konfigurationsabschnitte von ASP.NET-Apps in der Datei web.config werden von ASP.NET Core-Apps nicht zur Konfiguration verwendet:

• <system.web>
• <appSettings>
• <connectionStrings>
• <location>

ASP.NET Core-Apps werden mit anderen Konfigurationsanbietern konfiguriert. Weitere Informationen finden Sie unter Konfiguration und in den Konfigurationseinstellungen für die .NET Core-Runtime.

Anwendungspools

Die App-Poolisolation wird durch das Hostingmodell bestimmt.

• In-Process-Hosting: Apps müssen in separaten App-Pools ausgeführt werden.
• Out-of-Process-Hosting: Es wird empfohlen, die Apps voneinander zu isolieren, indem Sie jede App in ihrem eigenen App-Pool ausführen.

Im IIS-Dialogfeld Website hinzufügen wird standardmäßig ein einzelner App-Pool pro App eingesetzt. Wenn ein Websitename angegeben ist, wird der Text automatisch in das Textfeld Anwendungspool übertragen. Ein neuer App-Pool mit dem Namen der Website wird erstellt, wenn die Website hinzugefügt wird.

Anwendungspool Identity

Mit einem Konto für die Identität des App-Pools können Sie eine App unter einem eindeutigen Konto ausführen, ohne Domänen oder lokale Konten erstellen und verwalten zu müssen. Unter IIS 8.0 oder höher erstellt der IIS-Administratorworkerprozess (WAS) ein virtuelles Konto mit dem Namen des neuen App-Pools und führt die Workerprozesse des App-Pools standardmäßig unter diesem Konto aus. Stellen Sie sicher, dass in der IIS-Verwaltungskonsole unter Erweiterte Einstellungen für den App-Pool die Identity (Identität) auf ApplicationPoolIdentity festgelegt ist:

Der IIS-Verwaltungsprozess erstellt im Windows-Sicherheitssystem einen sicheren Bezeichner mit dem Namen des App-Pools. Ressourcen können mithilfe dieser Identität geschützt werden. Allerdings ist diese Identität kein echtes Benutzerkonto und wird in der Windows-Benutzerverwaltungskonsole nicht angezeigt.

Wenn der IIS-Workerprozess erhöhte Rechte für den Zugriff auf Ihre Anwendung erfordert, ändern Sie die Zugriffssteuerungsliste (ACL) für das Verzeichnis mit der App:

1. Öffnen Sie Windows Explorer, und navigieren Sie zum Verzeichnis.

2. Klicken Sie mit der rechten Maustaste auf das Verzeichnis, und klicken Sie auf Eigenschaften.

3. Klicken Sie auf der Registerkarte Sicherheit auf die Schaltfläche Bearbeiten und dann auf die Schaltfläche Hinzufügen.

4. Wählen Sie die Schaltfläche Speicherorte aus, und stellen Sie sicher, dass das System ausgewählt ist.

5. Geben Sie IIS AppPool\{APP POOL NAME} ein. Hierbei steht der Platzhalter {APP POOL NAME} für den Namen des App-Pools im Bereich Geben Sie die Namen der auszuwählenden Objekte ein. Klicken Sie auf die Schaltfläche Namen überprüfen. Überprüfen Sie für DefaultAppPool die Namen mit IIS AppPool\DefaultAppPool. Bei Auswahl der Schaltfläche Namen überprüfen wird im Bereich für Objektnamen der Wert DefaultAppPool angegeben. Es ist nicht möglich, den Namen des App-Pools direkt in den Bereich für Objektnamen einzugeben. Verwenden Sie das Format IIS AppPool\{APP POOL NAME}, wenn Sie den Objektnamen überprüfen. Hierbei steht der Platzhalter {APP POOL NAME} für den Namen des App-Pools.

   

6. Klicken Sie auf OK.

   

7. Standardmäßig sollten Lese- und Schreibberechtigungen gewährt werden. Erteilen Sie weitere Berechtigungen, sofern erforderlich.

Zugriff kann auch über eine Eingabeaufforderung mit dem Tool ICACLS gewährt werden. Im folgenden Befehl wird als Beispiel DefaultAppPool verwendet:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Weitere Informationen finden Sie im Thema icacls.

HTTP/2-Unterstützung

HTTP/2 wird mit ASP.NET Core in den folgenden IIS-Bereitstellungsszenarien unterstützt:

• In-Process
  • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
  • TLS 1.2-Verbindung oder höher
• Out-of-Process
  • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
  • Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit dem Kestrel-Server verwendet HTTP/1.1.
  • TLS 1.2-Verbindung oder höher

Für eine In-Process-Bereitstellung, wenn eine HTTP/2-Verbindung hergestellt wurde, meldet HttpRequest.Protocol den Wert HTTP/2. Für eine Out-of-Process-Bereitstellung, wenn eine HTTP/2-Verbindung hergestellt wurde, meldet HttpRequest.Protocol den Wert HTTP/1.1.

Weitere Informationen zu den In-Process- und Out-of-Process-Hostingmodellen finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

HTTP/2 ist standardmäßig aktiviert. Verbindungen führen ein Fallback auf HTTP/1.1 aus, wenn keine HTTP/2-Verbindung hergestellt wurde. Weitere Informationen zur HTTP/2-Konfiguration mit IIS-Bereitstellungen finden Sie unter HTTP/2 unter IIS.

CORS-Preflightanforderungen

Dieser Abschnitt gilt nur für ASP.NET Core-Apps, die auf das .NET Framework ausgerichtet sind.

Für eine ASP.NET Core-App, die auf das .NET Framework ausgerichtet ist, werden OPTIONS-Anforderungen in IIS standardmäßig nicht an die App übergeben. Informationen dazu, wie Sie die IIS-Handler der App in web.config so konfigurieren, dass OPTIONS-Anforderungen übergeben werden, finden Sie unter Aktivieren ursprungsübergreifender Anforderungen in ASP.NET-Web-API 2: Funktionsweise von CORS.

Anwendungsinitialisierungsmodul und Leerlauftimeout

Bei Hosting in IIS durch Version 2 das ASP.NET Core-Moduls:

• Anwendungsinitialisierungsmodul: App-Hostings vom Typ In-Process oder Out-of-Process können so konfiguriert werden, dass sie automatisch im Rahmen eines Workerprozessneustarts oder eines Serverneustarts gestartet werden.
• Leerlauftimeout: App-Hostings vom Typ In-Process können so konfiguriert werden, dass in Zeiten ohne Aktivität kein Timeout eintritt.

Anwendungsinitialisierungsmodul

Gilt für In-Process und Out-of-Process gehostete Apps.

IIS-Anwendungsinitialisierung ist ein IIS-Feature, das eine HTTP-Anforderung an die App sendet, wenn der App-Pool startet oder wiederverwendet wird. Die Anforderung löst den Start der App aus. Standardmäßig gibt IIS eine Anforderung an die Stamm-URL der App (/) zum Initialisieren der App aus (weitere Informationen zur Konfiguration finden Sie unter Zusätzliche Ressourcen).

Vergewissern Sie sich, dass die IIS-Anwendungsinitialisierungs-Rollenfunktion aktiviert ist:

Unter Windows 7 oder höher gilt für Desktopsysteme bei lokaler Verwendung von IIS:

1. Navigieren Sie zu Systemsteuerung>Programme>Programme und Features>Windows-Features aktivieren oder deaktivieren (links auf dem Bildschirm).
2. Öffnen Sie Internetinformationsdienste>WWW-Dienste>Anwendungsentwicklungsfeatures.
3. Aktivieren Sie das Kontrollkästchen für Anwendungsinitialisierung.

Unter Windows Server 2008 R2 oder höher:

1. Öffnen Sie den Assistenten zum Hinzufügen von Rollen und Features.
2. Öffnen Sie im Bereich Rollendienste auswählen den Knoten Anwendungsentwicklung.
3. Aktivieren Sie das Kontrollkästchen für Anwendungsinitialisierung.

Verwenden Sie einen der folgenden Ansätze, um das Anwendungsinitialisierungsmodul für die Website zu aktivieren:

• Bei Verwenden von IIS-Manager:

  1. Wählen Sie Anwendungspools im Bereich Verbindungen aus.
  2. Klicken Sie mit der rechten Maustaste im App-Pool der App in die Liste, und wählen Sie Erweiterte Einstellungen aus.
  3. Der standardmäßige Startmodus ist OnDemand. Legen Sie den Startmodus auf AlwaysRunning fest. Klicken Sie auf OK.
  4. Öffnen Sie den Knoten Websites im Bereich Verbindungen.
  5. Klicken Sie mit der rechten Maustaste auf die App, und wählen Sie Website verwalten>Erweiterte Einstellungen aus.
  6. Die Standardeinstellung für Vorabladen aktiviert ist False. Legen Sie für Vorabladen aktiviertTrue fest. Klicken Sie auf OK.

• Fügen Sie bei Verwenden von web.config das <applicationInitialization>-Element hinzu, wobei doAppInitAfterRestart für die <system.webServer>-Elemente in der web.config-Datei der App auf true festgelegt ist:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Leerlauftimeout

Gilt nur für In-Process gehostete Apps.

Um zu verhindern, dass die App in den Leerlauf wechselt, legen Sie das Leerlauftimeout des App-Pools mit IIS-Manager fest:

1. Wählen Sie Anwendungspools im Bereich Verbindungen aus.
2. Klicken Sie mit der rechten Maustaste im App-Pool der App in die Liste, und wählen Sie Erweiterte Einstellungen aus.
3. Der Standardwert für Leerlauftimeout (Minuten) ist 20 Minuten. Legen Sie Leerlauftimeout (Minuten) auf 0 (null) fest. Klicken Sie auf OK.
4. Recyceln Sie den Workerprozess.

Um zu verhindern, dass in Apps, die Out-of-Process gehostet werden, ein Timeout auftritt, verwenden Sie einen der folgenden Ansätze:

• Pingen Sie die App von einem externen Dienst aus, damit sie kontinuierlich ausgeführt wird.
• Wenn die App nur Hintergrunddienste hostet, vermeiden Sie IIS-Hosting, und verwenden Sie einen Windows-Dienst, um die ASP.NET Core-App zu hosten.

Zusätzliche Ressourcen für das Anwendungsinitialisierungsmodul und das Leerlauftimeout

• IIS 8.0 Anwendungsinitialisierung
• Anwendungsinitialisierung <applicationInitialization>.
• Verarbeiten von Modelleinstellungen für einen Anwendungspool <ProcessModel>.

Bereitstellungsressourcen für IIS-Administratoren

• IIS-Dokumentation
• Erste Schritte mit IIS-Manager in IIS
• .NET Core-Anwendungsbereitstellung
• ASP.NET Core-Modul (ANCM) für IIS
• Verzeichnisstruktur für ASP.NET Core
• IIS-Module mit ASP.NET Core
• Problembehandlung bei ASP.NET Core in Azure App Service und IIS
• Problembehandlung für häufige Fehler bei Azure App Service und IIS mit ASP.NET Core

Zusätzliche Ressourcen

• Problembehandlung und Debuggen von ASP.NET Core-Projekten
• Übersicht über ASP.NET Core
• Die offizielle Microsoft IIS-Website
• Bibliothek mit technischem Inhalt zu Windows Server
• HTTP/2 unter IIS
• Transformieren von web.config

Ein Tutorial zum Veröffentlichen einer ASP.NET Core-App auf einem IIS-Server finden Sie unter Veröffentlichen einer ASP.NET Core-App in IIS.

Installieren des .NET Core Hosting-Pakets

Unterstützte Betriebssysteme

Die folgenden Betriebssysteme werden unterstützt:

• Windows 7 oder höher
• Windows Server 2008 R2 oder höher

Der HTTP.sys-Server (zuvor WebListener genannt) funktioniert nicht in einer Reverseproxykonfiguration mit IIS. Verwenden Sie den Kestrel-Server.

Informationen zum Hosting in Azure finden Sie unter Bereitstellen von ASP.NET Core-Apps in Azure App Service.

Anleitungen zur Problembehandlung finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Unterstützte Plattformen

Apps, die für Bereitstellungen für 32-Bit-Systeme (x86) oder 64-Bit-Systeme (x64) veröffentlicht wurden, werden unterstützt. Stellen Sie eine 32-Bit-App mit einem .NET Core SDK für 32-Bit (x86) bereit, es sei denn:

• Die App benötigt den größeren Adressraum des virtuellen Arbeitsspeichers, der 64-Bit-Apps zur Verfügung steht.
• Die App erfordert den größeren IIS-Stapel.
• Die App weist native 64-Bit-Abhängigkeiten auf.

Verwenden Sie ein .NET Core SDK für 64-Bit (x64), um eine 64-Bit-App zu veröffentlichen. Auf dem Hostsystem muss eine 64-Bit-Runtime vorhanden sein.

ASP.NET Core wird mit einem Kestrel-Server ausgeliefert, einem plattformübergreifenden HTTP-Standardserver.

Wenn Sie IIS oder IIS Express verwenden, wird die App in einem anderen Prozess als dem IIS-Workerprozess (Out-of-Process) mit dem Kestrel-Server ausgeführt.

Da ASP.NET Core-Apps in einem Prozess getrennt vom IIS-Arbeitsprozess ausgeführt werden, führt das 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:

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

Das Modul gibt den Port über die Umgebungsvariable beim Start an. Die Middleware für die Integration von IIS konfiguriert den Server so, dass er auf 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 per Push 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, wo sie per Push an den HTTP-Client zurückgegeben wird, der die Anforderung initiiert hat.

CreateDefaultBuilder konfiguriert den Kestrel-Server als Webserver und aktiviert die IIS-Integration durch Konfiguration des Basispfads und Ports für das ASP.NET Core-Modul.

Das ASP.NET Core-Modul generiert einen dynamischen Port, der dem Back-End-Prozess zugewiesen wird. CreateDefaultBuilder ruft die UseIISIntegration-Methode auf. UseIISIntegration konfiguriert Kestrel so, dass an dem dynamischen Port an der Localhost-IP-Adresse (127.0.0.1) gelauscht wird. Wenn der dynamische Port 1234 lautet, lauscht Kestrel an 127.0.0.1:1234. Diese Konfiguration ersetzt andere Konfigurationen von:

• UseUrls
• Listen API von Kestrel
• der Konfiguration (oder der Befehlszeilenoption „--urls)

Aufrufe von UseUrls oder der Listen API von Kestrel sind nicht erforderlich, wenn das Modul verwendet wird. Wenn UseUrls oder Listen aufgerufen wird, lauscht Kestrel nur an dem angegebenen Port, wenn die App ohne IIS ausgeführt wird.

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 CreateWebHostBuilder (Program.cs) CreateDefaultBuilder ab, um die IIS-Integration zu aktivieren:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

Weitere Informationen zu CreateDefaultBuilder finden Sie unter ASP.NET Core-Webhost.

IIS-Optionen

Option	Standard	Einstellung
AutomaticAuthentication	true	Bei Festlegung auf true legt der Server den per Windows-Authentifizierung authentifizierten HttpContext.User fest. Bei Festlegung auf false stellt der Server nur eine Identität für HttpContext.User bereit und antwortet auf explizite Anforderungen durch das AuthenticationScheme. Die Windows-Authentifizierung muss in IIS aktiviert sein, damit AutomaticAuthentication funktioniert. Weitere Informationen finden Sie unter Windows-Authentifizierung.
AuthenticationDisplayName	null	Legt den Anzeigename fest, der Benutzern auf Anmeldungsseiten angezeigt wird

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 das 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 Integration von IIS, die die Middleware für weitergeleitete Header konfiguriert, und das ASP.NET Core-Modul sind so konfiguriert, dass sie das Schema (HTTP/HTTPS) und die Remote-IP-Adresse an die Stelle weiterleiten, von der die Anforderung stammte. 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.

Datei „web.config“

Mit der Datei web.config wird das ASP.NET Core-Modul konfiguriert. Die Erstellung, Transformation und Veröffentlichung der Datei web.config wird bei der Projektveröffentlichung von einem MSBuild-Ziel (_TransformWebConfig) abgewickelt. Dieses Ziel ist in den Web SDK-Zielen (Microsoft.NET.Sdk.Web) vorhanden. Das SDK wird am Anfang der Projektdatei festgelegt:

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

Wenn im Projekt keine Datei namens web.config vorhanden ist, wird sie zur Konfiguration des ASP.NET Core-Moduls mit dem richtigen processPath- und arguments-Attribut erstellt und in die veröffentlichte Ausgabe verschoben.

Ist eine Datei namens web.config im Projekt vorhanden, wird sie zur Konfiguration des ASP.NET Core-Moduls mit dem richtigen processPath- und arguments-Attribut transformiert und in die veröffentlichte Ausgabe verschoben. Die Transformation ändert die IIS-Konfigurationseinstellungen in der Datei nicht.

Die Datei web.config kann zusätzliche IIS-Konfigurationseinstellungen zum Steuern der aktiven IIS-Module bereitstellen. Informationen zu IIS-Modulen, die Anforderungen mit ASP.NET Core-Apps verarbeiten können, finden Sie im Thema IIS-Module.

Um zu verhindern, dass das Web-SDK die Datei web.config transformiert, verwenden Sie die Eigenschaft <IsTransformWebConfigDisabled> in der Projektdatei:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Wenn die Transformation der Datei durch das Web-SDK deaktiviert wird, müssen die Attribute processPath und arguments manuell durch den Entwickler festgelegt werden. Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Speicherort der Datei „web.config“

Zum Erstellen des ASP.NET Core-Moduls muss die Datei web.config im Inhaltsstammpfad (normalerweise dem App-Basispfad) der bereitgestellten App vorhanden sein. Dies ist der physische Pfad der Website, der in IIS bereitgestellt wurde. Die Datei Web.config wird im Stammverzeichnis der App benötigt, um die Veröffentlichung mehrerer Apps mit Web Deploy zu ermöglichen.

Im physischen Pfad der App sind vertrauliche Dateien vorhanden, wie z. B. <assembly>.runtimeconfig.json, <assembly>.xml (XML-Dokumentationskommentare) und <assembly>.deps.json. Wenn die web.config-Datei vorhanden ist und die Website normal startet, werden diese vertraulichen Dateien bei Anforderung nicht offengelegt. Wenn die Datei web.config fehlt, falsch benannt wurde oder die Website nicht für den normalen Start konfigurieren kann, macht IIS vertrauliche Dateien möglicherweise öffentlich verfügbar.

Die Datei web.config muss immer in der Bereitstellung vorhanden, richtig benannt und in der Lage sein, die Website für einen normalen Start zu konfigurieren. Entfernen Sie die Datei web.config niemals aus einer Produktionsbereitstellung.

Transformieren von web.config

Wenn Sie web.config beim Veröffentlichen transformieren müssen (z.B. Umgebungsvariablen basierend auf der Konfiguration, dem Profil oder der Umgebung festlegen müssen), finden Sie weitere Informationen unter Transformieren von web.config.

IIS-Konfiguration

Windows Server-Betriebssysteme

Aktivieren Sie die Serverrolle Webserver (IIS) , und richten Sie Rollendienste ein.

1. Verwenden Sie den Assistenten Rollen und Features hinzufügen im Menü Verwalten oder den Link in Server-Manager. Aktivieren Sie im Schritt Serverrollen das Kontrollkästchen für Webserver (IIS) .

   

2. Nach dem Schritt Features wird der Schritt Rollendienste für Webserver (IIS) geladen. Wählen Sie die gewünschten IIS-Rollendienste aus, oder übernehmen Sie die bereitgestellten Standardrollendienste.

   

   Windows-Authentifizierung (optional)
   Um die Windows-Authentifizierung zu aktivieren, erweitern Sie die folgenden Knoten: Webserver>Sicherheit. Wählen Sie das Feature Windows-Authentifizierung aus. Weitere Informationen finden Sie unter Windows-Authentifizierung <windowsAuthentication> und Konfigurieren der Windows-Authentifizierung.

   WebSockets (optional)
   WebSockets wird mit ASP.NET Core 1.1 oder höher unterstützt. Um WebSockets zu aktivieren, erweitern Sie die folgenden Knoten: Webserver>Anwendungsentwicklung. Wählen Sie das Feature WebSocket-Protokoll aus. Weitere Informationen finden Sie unter WebSockets.

3. Fahren Sie mit dem Schritt Bestätigung fort, um die Webserverrolle und die Dienste zu installieren. Ein Server-/IIS-Neustart ist nach der Installation der Rolle Webserver (IIS) nicht erforderlich.

Windows-Desktopbetriebssysteme

Aktivieren Sie die IIS-Verwaltungskonsole und die WWW-Dienste.

1. Navigieren Sie zu Systemsteuerung>Programme>Programme und Features>Windows-Features aktivieren oder deaktivieren (links auf dem Bildschirm).

2. Öffnen Sie den Knoten Internetinformationsdienste. Öffnen Sie den Knoten Webverwaltungstools.

3. Aktivieren Sie das Kontrollkästchen für IIS-Verwaltungskonsole.

4. Aktivieren Sie das Kontrollkästchen für WWW-Dienste.

5. Akzeptieren Sie die Standardfeatures für WWW-Dienste, oder passen Sie die IIS-Features an.

   Windows-Authentifizierung (optional)
   Um die Windows-Authentifizierung zu aktivieren, erweitern Sie die folgenden Knoten: WWW-Dienste>Sicherheit. Wählen Sie das Feature Windows-Authentifizierung aus. Weitere Informationen finden Sie unter Windows-Authentifizierung <windowsAuthentication> und Konfigurieren der Windows-Authentifizierung.

   WebSockets (optional)
   WebSockets wird mit ASP.NET Core 1.1 oder höher unterstützt. Um WebSockets zu aktivieren, erweitern Sie die folgenden Knoten: WWW-Dienste>Anwendungsentwicklungsfeatures. Wählen Sie das Feature WebSocket-Protokoll aus. Weitere Informationen finden Sie unter WebSockets.

6. Wenn die IIS-Installation einen Neustart erfordert, starten Sie das System neu.

Installieren des .NET Core Hosting-Pakets

Installieren Sie das Paket „.NET Core Hosting“ im Hostsystem. Das Paket installiert die .NET Core-Runtime, die .NET Core-Bibliothek und das ASP.NET Core-Modul. Mit dem Modul können ASP.NET Core-Apps hinter IIS ausgeführt werden.

Herunterladen

1. Navigieren Sie zur .NET Core-Downloadseite.
2. Wählen Sie die gewünschte .NET Core-Version aus.
3. Suchen Sie in der Spalte Run apps - Runtime (Apps ausführen – Runtime) die Zeile mit der gewünschten .NET Core-RuntimeRuntime-Version.
4. Laden Sie den Installer über den Link das Hosting Bundle (Hosting-Paket) herunter.

Installieren des Hosting-Pakets

1. Führen Sie das Installationsprogramm auf dem Server aus. Die folgenden Parameter sind verfügbar, wenn Sie das Installationsprogramm über eine Administratorbefehlsshell ausführen.

   • OPT_NO_ANCM=1: Überspringen Sie die Installation des ASP.NET Core-Moduls.
   • OPT_NO_RUNTIME=1: Überspringen Sie die Installation der .NET Core-Runtime. Wird verwendet, wenn der Server nur eigenständige Bereitstellungen (Self-contained Deployments, SCD) hostet.
   • OPT_NO_SHAREDFX=1: Überspringen Sie die Installation des freigegebenen ASP.NET-Frameworks (ASP.NET-Runtime). Wird verwendet, wenn der Server nur eigenständige Bereitstellungen (Self-contained Deployments, SCD) hostet.
   • OPT_NO_X86=1: Überspringen Sie die Installation von x86-Runtimes. Verwenden Sie diesen Parameter, wenn Sie wissen, dass Sie keine 32-Bit-Apps hosten. Sollte die Möglichkeit bestehen, dass Sie sowohl 32-Bit- als auch 64-Bit-Apps hosten könnten, verwenden Sie diesen Parameter nicht, und installieren Sie beide Runtimes.
   • OPT_NO_SHARED_CONFIG_CHECK=1: Deaktivieren Sie die Überprüfung auf Verwendung einer gemeinsamen IIS-Konfiguration, wenn sich die gemeinsam genutzte Konfiguration (applicationHost.config) auf demselben Computer wie die IIS-Installation befindet. Nur für Installationsprogramme für Hostingbundles für ASP.NET Core 2.2 oder höher verfügbar. Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

2. Starten Sie das System neu, oder führen Sie die folgenden Befehle in einer Befehlsshell aus:

   net stop was /y
   net start w3svc
   

   Durch den Neustart von IIS wird eine Änderung an der PATH-Systemeinstellung – einer Umgebungsvariable – angewendet, die durch den Installer vorgenommen wurde.

Beim Installieren des Hostingpakets müssen die einzelnen Websites in IIS nicht manuell angehalten werden. Gehostete Apps (IIS-Websites) werden beim Neustart von IIS neu gestartet. Apps starten wieder, wenn die erste Anforderung eintrifft, beispielsweise aus dem Anwendungsinitialisierungsmodul.

ASP.NET Core wendet ein Rollforwardverhalten für Patchversionen freigegebener Frameworkpaketen an. Wenn von IIS gehostete Apps mit IIS neu starten, werden sie mit den neuesten Patchversionen der referenzierten Pakete geladen, sobald sie die erste Anforderung empfangen. Wenn IIS nicht neu gestartet wird, starten die Apps neu und wenden ein Rollforwardverhalten an, wenn die Workerprozesse neu starten und die Apps die erste Anforderung empfangen.

Installieren von Web Deploy beim Veröffentlichen mit Visual Studio

Wenn Sie Apps auf Servern mit Web Deploy bereitstellen, installieren Sie die neueste Version von Web Deploy auf dem Server. Verwenden Sie den Webplattform-Installer (WebPI) oder IIS-Downloads: Web Deploy, um Web Deploy zu installieren. Die bevorzugte Methode ist die Verwendung von WebPI. WebPI bietet ein eigenständiges Setup und eine Konfiguration für Hostinganbieter.

Erstellen der IIS-Website

1. Erstellen Sie auf dem Hostingsystem einen Ordner zum Speichern der veröffentlichten Ordner und Dateien der App. In einem späteren Schritt wird der Ordnerpfad als physischer App-Pfad in IIS angegeben. Weitere Informationen zum Bereitstellungsordner und zum Dateilayout einer App finden Sie unter ASP.NET Core-Verzeichnisstruktur.

2. Öffnen Sie in IIS-Manager den Serverknoten im Bereich Verbindungen. Klicken Sie mit der rechten Maustaste auf den Ordner Websites. Klicken Sie im Kontextmenü auf Website hinzufügen.

3. Geben Sie einen Websitenamen an, und legen Sie den physischen Pfad auf den Bereitstellungsordner der App fest. Geben Sie die Konfiguration unter Bindung an, und erstellen Sie die Website, indem Sie auf OK klicken:

   

   Warnung

   Allgemeine Platzhalterbindungen (http://*:80/ und http://+:80) dürfen nicht verwendet werden. Platzhalterbindungen auf oberster Ebene gefährden die Sicherheit Ihrer App. Dies gilt für starke und schwache Platzhalter. Verwenden Sie statt Platzhaltern explizite Hostnamen. Platzhalterbindungen in untergeordneten Domänen (z.B. *.mysub.com) verursachen kein Sicherheitsrisiko, wenn Sie die gesamte übergeordnete Domäne steuern (im Gegensatz zu *.com, das angreifbar ist). Weitere Informationen finden Sie unter RFC 9110: HTTP-Semantik (Abschnitt 7.2. Host und :authority).

4. Wählen Sie unter dem Serverknoten Anwendungspools aus.

5. Klicken Sie mit der rechten Maustaste auf den App-Pool der Website, und wählen Sie im Kontextmenü Grundeinstellungen aus.

6. Legen Sie im Fenster Anwendungspool bearbeiten die .NET CLR-Version auf Kein verwalteter Code fest:

   

   ASP.NET Core wird in einem separaten Prozess ausgeführt und verwaltet die Runtime. ASP.NET Core basiert nicht auf dem Laden des Desktop-CLR (.NET CLR). Die Core Common Language Runtime (CoreCLR) für .NET Core wird gestartet, um die App im Workerprozess zu hosten. Das Festlegen der .NET CLR-Version auf Kein verwalteter Code ist optional, wird aber empfohlen.

7. ASP.NET Core 2.2 oder höher: Deaktivieren Sie für eine eigenständige Bereitstellung für 64-Bit-Systeme (x64), die das In-Process-Hostingmodell verwendet, den App-Pool für 32-Bit-Prozesse (x86).

   Wählen Sie in der Seitenleiste Aktionen von IIS-Manager >Anwendungspools, Standardwerte für Anwendungspool festlegen oder Erweiterte Einstellungen aus. Suchen Sie nach 32-Bit-Anwendungen aktivieren, und legen Sie den Wert auf False fest. Diese Einstellung wirkt sich nicht auf Apps aus, die für Out-of-Process-Hosting bereitgestellt wurden.

8. Vergewissern Sie sich, dass die Prozessmodellidentität über die richtigen Berechtigungen verfügt.

   Wenn die Standardidentität des App-Pools (Prozessmodell>Identity) von ApplicationPoolIdentity in eine andere Identität geändert wird, sollten Sie sicherstellen, dass die neue Identität über die erforderlichen Berechtigungen zum Zugriff auf den Ordner, die Datenbank und andere erforderliche Ressourcen der App verfügt. Der App-Pool benötigt beispielsweise Lese- und Schreibzugriff für Ordner, in denen die App Lese- und Schreibvorgänge für Dateien ausführt.

Konfigurieren der Windows-Authentifizierung (optional)
Weitere Informationen finden Sie unter Konfigurieren der Windows-Authentifizierung.

Bereitstellen der App

Stellen Sie die App im IIS-Ordner Physischer Pfad bereit, der im Abschnitt Erstellen der IIS-Website eingerichtet wurde. Web Deploy ist die empfohlene Methode für die Bereitstellung, aber es gibt verschiedene Optionen, um die Anwendung aus dem Ordner publish des Projekts in den Bereitstellungsordner des Hostsystems zu verschieben.

Web Deploy mit Visual Studio

Informationen zum Erstellen eines Veröffentlichungsprofils zur Verwendung mit Web Deploy finden Sie im Thema Visual Studio publish profiles for ASP.NET Core app deployment (Visual Studio-Veröffentlichungsprofile zum Bereitstellen von ASP.NET Core-Apps). Wenn der Hostinganbieter ein Veröffentlichungsprofil oder Unterstützung für das Erstellen eines solchen Profils bereitstellt, laden Sie dessen Profil herunter, und importieren Sie es mithilfe des Visual Studio-Dialogfelds Veröffentlichen:

Web Deploy außerhalb von Visual Studio

Web Deploy kann über die Befehlszeile auch außerhalb von Visual Studio verwendet werden. Weitere Informationen finden Sie unter Web Deployment Tool (Webbereitstellungstool).

Alternativen zu Web Deploy

Verwenden Sie eine der folgenden Methoden, um die App in das Hostsystem zu verschieben: manuelles Kopieren, Xcopy, Robocopy oder PowerShell.

Weitere Informationen zum Bereitstellen von ASP.NET Core in IIS finden Sie im nachfolgenden Abschnitt Bereitstellungsressourcen für IIS-Administratoren.

Navigieren auf der Website

Senden Sie nach Abschluss der App-Bereitstellung auf dem Hostsystem eine Anforderung an einen der öffentlichen Endpunkte der App.

Im folgenden Beispiel ist die Website an den IIS-Hostnamen von www.mysite.com auf Port 80 gebunden. Es wird eine Anforderung an http://www.mysite.com gesendet:

Gesperrte Bereitstellungsdateien

Die Dateien im Bereitstellungsordner werden gesperrt, wenn die App ausgeführt wird. Gesperrte Dateien können während der Bereitstellung nicht überschrieben werden. Um gesperrte Dateien in einer Bereitstellung freizugeben, beenden Sie den App-Pool mit einer der folgenden Methoden:

• Verwenden Sie Web Deploy, und verweisen Sie auf Microsoft.NET.Sdk.Web in der Projektdatei. Eine Datei namens app_offline.htm befindet sich im Stammverzeichnis des Web-App-Verzeichnisses. Wenn die Datei vorhanden ist, fährt das ASP.NET Core Module die App ordnungsgemäß herunter und verarbeitet die Datei app_offline.htm während der Bereitstellung. Weitere Informationen finden Sie unter Konfigurationsreferenz für das ASP.NET Core-Modul.

• Beenden Sie den App-Pool im IIS-Manager auf dem Server manuell.

• Verwenden Sie PowerShell, um app_offline.htm abzulegen (erfordert PowerShell 5 oder höher):

  $pathToApp = 'PATH_TO_APP'
  
  # Stop the AppPool
  New-Item -Path $pathToApp app_offline.htm
  
  # Provide script commands here to deploy the app
  
  # Restart the AppPool
  Remove-Item -Path $pathToApp app_offline.htm
  
  

Schutz von Daten

Der ASP.NET Core-Stapel zum Schutz von Daten wird von mehreren ASP.NET-Middlewarekomponenten genutzt, darunter auch von Middleware, die bei der Authentifizierung verwendet wird. Selbst wenn die APIs zum Schutz von Daten nicht aus dem Benutzercode aufgerufen werden, sollte der Schutz von Daten mit einem Bereitstellungsskript oder im Benutzercode konfiguriert werden, um einen persistenten kryptografischen Schlüsselspeicher zu erstellen. Wenn der Schutz von Daten nicht konfiguriert ist, werden die Schlüssel beim Neustarten der App im Arbeitsspeicher gespeichert und verworfen.

Falls der Schlüsselbund im Arbeitsspeicher gespeichert wird, wenn die App neu gestartet wird, gilt Folgendes:

• Alle cookiebasierten Authentifizierungstoken werden für ungültig erklärt.
• Benutzer müssen sich bei ihrer nächsten Anforderung erneut anmelden.
• Alle mit dem Schlüsselbund geschützte Daten können nicht mehr entschlüsselt werden. Dies kann CSRF-Token und ASP.NET Core-MVC-TempData-Cookies einschließen.

Zum Konfigurieren des Schutzes von Daten unter IIS mithilfe des persistenten Schlüsselbunds verwenden Sie einen der folgenden Ansätze:

• Erstellen einer Registrierungsstruktur für den Schutz von Daten

  Schlüssel für den Schutz von Daten, die von ASP.NET Core-Apps verwendet werden, werden in der Registrierung außerhalb der Apps gespeichert. Um die Schlüssel für eine bestimmte App zu dauerhaft zu speichern, müssen Sie Registrierungsschlüssel für den App-Pool erstellen.

  Bei eigenständigen IIS-Installationen, die ohne Webfarm vorgesehen sind, kann das PowerShell-Skript „Provision-AutoGenKeys.ps1“ für den Schutz von Daten für jeden App-Pool genutzt werden, das mit einer ASP.NET Core-App verwendet wird. Dieses Skript erstellt einen Registrierungsschlüssel in der HKLM-Registrierung, der nur für das Workerprozesskonto des App-Pools der App zugänglich ist. Schlüssel werden in ruhendem Zustand mit DPAPI mit einem computerweiten Schlüssel verschlüsselt.

  In Webfarmszenarios kann eine App so konfiguriert werden, dass sie einen UNC-Pfad verwendet, um den Schlüsselbund für den Schutz von Daten zu speichern. Standardmäßig werden die Schlüssel für den Schutz von Daten nicht verschlüsselt. Stellen Sie sicher, dass die Dateiberechtigungen für die Netzwerkfreigabe auf das Windows-Konto beschränkt sind, mit dem die App ausgeführt wird. Ein X.509-Zertifikat kann zum Schutz von Schlüsseln im ruhenden Zustand verwendet werden. Richten Sie ggf. einen Mechanismus ein, um es Benutzern zu ermöglichen, Zertifikate hochzuladen: Platzieren Sie Zertifikate im Zertifikatspeicher des Benutzers für vertrauenswürdige Anbieter, und stellen Sie sicher, dass sie auf allen Computern verfügbar sind, auf denen die App des Benutzers ausgeführt wird. Details finden Sie unter Konfigurieren des Schutzes von Daten in ASP.NET Core.

• Konfigurieren des IIS-Anwendungspools zum Laden des Benutzerprofils

  Diese Einstellung befindet sich im Abschnitt Prozessmodell unter Erweiterte Einstellungen für den App-Pool. Legen Sie Benutzerprofil laden auf True fest. Wenn diese Option auf True festgelegt ist, werden Schlüssel im Benutzerprofilverzeichnis gespeichert und mit DPAPI mit einem für das Benutzerkonto spezifischen Schlüssel geschützt. Schlüssel werden im Ordner %LOCALAPPDATA%/ASP.NET/DataProtection-Keys gespeichert.

  Das setProfileEnvironment-Attribut des App-Pools muss ebenfalls aktiviert sein. Der Standardwert von setProfileEnvironment ist true. In einigen Szenarien (z.B. Windows-Betriebssystem) ist setProfileEnvironment auf false festgelegt. Gehen Sie folgendermaßen vor, wenn Schlüssel nicht wie erwartet im Benutzerprofilverzeichnis gespeichert werden:

  1. Navigieren Sie zum Ordner %windir%/system32/inetsrv/config.
  2. Öffnen Sie die Datei applicationHost.config.
  3. Suchen Sie das Element <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
  4. Bestätigen Sie, dass das setProfileEnvironment-Attribut nicht vorhanden ist, das standardmäßig den Wert true aufweist, oder legen Sie den Wert des Attributs explizit auf true fest.

• Verwenden des Dateisystems als Schlüsselbundspeicher

  Passen Sie den App-Code so an, dass er das Dateisystem als Schlüsselbundspeicher verwendet. Verwenden Sie ein X.509-Zertifikat, um den Schlüsselbund zu schützen, und stellen Sie sicher, dass es sich bei dem Zertifikat um ein vertrauenswürdiges Zertifikat handelt. Wenn es sich um ein selbstsigniertes Zertifikat handelt, müssen Sie es im vertrauenswürdigen Stammspeicher platzieren.

  Wenn IIS in einer Webfarm verwendet wird:

  • Verwenden Sie eine Dateifreigabe, auf die alle Computer zugreifen können.
  • Stellen Sie ein X509-Zertifikat auf jedem Computer bereit. Konfigurieren Sie den Schutz von Daten im Code.

• Festlegen einer computerweiten Richtlinie für den Schutz von Daten

  Das System zum Schutz von Daten verfügt über eine eingeschränkte Unterstützung zum Festlegen einer computerweiten Standardrichtlinie für alle Apps, die die Datenschutz-APIs nutzen. Weitere Informationen finden Sie unter ASP.NET Core-Datenschutz: Übersicht.

Virtuelle Verzeichnisse

Virtuelle IIS-Verzeichnisse werden mit ASP.NET Core-Apps nicht unterstützt. Eine App kann als untergeordnete Anwendung gehostet werden.

Untergeordnete Anwendungen

Eine ASP.NET Core-App kann als untergeordnete IIS-Anwendung (untergeordnete App) gehostet werden. Der Pfad der untergeordneten App wird ein Teil der URL der Stamm-App.

Eine untergeordnete App sollte kein ASP.NET Core-Modul als Handler enthalten. Wenn das Modul als Handler in einer web.config einer untergeordneten App hinzugefügt wird, erhalten Sie beim Versuch, zur untergeordneten App zu navigieren, den Fehler 500.19: Interner Serverfehler. Dieser verweist auf die fehlerhafte Konfigurationsdatei.

Das folgende Beispiel zeigt den Inhalt einer veröffentlichten Datei web.config für eine untergeordnete ASP.NET Core-App:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Wenn Sie eine untergeordnete App ohne ASP.NET Core unterhalb einer ASP.NET Core-App hosten, entfernen Sie den geerbten Handler ausdrücklich aus der Datei web.config der untergeordneten App:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Statische Assetlinks in der untergeordneten App sollten die Tilde/Schrägstrich-Notation verwenden (~/). Die Tilde/Schrägstrich-Notation löst ein Taghilfsprogramm aus, um die Pfadbasis der untergeordneten App dem gerenderten relativen Link voranzustellen. Für eine untergeordnete App unter /subapp_path wird ein mit src="~/image.png" verknüpftes Bild als src="/subapp_path/image.png" gerendert. Die Static File Middleware verarbeitet die Anforderung der statischen Datei nicht. Die Anforderung wird von der Static File Middleware der untergeordneten App verarbeitet.

Wenn das src-Attribut eines statischen Objekts auf einen absoluten Pfad festgelegt wird (z.B. src="/image.png"), wird der Link ohne die Pfadbasis der untergeordneten App gerendert. Die Middleware für statische Dateien der Stamm-App versucht, das Objekt vom Webstamm der Stamm-App aus bereitzustellen, was zu einer 404 Nicht gefunden-Antwort führt, solange das statische Objekt in der Stamm-App nicht verfügbar ist.

So hosten Sie eine ASP.NET Core-App als untergeordnete App unter einer anderen ASP.NET Core-App:

1. Richten Sie einen App-Pool für die untergeordnete App ein. Legen Sie die .NET CLR-Version auf Kein verwalteter Code fest, weil die Core Common Language Runtime (CoreCLR) für .NET Core gestartet wird, um die App im Workerprozess zu hosten, nicht der Desktop-CLR (.NET CLR).

2. Fügen Sie die Stammwebsite im IIS-Manager mit der untergeordneten App in einem unter der Stammwebsite liegenden Ordner hinzu.

3. Klicken Sie mit der rechten Maustaste im IIS-Manager auf den Ordner der untergeordneten App, und wählen Sie In Anwendung konvertieren aus.

4. Weisen Sie im Dialogfeld Anwendung hinzufügen mit der Schaltfläche Auswählen den Anwendungspool dem App-Pool zu, den Sie für die untergeordnete App erstellt haben. Klicken Sie auf OK.

Die Zuweisung eines separaten App-Pools zur untergeordneten App ist eine Anforderung, wenn Sie das In-Process-Hostingmodell verwenden.

Weitere Informationen zum In-Process-Hostingmodell und zum Konfigurieren des ASP.NET Core-Moduls finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

Konfiguration von IIS mit der Datei „web.config“

Die IIS-Konfiguration wird von dem Abschnitt <system.webServer> der Datei web.config für IIS-Szenarien beeinflusst, die für ASP.NET Core-Apps mit dem ASP.NET Core-Modul funktional sind. Beispielsweise eignet sich die IIS-Konfiguration für dynamische Komprimierung. Wenn IIS auf Serverebene für die Verwendung der dynamischen Komprimierung konfiguriert ist, kann diese Einstellung mit dem <urlCompression>-Element in der Datei web.config der App für eine ASP.NET Core-App deaktiviert werden.

Weitere Informationen finden Sie unter den folgenden Themen:

• Konfigurationsreferenz für <system.webServer>
• ASP.NET Core-Modul (ANCM) für IIS
• IIS-Module mit ASP.NET Core

Um Umgebungsvariablen für einzelne Apps festzulegen, die in isolierten App-Pools ausgeführt werden (unterstützt für IIS 10.0 oder höher), lesen Sie den Abschnitt zum Befehl „AppCmd.exe“ im Thema Umgebungsvariablen <environmentVariables> in der IIS-Referenzdokumentation.

Abschnitte, die nicht von ASP.NET Core verwendet werden

Konfigurationsabschnitte von ASP.NET 4.x-Apps in der Datei web.config werden von ASP.NET Core-Apps nicht zur Konfiguration verwendet:

• <system.web>
• <appSettings>
• <connectionStrings>
• <location>

ASP.NET Core-Apps werden mit anderen Konfigurationsanbietern konfiguriert. Weitere Informationen finden Sie unter Konfiguration.

Anwendungspools

Wenn Sie mehrere Websites auf einem Server hosten, wird empfohlen, die Apps voneinander zu isolieren, indem Sie jede App in ihrem eigenen App-Pool ausführen. Im IIS-Dialogfeld Website hinzufügen wird standardmäßig diese Konfiguration eingesetzt. Wenn ein Websitename angegeben ist, wird der Text automatisch in das Textfeld Anwendungspool übertragen. Ein neuer App-Pool mit dem Namen der Website wird erstellt, wenn die Website hinzugefügt wird.

Anwendungspool Identity

Mit einem Konto für die Identität des App-Pools können Sie eine App unter einem eindeutigen Konto ausführen, ohne Domänen oder lokale Konten erstellen und verwalten zu müssen. Unter IIS 8.0 oder höher erstellt der IIS-Administratorworkerprozess (WAS) ein virtuelles Konto mit dem Namen des neuen App-Pools und führt die Workerprozesse des App-Pools standardmäßig unter diesem Konto aus. Stellen Sie sicher, dass in der IIS-Verwaltungskonsole unter Erweiterte Einstellungen für den App-Pool die Identity (Identität) auf ApplicationPoolIdentity festgelegt ist:

Der IIS-Verwaltungsprozess erstellt im Windows-Sicherheitssystem einen sicheren Bezeichner mit dem Namen des App-Pools. Ressourcen können mithilfe dieser Identität geschützt werden. Allerdings ist diese Identität kein echtes Benutzerkonto und wird in der Windows-Benutzerverwaltungskonsole nicht angezeigt.

Wenn der IIS-Workerprozess erhöhte Rechte für den Zugriff auf Ihre Anwendung erfordert, ändern Sie die Zugriffssteuerungsliste (ACL) für das Verzeichnis mit der App:

1. Öffnen Sie Windows Explorer, und navigieren Sie zum Verzeichnis.

2. Klicken Sie mit der rechten Maustaste auf das Verzeichnis, und klicken Sie auf Eigenschaften.

3. Klicken Sie auf der Registerkarte Sicherheit auf die Schaltfläche Bearbeiten und dann auf die Schaltfläche Hinzufügen.

4. Wählen Sie die Schaltfläche Speicherorte aus, und stellen Sie sicher, dass das System ausgewählt ist.

5. Geben Sie im Bereich Geben Sie die Namen der auszuwählenden Objekte ein den Wert IIS AppPool\<Name_des_AppPools> ein. Klicken Sie auf die Schaltfläche Namen überprüfen. Überprüfen Sie für DefaultAppPool die Namen mit IIS AppPool\DefaultAppPool. Bei Auswahl der Schaltfläche Namen überprüfen wird im Bereich für Objektnamen der Wert DefaultAppPool angegeben. Es ist nicht möglich, den Namen des App-Pools direkt in den Bereich für Objektnamen einzugeben. Verwenden Sie das Format IIS AppPool\<Name_des_AppPools>, wenn Sie die Objektnamen überprüfen.

   

6. Klicken Sie auf OK.

   

7. Standardmäßig sollten Lese- und Schreibberechtigungen gewährt werden. Erteilen Sie weitere Berechtigungen, sofern erforderlich.

Zugriff kann auch über eine Eingabeaufforderung mit dem Tool ICACLS gewährt werden. Im folgenden Befehl wird als Beispiel DefaultAppPool verwendet:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Weitere Informationen finden Sie im Thema icacls.

HTTP/2-Unterstützung

HTTP/2 wird für Out-of-Process-Bereitstellungen unterstützt, die die folgenden Grundanforderungen erfüllen:

• Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
• Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit dem Kestrel-Server verwendet HTTP/1.1.
• Zielframework: Nicht zutreffend für Out-of-Process-Bereitstellungen, da die HTTP/2-Verbindung vollständig von IIS verarbeitet wird.
• TLS 1.2-Verbindung oder höher

Wenn eine HTTP/2-Verbindung hergestellt wurde, meldet HttpRequest.ProtocolHTTP/1.1.

HTTP/2 ist standardmäßig aktiviert. Verbindungen führen ein Fallback auf HTTP/1.1 aus, wenn keine HTTP/2-Verbindung hergestellt wurde. Weitere Informationen zur HTTP/2-Konfiguration mit IIS-Bereitstellungen finden Sie unter HTTP/2 unter IIS.

CORS-Preflightanforderungen

Dieser Abschnitt gilt nur für ASP.NET Core-Apps, die auf das .NET Framework ausgerichtet sind.

Für eine ASP.NET Core-App, die auf das .NET Framework ausgerichtet ist, werden OPTIONS-Anforderungen in IIS standardmäßig nicht an die App übergeben. Informationen dazu, wie Sie die IIS-Handler der App in web.config so konfigurieren, dass OPTIONS-Anforderungen übergeben werden, finden Sie unter Aktivieren ursprungsübergreifender Anforderungen in ASP.NET-Web-API 2: Funktionsweise von CORS.

Bereitstellungsressourcen für IIS-Administratoren

• IIS-Dokumentation
• Erste Schritte mit IIS-Manager in IIS
• .NET Core-Anwendungsbereitstellung
• ASP.NET Core-Modul (ANCM) für IIS
• Verzeichnisstruktur für ASP.NET Core
• IIS-Module mit ASP.NET Core
• Problembehandlung bei ASP.NET Core in Azure App Service und IIS
• Problembehandlung für häufige Fehler bei Azure App Service und IIS mit ASP.NET Core

Zusätzliche Ressourcen

• Veröffentlichen einer ASP.NET Core-App in IIS
• Problembehandlung und Debuggen von ASP.NET Core-Projekten
• Übersicht über ASP.NET Core
• Die offizielle Microsoft IIS-Website
• Bibliothek mit technischem Inhalt zu Windows Server
• HTTP/2 unter IIS
• Transformieren von web.config