Zaawansowana konfiguracja podstawowego modułu ASP.NET i usług IIS

W tym artykule opisano zaawansowane opcje konfiguracji i scenariusze dla modułu podstawowego ASP.NET i usług IIS.

Modyfikowanie rozmiaru stosu

Ma zastosowanie tylko w przypadku korzystania z modelu hostingu w procesie.

Skonfiguruj rozmiar zarządzanego stosu stackSize przy użyciu ustawienia w bajtach w web.config pliku. Domyślny rozmiar to 1 048 576 bajtów (1 MB). Poniższy przykład zmienia rozmiar stosu na 2 MB (2097 152 bajty):

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

Nie zezwalaj na rotację w konfiguracji

To disallowRotationOnConfigChange ustawienie jest przeznaczone dla scenariuszy niebieski/zielony, w których zmiana konfiguracji globalnej nie powinna spowodować ponownego odtworzenia wszystkich lokacji. Gdy ta flaga ma wartość true, tylko zmiany istotne dla samej witryny spowodują jego odtwarzanie. Na przykład odtwarzanie witryny, jeśli jego plik web.config ulegnie zmianie lub coś, co jest istotne dla ścieżki witryny z perspektywy usług IIS. Jednak ogólna zmiana właściwości applicationHost.config nie spowoduje ponownego odtworzenia aplikacji. W poniższym przykładzie to ustawienie ma wartość true:

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

To ustawienie odpowiada interfejsowi API ApplicationPoolRecycling.DisallowRotationOnConfigChange

Zmniejsz prawdopodobieństwo 503 podczas recyklingu aplikacji

Domyślnie występuje jedno sekundowe opóźnienie między powiadomieniem usług IIS o recyklingu lub zamykaniu, a gdy narzędzie ANCM informuje serwer zarządzany o zainicjowaniu zamknięcia. Opóźnienie można skonfigurować za pomocą zmiennej środowiskowej ANCM_shutdownDelay lub przez ustawienie shutdownDelay ustawienia programu obsługi. Obie wartości znajdują się w milisekundach. Opóźnienie polega przede wszystkim na zmniejszeniu prawdopodobieństwa wyścigu, w którym:

• Usługi IIS nie uruchomiły kolejkowania żądań, aby przejść do nowej aplikacji.
• Usługa ANCM rozpoczyna odrzucanie nowych żądań, które wchodzą do starej aplikacji.

To ustawienie nie oznacza, że żądania przychodzące zostaną opóźnione o tę kwotę. Ustawienie wskazuje, że stare wystąpienie aplikacji rozpocznie zamykanie po upływie limitu czasu. Wolniejsze maszyny lub maszyny z większym użyciem procesora CPU mogą wymagać dostosowania tej wartości, aby zmniejszyć prawdopodobieństwo 503.

Poniższy przykład ustawia opóźnienie na 5 sekund:

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

Konfiguracja serwera proxy używa protokołu HTTP i tokenu parowania

Dotyczy tylko hostingu poza procesem.

Serwer proxy utworzony między modułem ASP.NET Core i Kestrel używa protokołu HTTP. Nie ma ryzyka podsłuchiwania ruchu między modułem a Kestrel lokalizacją poza serwerem.

Token parowania służy do zagwarantowania, że żądania odebrane przez Kestrel usługę IIS były proxied przez usługi IIS i nie pochodziły z innego źródła. Token parowania jest tworzony i ustawiany w zmiennej środowiskowej (ASPNETCORE_TOKEN) przez moduł. Token parowania jest również ustawiany na nagłówek (MS-ASPNETCORE-TOKEN) dla każdego żądania proxied. Oprogramowanie pośredniczące USŁUG IIS sprawdza każde odebrane żądanie, aby potwierdzić, że wartość nagłówka tokenu parowania jest zgodna z wartością zmiennej środowiskowej. Jeśli wartości tokenu są niezgodne, żądanie jest rejestrowane i odrzucane. Zmienna środowiskowa tokenu parowania i ruch między modułem i Kestrel nie są dostępne z lokalizacji poza serwerem. Bez znajomości wartości tokenu parowania cyberatak nie może przesyłać żądań, które pomijają ewidencjonowanie oprogramowania pośredniczącego usług IIS.

ASP.NET Core Module z konfiguracją udostępnioną usług IIS

Instalator ASP.NET Core Module jest uruchamiany z uprawnieniami TrustedInstaller konta. Ponieważ lokalne konto systemowe nie ma uprawnień do modyfikowania ścieżki udziału używanej przez konfigurację udostępnioną usług IIS, instalator zgłasza błąd odmowy dostępu podczas próby skonfigurowania ustawień modułu w pliku w applicationHost.config udziale.

W przypadku korzystania z konfiguracji udostępnionej usług IIS na tej samej maszynie co instalacja usług IIS uruchom instalator pakietu hostingu podstawowego ASP.NET z parametrem ustawionym OPT_NO_SHARED_CONFIG_CHECK na 1:

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

Jeśli ścieżka do konfiguracji udostępnionej nie znajduje się na tej samej maszynie co instalacja usług IIS, wykonaj następujące kroki:

1. Wyłącz konfigurację udostępnioną usług IIS.
2. Uruchom instalatora.
3. Wyeksportuj zaktualizowany applicationHost.config plik do udziału plików.
4. Ponownie włącz konfigurację udostępnioną usług IIS.

Ochrona danych

Stos ochrony danych ASP.NET Core jest używany przez kilka jednostek oprogramowania pośredniczącego ASP.NET Core, a w tym oprogramowanie pośredniczące używane podczas uwierzytelniania. Nawet jeśli interfejsy API ochrony danych nie są wywoływane przez kod użytkownika, należy skonfigurować ochronę danych za pomocą skryptu wdrażania lub w kodzie użytkownika w celu utworzenia trwałego magazynu kluczy kryptograficznych. Jeśli ochrona danych nie jest skonfigurowana, klucze są przechowywane w pamięci i odrzucane po ponownym uruchomieniu aplikacji.

Jeśli pierścień klucza ochrony danych jest przechowywany w pamięci po ponownym uruchomieniu aplikacji:

• Wszystkie tokeny uwierzytelniania oparte na systemie cookie są unieważniane.
• Użytkownicy są zobowiązani do ponownego zalogowania się podczas następnego żądania.
• Nie można już odszyfrować żadnych danych chronionych za pomocą pierścienia kluczy. Może to obejmować tokeny CSRF i pliki cookie ASP.NET Core MVC TempData.

Aby skonfigurować ochronę danych w ramach usług IIS w celu utrwalenia pierścienia kluczy, użyj jednej z następujących metod:

• Tworzenie kluczy rejestru ochrony danych

  Klucze ochrony danych używane przez aplikacje ASP.NET Core są przechowywane w rejestrze zewnętrznym dla aplikacji. Aby utrwały klucze dla danej aplikacji, utwórz klucze rejestru dla puli aplikacji.

  W przypadku instalacji autonomicznych usług IIS innych niż farma internetowa można użyć skryptu ochrony danych Provision-AutoGenKeys.ps1 programu PowerShell dla każdej puli aplikacji używanej z aplikacją ASP.NET Core. Ten skrypt tworzy klucz rejestru w rejestrze HKLM dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane przy rest użyciu interfejsu DPAPI z kluczem całego komputera.

  W scenariuszach farmy internetowej aplikację można skonfigurować tak, aby używała ścieżki UNC do przechowywania pierścienia kluczy ochrony danych. Domyślnie klucze nie są szyfrowane. Upewnij się, że uprawnienia do plików udziału sieciowego są ograniczone do konta systemu Windows, w ramach którego działa aplikacja. Certyfikat X509 może służyć do ochrony kluczy pod adresem rest. Rozważ mechanizm zezwalania użytkownikom na przekazywanie certyfikatów. Umieść certyfikaty w magazynie zaufanych certyfikatów użytkownika i upewnij się, że są one dostępne na wszystkich komputerach, na których działa aplikacja użytkownika. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core Data Protection.

• Konfigurowanie puli aplikacji usług IIS w celu załadowania profilu użytkownika

  To ustawienie znajduje się w sekcji Model procesu w obszarze Ustawienia zaawansowane dla puli aplikacji. Ustaw opcję Załaduj profil użytkownika na wartość True. Po ustawieniu wartości True klucze są przechowywane w katalogu profilu użytkownika i chronione przy użyciu interfejsu API ochrony danych z kluczem specyficznym dla konta użytkownika. Klucze są utrwalane w folderze %LOCALAPPDATA%/ASP.NET/DataProtection-Keys .

  Atrybut puli setProfileEnvironment aplikacji musi być również włączony. Wartość domyślna setProfileEnvironment to true. W niektórych scenariuszach (na przykład systemu operacyjnego Windows) opcja setProfileEnvironment jest ustawiona na wartość false. Jeśli klucze nie są przechowywane w katalogu profilu użytkownika zgodnie z oczekiwaniami:

  1. Przejdź do folderu %windir%/system32/inetsrv/config.
  2. Otwórz plik applicationHost.config.
  3. Znajdź element <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Upewnij się, że atrybut setProfileEnvironment nie występuje, co powoduje, że wartość domyślnie staje się równa true, lub jawnie ustaw wartość atrybutu na true.

• Używanie systemu plików jako magazynu pierścienia kluczy

  Dostosuj kod aplikacji, aby używać systemu plików jako magazynu pierścienia kluczy. Użyj certyfikatu X509, aby chronić pierścień kluczy i upewnić się, że certyfikat jest zaufanym certyfikatem. Jeśli certyfikat ma podpis własny, umieść certyfikat w zaufanym magazynie głównym.

  W przypadku korzystania z usług IIS w farmie internetowej:

  • Użyj udziału plików, do którego mogą uzyskiwać dostęp wszystkie maszyny.
  • Wdróż certyfikat X509 na każdej maszynie. Konfigurowanie ochrony danych w kodzie.

• Ustawianie zasad dla całej maszyny na potrzeby ochrony danych

  System ochrony danych ma ograniczoną obsługę ustawiania domyślnych zasad dla wszystkich aplikacji korzystających z interfejsów API ochrony danych. Aby uzyskać więcej informacji, zobacz Omówienie ochrony danych ASP.NET Core.

Konfiguracja usług IIS

Systemy operacyjne Windows Server

Włącz rolę serwera Web Server (IIS) i ustal usługi ról.

1. Użyj kreatora Dodawanie ról i funkcji z menu Zarządzanie lub linku w Menedżer serwera. W kroku Role serwera zaznacz pole wyboru Web Server (IIS).

   

2. Po kroku Funkcje krok Usługi ról ładuje się dla serwera Web Server (IIS). Wybierz żądane usługi ról lub zaakceptuj udostępnione domyślne usługi ról usług IIS.

   

   Uwierzytelnianie systemu Windows (opcjonalne)
   Aby włączyć uwierzytelnianie systemu Windows, rozwiń następujące węzły:Web Server>Zabezpieczenia. Wybierz funkcję Uwierzytelnianie systemu Windows. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie systemu Windows<windowsAuthentication> i Konfigurowanie uwierzytelniania systemu Windows.

   WebSockets (opcjonalnie)
   Obiekty WebSockets są obsługiwane za pomocą programu ASP.NET Core 1.1 lub nowszego. Aby włączyć obiekty WebSockets, rozwiń następujące węzły:Web Server>Tworzenie aplikacji. Wybierz funkcję Protokół WebSocket. Aby uzyskać więcej informacji, zobacz WebSockets.

3. Przejdź do kroku Potwierdzenie, aby zainstalować rolę i usługi serwera internetowego. Ponowne uruchomienie serwera/usług IIS nie jest wymagane po zainstalowaniu roli Web Server (IIS).

Komputerowe systemy operacyjne Windows

Włącz konsolę zarządzania usługami IIS i usługi internetowe.

1. Przejdź do pozycji Panel sterowania>Programy>Programy i funkcje>Włącz lub wyłącz funkcje systemu Windows (po lewej stronie ekranu).

2. Otwórz węzeł Internet Information Services. Otwórz węzeł Internetowe narzędzia zarządzania.

3. Zaznacz pole wyboru konsoli zarządzania usługami IIS.

4. Zaznacz pole wyboru Usługi internetowe.

5. Zaakceptuj domyślne funkcje usług internetowych lub dostosuj funkcje usług IIS.

   Uwierzytelnianie systemu Windows (opcjonalne)
   Aby włączyć uwierzytelnianie systemu Windows, rozwiń następujące węzły:Usługi internetowe>Zabezpieczenia. Wybierz funkcję Uwierzytelnianie systemu Windows. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie systemu Windows<windowsAuthentication> i Konfigurowanie uwierzytelniania systemu Windows.

   WebSockets (opcjonalnie)
   Obiekty WebSockets są obsługiwane za pomocą programu ASP.NET Core 1.1 lub nowszego. Aby włączyć obiekty WebSockets, rozwiń następujące węzły:Usługi internetowe>Funkcje programowania aplikacji. Wybierz funkcję Protokół WebSocket. Aby uzyskać więcej informacji, zobacz WebSockets.

6. Jeśli instalacja usług IIS wymaga ponownego uruchomienia, uruchom ponownie system.

Katalogi wirtualne

Katalogi wirtualne usług IIS nie są obsługiwane w przypadku aplikacji ASP.NET Core. Aplikację można hostować jako aplikację podrzędną.

Aplikacje podrzędne

Aplikację ASP.NET Core można hostować jako aplikację podrzędną usług IIS (podaplikację). Ścieżka aplikacji podrzędnej staje się częścią adresu URL aplikacji głównej.

Statyczne linki zasobów w podaplikacji powinny używać notacji tyldy-ukośnika (~/) w wzorcach MVC i Razor Pages. Notacja tylda-ukośnik wyzwala pomocnika tagów w celu wstępnego dołączania bazy ścieżek aplikacji podrzędnej do renderowanego linku względnego. W przypadku aplikacji podrzędnej w lokalizacji /subapp_pathobraz połączony z elementem src="~/image.png" jest renderowany jako src="/subapp_path/image.png". Statyczne oprogramowanie pośredniczące pliku aplikacji głównej nie przetwarza statycznego żądania pliku. Żądanie jest przetwarzane przez statyczne oprogramowanie pośredniczące pliku aplikacji podrzędnej.

Uwaga

Razor składniki (.razor) nie powinny używać notacji tyldy-ukośnika. Aby uzyskać więcej informacji, zobacz dokumentację Blazorścieżki podstawowej aplikacji.

Jeśli atrybut statycznego zasobu src jest ustawiony na ścieżkę bezwzględną (na przykład src="/image.png"), link jest renderowany bez bazy ścieżki aplikacji podrzędnej. Statyczne oprogramowanie pośredniczące pliku aplikacji głównej próbuje obsłużyć zasób z katalogu głównego aplikacji głównej, co powoduje odpowiedź 404 — Nie znaleziono, chyba że statyczny zasób jest dostępny z poziomu aplikacji głównej.

Aby hostować aplikację ASP.NET Core jako aplikację podrzędną w innej aplikacji ASP.NET Core:

1. Ustanów pulę aplikacji dla aplikacji podrzędnej. Ustaw wersję środowiska CLR platformy .NET na wartość Brak kodu zarządzanego, ponieważ środowisko uruchomieniowe Core Common Language Runtime (CoreCLR) dla platformy .NET Core jest uruchamiane w celu hostowania aplikacji w procesie roboczym, a nie środowiska CLR pulpitu (.NET CLR).

2. Dodaj witrynę główną w Menedżerze usług IIS za pomocą aplikacji podrzędnej w folderze w witrynie głównej.

3. Kliknij prawym przyciskiem myszy folder aplikacji podrzędnej w Menedżerze usług IIS i wybierz polecenie Konwertuj na aplikację.

4. W oknie dialogowym Dodawanie aplikacji użyj przycisku Wybierz dla puli aplikacji, aby przypisać pulę aplikacji utworzoną dla aplikacji podrzędnej. Wybierz przycisk OK.

Przypisanie oddzielnej puli aplikacji do aplikacji podrzędnej jest wymagane w przypadku korzystania z modelu hostingu wewnątrz procesu.

Aby uzyskać więcej informacji na temat modelu hostingu wewnątrz procesu i konfigurowania modułu ASP.NET Core Module, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.

Pule aplikacji

Izolacja puli aplikacji jest określana przez model hostingu:

• Hosting wewnątrz procesu: aplikacje muszą działać w oddzielnych pulach aplikacji.
• Hosting poza procesem: zalecamy izolowanie aplikacji od siebie przez uruchomienie każdej aplikacji we własnej puli aplikacji.

Okno dialogowe usług IIS Dodawanie witryny internetowej domyślnie jest ustawione na jedną pulę aplikacji na aplikację. Po podaniu nazwy witryny tekst jest automatycznie przesyłany do pola tekstowego Pula aplikacji. Nowa pula aplikacji jest tworzona przy użyciu nazwy witryny po dodaniu witryny.

Pula aplikacji Identity

Konto puli identity aplikacji umożliwia uruchamianie aplikacji na unikatowym koncie bez konieczności tworzenia domen lub kont lokalnych oraz zarządzania nimi. W usługach IIS w wersji 8.0 lub nowszej Proces roboczy Administratora usług IIS (WAS) tworzy konto wirtualne o nazwie nowej puli aplikacji i domyślnie uruchamia procesy robocze puli aplikacji w ramach tego konta. W konsoli zarządzania usługami IIS w obszarze Ustawienia zaawansowane dla puli aplikacji upewnij się, że Identity parametr jest ustawiony na wartość ApplicationPoolIdentity:

Proces zarządzania usługami IIS tworzy bezpieczny identyfikator z nazwą puli aplikacji w zabezpieczeniach systemu Windows. Zasoby można zabezpieczyć przy użyciu tego elementu identity. Nie jest to identity jednak prawdziwe konto użytkownika i nie jest wyświetlane w konsoli zarządzania użytkownikami systemu Windows.

Jeśli proces roboczy usług IIS wymaga podwyższonego poziomu dostępu do aplikacji, zmodyfikuj listę kontroli dostępu (ACL) dla katalogu zawierającego aplikację:

1. Otwórz Eksploratora Windows i przejdź do katalogu.

2. Kliknij prawym przyciskiem myszy katalog i wybierz pozycję Właściwości.

3. Na karcie Zabezpieczenia wybierz przycisk Edytuj, a następnie przycisk Dodaj.

4. Wybierz przycisk Lokalizacje i upewnij się, że system jest wybrany.

5. Wprowadź IIS AppPool\{APP POOL NAME} format, w którym symbol zastępczy {APP POOL NAME} to nazwa puli aplikacji, w polu Wprowadź nazwy obiektów do wybrania obszaru. Wybierz przycisk Sprawdź nazwy. W przypadku puli DefaultAppPool sprawdź nazwy przy użyciu polecenia IIS AppPool\DefaultAppPool. Po wybraniu przycisku Sprawdź nazwy wartość DefaultAppPool jest wskazywana w obszarze nazw obiektów. Nie można wprowadzić nazwy puli aplikacji bezpośrednio w obszarze nazw obiektów. Użyj formatu IIS AppPool\{APP POOL NAME}, w którym symbol zastępczy {APP POOL NAME} jest nazwą puli aplikacji, podczas sprawdzania nazwy obiektu.

   

6. Wybierz przycisk OK.

   

7. Uprawnienia do odczytu i wykonywania powinny być domyślnie przyznawane. Podaj dodatkowe uprawnienia zgodnie z potrzebami.

Dostępu można również udzielić w wierszu polecenia przy użyciu narzędzia ICACLS. Na przykład przy użyciu puli DefaultAppPool następujące polecenie służy do udzielania uprawnień MyWebApp do odczytu i wykonywania do folderu, podfolderów i plików:

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

Aby uzyskać więcej informacji, zobacz temat icacls.

Obsługa protokołu HTTP/2

Protokół HTTP/2 jest obsługiwany w przypadku ASP.NET Core w następujących scenariuszach wdrażania usług IIS:

• Proces
  • Windows Server 2016/Windows 10 lub nowszy; usługi IIS 10 lub nowsze
  • Połączenie TLS 1.2 lub nowsze
• Poza procesem
  • Windows Server 2016/Windows 10 lub nowszy; usługi IIS 10 lub nowsze
  • Publiczne połączenia serwera brzegowego używają protokołu HTTP/2, ale odwrotne połączenie serwera proxy z serwerem Kestrel korzysta z protokołu HTTP/1.1.
  • Połączenie TLS 1.2 lub nowsze

W przypadku wdrożenia wewnątrz procesu po nawiązaniu połączenia HTTP/2 HttpRequest.Protocol zgłasza HTTP/2. W przypadku wdrożenia poza procesem podczas nawiązywania połączenia HTTP/2 HttpRequest.Protocol zgłasza HTTP/1.1.

Aby uzyskać więcej informacji na temat modeli hostingu wewnątrz procesu i poza procesem, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.

Protokół HTTP/2 jest domyślnie włączony. Połączenia wracają do używania protokołu HTTP/1.1, jeśli połączenie HTTP/2 nie zostało nawiązane. Aby uzyskać więcej informacji na temat konfiguracji protokołu HTTP/2 z wdrożeniami usług IIS, zobacz HTTP/2 w usługach IIS.

Żądania wstępne CORS

Ta sekcja dotyczy tylko aplikacji ASP.NET Core przeznaczonych dla platformy .NET Framework.

W przypadku aplikacji ASP.NET Core przeznaczonej dla platformy .NET Framework żądania OPTIONS nie są domyślnie przekazywane do aplikacji w usługach IIS. Aby dowiedzieć się, jak skonfigurować procedury obsługi usług IIS aplikacji w web.config w celu przekazywania żądań OPTIONS, zobacz Włączanie żądań między źródłami w internetowym interfejsie API ASP.NET 2: Jak działa mechanizm CORS.

Moduł inicjowania aplikacji i limit czasu bezczynności

W przypadku hostowanych w usługach IIS przez moduł ASP.NET Core Module w wersji 2:

• Moduł inicjowania aplikacji: aplikację hostowaną wewnątrz procesu lub poza procesem można skonfigurować tak, aby uruchamiała się automatycznie po ponownym uruchomieniu procesu roboczego lub ponownym uruchomieniu serwera.
• Limit czasu bezczynności: hostowana w procesie aplikacja może nie być ustawiona tak, aby upłynął limit czasu w okresach braku aktywności.

Moduł inicjowania aplikacji

Dotyczy aplikacji hostowanych wewnątrz procesu i poza procesem.

Inicjowanie aplikacji usług IIS to funkcja usług IIS, która wysyła żądanie HTTP do aplikacji po uruchomieniu lub przetworzeniu puli aplikacji. Żądanie wyzwala uruchomienie aplikacji. Domyślnie usługi IIS wysyłają żądanie do głównego adresu URL aplikacji (/), aby zainicjować aplikację (zobacz dodatkowe zasoby, aby uzyskać więcej informacji na temat konfiguracji).

Upewnij się, że funkcja roli inicjowania aplikacji usług IIS jest włączona:

W systemach komputerowych z systemem Windows 7 lub nowszym w przypadku korzystania z usług IIS lokalnie:

1. Przejdź do pozycji Panel sterowania>Programy>Programy i funkcje>Włącz lub wyłącz funkcje systemu Windows (po lewej stronie ekranu).
2. Otwórz pozycję Internet Information Services>Usługi internetowe>Funkcje tworzenia aplikacji.
3. Zaznacz pole wyboru Inicjowanie aplikacji.

W systemie Windows Server 2008 R2 lub nowszym:

1. Otwórz Kreatora dodawania ról i funkcji.
2. W panelu Wybieranie usług ról otwórz węzeł Tworzenie aplikacji.
3. Zaznacz pole wyboru Inicjowanie aplikacji.

Użyj jednej z następujących metod, aby włączyć moduł inicjowania aplikacji dla witryny:

• Za pomocą Menedżera usług IIS:

  1. Wybierz pozycję Pule aplikacji w panelu Połączenia.
  2. Kliknij prawym przyciskiem myszy pulę aplikacji na liście i wybierz pozycję Ustawienia zaawansowane.
  3. Domyślnym trybem uruchamiania jest OnDemand. Ustaw tryb uruchamiania na AlwaysRunning. Wybierz przycisk OK.
  4. Otwórz węzeł Witryny w panelu Połączenia.
  5. Kliknij prawym przyciskiem myszy aplikację i wybierz pozycję Zarządzanie witrynami>Ustawienia zaawansowane.
  6. Domyślne ustawienie Włączone wstępne ładowanie to False. Ustaw wartość Włączone wstępne ładowanie na True. Wybierz przycisk OK.

• Za pomocą polecenia web.configdodaj <applicationInitialization> element z doAppInitAfterRestart ustawioną wartością do true <system.webServer> elementów w pliku aplikacji web.config :

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

Limit czasu bezczynności

Dotyczy tylko aplikacji hostowanych wewnątrz procesu.

Aby zapobiec bezczynności aplikacji, ustaw limit czasu bezczynności puli aplikacji przy użyciu Menedżera usług IIS:

1. Wybierz pozycję Pule aplikacji w panelu Połączenia.
2. Kliknij prawym przyciskiem myszy pulę aplikacji na liście i wybierz pozycję Ustawienia zaawansowane.
3. Domyślny limit czasu bezczynności (w minutach) to 20 minuty. Ustaw limit czasu bezczynności (w minutach) na 0 (zero). Wybierz przycisk OK.
4. Odzyskaj proces roboczy.

Aby zapobiec przekroczeniu limitu czasu przez aplikacje hostowane poza procesem, użyj jednej z następujących metod:

• Wyślij polecenie ping do aplikacji z usługi zewnętrznej, aby podtrzymać jej działanie.
• Jeśli aplikacja hostuje tylko usługi w tle, należy unikać hostowania usług IIS i użyć usługi systemu Windows do hostowania aplikacji ASP.NET Core.

Moduł inicjowania aplikacji i dodatkowe zasoby z limitem czasu bezczynności

• Inicjowanie aplikacji usług IIS 8.0
• Inicjowanie <applicationInitialization>aplikacji .
• Ustawienia modelu przetwarzania dla puli <processModel>aplikacji.

Lokalizacje plików modułu, schematu i konfiguracji

Moduł

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

Schemat

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

Konfigurowanie

IIS

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

IIS Express

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

• interfejs wiersza polecenia iisexpress.exe:%USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Pliki można znaleźć, wyszukując aspnetcore applicationHost.config w pliku.

Instalowanie narzędzia Web Deploy podczas publikowania za pomocą programu Visual Studio

Podczas wdrażania aplikacji na serwerach za pomocą narzędzia Web Deploy zainstaluj najnowszą wersję narzędzia Web Deploy na serwerze. Aby zainstalować narzędzie Web Deploy, zobacz Pliki do pobrania usług IIS: Web Deploy.

Tworzenie witryny usług IIS

1. W systemie hostingu utwórz folder na opublikowane foldery i pliki aplikacji. W następnym kroku ścieżka folderu jest udostępniana usługom IIS jako ścieżka fizyczna do aplikacji. Aby uzyskać więcej informacji na temat folderu wdrażania i układu pliku aplikacji, zobacz Struktura katalogów ASP.NET Core.

2. W Menedżerze usług IIS otwórz węzeł serwera w panelu Połączenia. Kliknij prawym przyciskiem myszy folder Witryny. Wybierz pozycję Dodaj witrynę internetową z menu kontekstowego.

3. Podaj nazwę witryny i ustaw ścieżkę fizyczną do folderu wdrożenia aplikacji. Podaj konfigurację powiązania i utwórz witrynę internetową, wybierając przycisk OK:

   

   Ostrzeżenie

   Nie należy używać powiązań z symbolami wieloznacznymi najwyższego poziomu (http://*:80/ i http://+:80). Powiązania z symbolami wieloznacznymi najwyższego poziomu mogą otworzyć aplikację na luki w zabezpieczeniach. Dotyczy to zarówno silnych, jak i słabych symboli wieloznacznych. Użyj raczej jawnych nazw hostów, a nie symboli wieloznacznych. Powiązanie wieloznaczne poddomeny (na przykład *.mysub.com) nie niesie ze sobą takiego ryzyka dla zabezpieczeń, jeśli kontrolujesz całą domenę nadrzędną (w przeciwieństwie do *.com, która jest podatna na zagrożenia). Aby uzyskać więcej informacji, zobacz RFC 9110: Semantyka HTTP (sekcja 7.2: Host i :authority).

4. W węźle serwera wybierz pozycję Pule aplikacji.

5. Kliknij prawym przyciskiem myszy pulę aplikacji witryny i wybierz pozycję Ustawienia podstawowe z menu kontekstowego.

6. W oknie Edytowanie puli aplikacji ustaw wersję środowiska CLR platformy .NET na wartość Brak kodu zarządzanego:

   

   ASP.NET Core działa w osobnym procesie i zarządza środowiskiem uruchomieniowym. ASP.NET Core nie polega na ładowaniu pulpitu CLR (.NET CLR). Podstawowy aparat plików wykonywalnych języka wspólnego (CoreCLR) dla platformy .NET Core jest uruchamiany w celu hostowania aplikacji w procesie roboczym. Ustawienie wersji środowiska .NET CLR na wartość Brak kodu zarządzanego jest opcjonalne, ale zalecane.

   • W przypadku 32-bitowego (x86) samodzielnego wdrożenia opublikowanego przy użyciu 32-bitowego zestawu SDK korzystającego z modelu hostingu w procesie włącz pulę aplikacji dla 32-bitowej wersji. W Menedżerze usług IIS przejdź do pozycji Pule aplikacji na pasku bocznym Połączenia. Wybierz pulę aplikacji. Na pasku bocznym Akcje wybierz pozycję Ustawienia zaawansowane. Ustaw opcję Włącz aplikacje 32-bitowe na wartość True.

   • W przypadku 64-bitowego (x64) samodzielnego wdrożenia korzystającego z modelu hostingu w procesie wyłącz pulę aplikacji dla procesów 32-bitowych (x86). W Menedżerze usług IIS przejdź do pozycji Pule aplikacji na pasku bocznym Połączenia. Wybierz pulę aplikacji. Na pasku bocznym Akcje wybierz pozycję Ustawienia zaawansowane. Ustaw opcję Włącz aplikacje 32-bitowe na wartość False.

7. Upewnij się, że model identity przetwarzania ma odpowiednie uprawnienia.

   Jeśli wartość domyślna identity puli aplikacji (modelIdentity> przetwarzania) zostanie zmieniona z ApplicationPoolIdentity na innąidentity, sprawdź, czy nowe identity ma wymagane uprawnienia dostępu do folderu, bazy danych i innych wymaganych zasobów aplikacji. Na przykład pula aplikacji wymaga dostępu do odczytu i zapisu do folderów, w których aplikacja odczytuje i zapisuje pliki.

Konfiguracja uwierzytelniania systemu Windows (opcjonalnie)
Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania systemu Windows.

Kopia w tle

Zestawy aplikacji kopiujących w tle do ASP.NET Core Module (ANCM) dla usług IIS mogą zapewnić lepsze środowisko użytkownika końcowego niż zatrzymywanie aplikacji przez wdrożenie pliku w trybie offline aplikacji.

Gdy aplikacja ASP.NET Core jest uruchomiona w systemie Windows, pliki binarne są zablokowane, aby nie można było ich modyfikować ani zastępować. Kopiowanie w tle umożliwia aktualizowanie zestawów aplikacji podczas działania aplikacji przez utworzenie kopii zestawów.

Kopiowanie w tle nie jest przeznaczone do włączenia wdrożenia bez przestojów, dlatego oczekuje się, że usługi IIS będą nadal odtwarzać aplikację, a niektóre żądania mogą otrzymać odpowiedź 503 Usługa niedostępna . Zalecamy użycie wzorca, takiego jak wdrożenia niebieski-zielony lub miejsca wdrożenia platformy Azure w przypadku wdrożeń bez przestojów. Kopiowanie w tle pomaga zminimalizować przestoje wdrożeń, ale nie może całkowicie go wyeliminować.

Kopiowanie w tle jest włączone przez dostosowanie ustawień programu obsługi ANCM w programie web.config:

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