Erweiterte Konfiguration des ASP.NET Core-Moduls und der IIS

In diesem Artikel geht es um erweiterte Konfigurationsoptionen und entsprechende Szenarios für das ASP.NET Core-Modul und die IIS.

Ändern der Stapelgröße

Gilt nur bei Verwendung des In-Process-Hostingmodells.

Konfigurieren Sie die Größe des verwalteten Stapels mithilfe der stackSize-Einstellung in Byte in der web.config-Datei. Die Standardgröße beträgt 1.048.576 Byte (1 MB). Im folgenden Beispiel wird die Stapelgröße in 2 MB (2.097.152 Byte) geändert:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

Drehung in der Konfiguration nicht zulassen

Die disallowRotationOnConfigChange-Einstellung ist für Blau/Grün-Szenarios vorgesehen, in denen eine Änderung an der globalen Konfiguration nicht dazu führen sollte, dass alle Websites wiederverwendet werden. Wenn dieses Flag TRUE ist, führen nur Änderungen, die für die Website selbst relevant sind, dazu, dass sie wiederverwendet wird. Beispielsweise wird eine Website wiederverwendet, wenn sich ihre web.config ändert oder sich etwas ändert, das aus IIS-Sicht für den Pfad der Website relevant ist. Eine allgemeine Änderung anapplicationHost.config würde jedoch nicht dazu führen, dass eine App wiederverwendet wird. Im folgenden Beispiel wird diese Einstellung auf TRUE festgelegt:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

Diese Einstellung entspricht der API ApplicationPoolRecycling.DisallowRotationOnConfigChange.

Verringern der Wahrscheinlichkeit 503 während des App-Wiederverwendungsvorgangs

Standardmäßig gibt es eine Verzögerung von einer Sekunde, wenn IIS über eine Wiederverwendung oder ein Herunterfahren benachrichtigt wird und wenn ANCM den verwalteten Server anweist, das Herunterfahren zu initiieren. Die Verzögerung kann über die Umgebungsvariable ANCM_shutdownDelay oder durch Festlegen der Handlereinstellung shutdownDelay konfiguriert werden. Beide Werte sind in Millisekunden. Die Verzögerung soll in erster Linie die Wahrscheinlichkeit eines Wettrennens verringern, bei dem:

• IIS keine Warteschlangenanforderungen gestartet hat, um zur neuen App zu wechseln.
• ANCM mit der Ablehnung neuer Anforderungen beginnt, die in die alte App gelangen.

Diese Einstellung bedeutet nicht, dass eingehende Anforderungen um diesen Wert verzögert werden. Die Einstellung gibt an, dass die alte App-Instanz nach dem Timeout heruntergefahren wird. Für langsamere Computer oder Computer mit höherer CPU-Auslastung muss dieser Wert möglicherweise angepasst werden, um die Wahrscheinlichkeit 503 zu verringern.

Im folgenden Beispiel wird die Verzögerung auf 5 Sekunden festgelegt:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="shutdownDelay" value="5000" />
  </handlerSettings>
</aspNetCore>

Die Proxykonfiguration verwendet das HTTP-Protokoll und ein Paarbildungstoken

Gilt nur für Out-of-Process-Hosting.

Der Proxy, der zwischen dem ASP.NET Core-Modul und Kestrel erstellt wurde, verwendet das HTTP-Protokoll. Es gibt kein Risiko für Lauschangriffe auf den Datenverkehr zwischen dem Modul und Kestrel von einem Speicherort außerhalb des Servers.

Ein Paarbildungstoken wird verwendet, um sicherzustellen, dass die von Kestrel empfangenen Anfragen von IIS über einen Proxy gesendet wurden und nicht von einer anderen Quelle stammen. Das Paarbildungstoken wurde durch das Modul erstellt und in einer Umgebungsvariablen (ASPNETCORE_TOKEN) festgelegt. Das Paarbildungstoken ist auch bei jeder Proxyanforderung in einem Header (MS-ASPNETCORE-TOKEN) festgelegt. IIS-Middleware überprüft jede erhaltene Anforderung, um sicherzustellen, dass der Headerwert des Paarbildungstokens dem Wert der Umgebungsvariablen entspricht. Wenn die Tokenwerte nicht übereinstimmen, wird die Anforderung protokolliert und abgelehnt. Es kann nicht von einem Speicherort außerhalb des Servers auf die Umgebungsvariablen des Paarbildungstokens und den Datenverkehr zwischen dem Modul und Kestrel zugegriffen werden. Wenn Cyberkriminelle den Wert des Paarbildungstokens nicht kennen, können sie keine Anforderungen einreichen, die die IIS-Middleware-Prüfung umgehen.

ASP.NET Core-Modul mit einer IIS-Freigabekonfiguration

Das Installationsprogramm des ASP.NET Core-Moduls wird mit den Berechtigungen des TrustedInstaller-Kontos ausgeführt. Da das lokale Systemkonto keine Berechtigung zum Ändern für den von der IIS-Freigabekonfiguration verwendeten Freigabepfad hat, stößt der Installer beim Versuch, die Moduleinstellungen in der applicationHost.config-Datei auf der Freigabe zu konfigurieren, auf einen „Zugriff verweigert“-Fehler.

Wenn eine ISS-Freigabekonfiguration auf demselben Computer verwendet wird wie die ISS-Installation, führen Sie das Installationsprogramm des ASP.NET -Core-Hosting-Pakets mit auf 1 festgelegtem Parameter OPT_NO_SHARED_CONFIG_CHECK aus:

dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1

Wenn sich der Pfad zur freigegebenen Konfiguration nicht auf demselben Computer wie die ISS-Installation befindet, befolgen Sie die folgenden Schritte:

1. Deaktivieren Sie die IIS-Freigabekonfiguration.
2. Führen Sie den Installer aus.
3. Exportieren Sie die aktualisierte applicationHost.config-Datei in die Dateifreigabe.
4. Aktivieren Sie die IIS-Freigabekonfiguration erneut.

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 die Schlüsselsammlung für den Datenschutz 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 von Registrierungsschlüsseln 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. Sie müssen Registrierungsschlüssel für den App-Pool erstellen, um die Schlüssel für eine bestimmte App dauerhaft zu speichern.

  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 die Schlüsselsammlung für den Schutz von Daten zu speichern. Standardmäßig werden die Schlüssel 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. Weitere Informationen 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.

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.

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 Ressourcenlinks in der untergeordneten App sollten die Tilde-Schrägstrich-Notation (~/) in MVC und Razor Pages 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.

Hinweis

Razor-Komponenten (.razor) sollten keine Tilde-Schrägstrich-Notation verwenden. Weitere Informationen finden Sie in der BlazorDokumentation zum Basispfad einer App.

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.

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 Option Identity 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 IIS AppPool\{APP POOL NAME} das IIS AppPool\{APP POOL NAME}-Format ein. Hierbei steht der Platzhalter {APP POOL NAME} für den Namen des App-Pools. 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. Unter Verwendung von DefaultAppPool als Beispiel wird der folgende Befehl ausgeführt, um dem Ordner MyWebApp, den Unterordnern und den Dateien Lese- und Ausführungsberechtigungen zu erteilen:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

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 lautet 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 lautet False. Legen Sie Vorabladen aktiviert auf True fest. Klicken Sie auf OK.

• Fügen Sie mithilfe von web.config das <applicationInitialization>-Element, für das doAppInitAfterRestart auf true festgelegt ist, den <system.webServer>-Elementen in der web.config-Datei der App hinzu:

  <?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) beträgt 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>.

Dateispeicherorte für Modul, Schema und Konfiguration

Modul

IIS (x86/amd64):

• %windir%\System32\inetsrv\aspnetcore.dll

• %windir%\SysWOW64\inetsrv\aspnetcore.dll

• %ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

• %ProgramFiles(x86)%\IIS Express\aspnetcore.dll

• %ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

Schema

IIS

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml

IIS Express

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml

Konfiguration

IIS

• %windir%\System32\inetsrv\config\applicationHost.config

IIS Express

• Visual Studio: {APPLICATION ROOT}\.vs\config\applicationHost.config

• iisexpress.exe CLI: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Den Speicherort dieser Dateien finden Sie, indem Sie aspnetcore in der Datei applicationHost.config suchen.

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. Informationen zum Installieren von Web Deploy finden Sie unter IIS-Downloads: Web Deploy.

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.

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

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

Schattenkopie

Schattenkopieren von App-Assemblys in das ASP.NET Core-Modul (ANCM) für IIS kann eine bessere Endbenutzerfreundlichkeit bieten als das Beenden der App durch Bereitstellen einer App-Offlinedatei.

Wenn eine ASP.NET Core-App in Windows ausgeführt wird, werden die Binärdateien gesperrt, damit sie nicht geändert oder ersetzt werden können. Durch das Schattenkopieren können die App-Assemblys aktualisiert werden, während die App ausgeführt wird, indem eine Kopie der Assemblys erstellt wird.

Schattenkopieren soll keine Bereitstellung ohne Downtime ermöglichen, sodass erwartet wird, dass IIS die App weiterhin neu starten wird, und einige Anforderungen erhalten möglicherweise eine 503 – Dienst nicht verfügbar-Antwort. Wir empfehlen, ein Muster wie die blau-grünen-Bereitstellungen oder Azure-Bereitstellungsslots für Bereitstellungen ohne Downtime zu verwenden. Schattenkopieren minimiert die Downtime bei Bereitstellungen, kann sie jedoch nicht vollständig beseitigen.

Schattenkopieren wird aktiviert, indem Sie die ANCM-Handlereinstellungen in web.config anpassen:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>