Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
Uwaga
Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
Ostrzeżenie
Ta wersja ASP.NET Core nie jest już obsługiwana. Aby uzyskać więcej informacji, zobacz .NET i .NET Core Support Policy (Zasady obsługi platformy .NET Core). Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
Ważne
Te informacje odnoszą się do produktu w wersji wstępnej, który może zostać znacząco zmodyfikowany, zanim zostanie wydany komercyjnie. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.
Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
Usługi Internet Information Services (IIS) to elastyczny, bezpieczny i zarządzalny serwer internetowy do hostowania aplikacji internetowych, a w tym ASP.NET Core.
Obsługiwane platformy
Obsługiwane są następujące systemy operacyjne:
- Windows 7 lub nowszy
- Windows Server 2012 R2 lub nowszy
Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wdróż aplikację 32-bitową za pomocą 32-bitowego zestawu SDK platformy .NET Core (x86), chyba że aplikacja:
- Wymaga większej przestrzeni adresowej pamięci wirtualnej dostępnej dla aplikacji 64-bitowej.
- Wymaga większego rozmiaru stosu usług IIS.
- Ma 64-bitowe zależności natywne.
Instalowanie pakietu modułu ASP.NET Core Module/hostingu
Pobierz najnowszy instalator, korzystając z następującego linku:
Bieżący instalator pakietu hostingowego platformy .NET Core (pobieranie bezpośrednie)
Aby uzyskać więcej szczegółowych informacji na temat sposobu instalowania modułu ASP.NET Core Module lub instalowania różnych wersji, zobacz Instalowanie pakietu hostingu platformy .NET Core.
Aby pobrać poprzednie wersje pakietu hostingu, zobacz ten problem z usługą GitHub.
Rozpocznij
Aby rozpocząć hostowanie witryny internetowej w usługach IIS, zobacz nasz przewodnik wprowadzający.
Aby zapoznać się z wprowadzeniem do hostowania witryny internetowej w usługach Azure App Service, zobacz przewodnik wdrażania w usłudze Azure App Service.
Konfigurowanie
Aby uzyskać wskazówki dotyczące konfiguracji, zobacz Konfiguracja zaawansowana.
Zasoby wdrażania dla administratorów usług IIS
- Dokumentacja usług IIS
- Wprowadzenie za pomocą Menedżera usług IIS w usługach IIS
- Wdrażanie aplikacji platformy .NET Core
- Moduł ASP.NET Core (ANCM) dla usług IIS
- Struktura katalogów platformy ASP.NET Core
- Moduły usług IIS z platformą ASP.NET Core
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
Nakładane odzyskiwanie
Ogólnie rzecz biorąc, zalecamy użycie wzorca, takiego jak wdrożenia niebiesko-zielone w przypadku wdrożeń bez przestojów. Funkcje, takie jak Nakładane odzyskiwanie, pomagają, ale nie gwarantują, że można wykonać wdrożenie bez przestojów. Aby uzyskać więcej informacji, zobacz ten problem w serwisie GitHub.
Opcjonalne certyfikaty klienta
Aby uzyskać informacje na temat aplikacji, które muszą chronić podzbiór aplikacji przy użyciu certyfikatu, zobacz Opcjonalne certyfikaty klienta.
Dodatkowe zasoby
Aby zapoznać się z samouczkiem dotyczącym publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS.
Instalowanie pakietu hostingu platformy .NET Core
Obsługiwane systemy operacyjne
Obsługiwane są następujące systemy operacyjne:
- Windows 7 lub nowszy
- Windows Server 2012 R2 lub nowszy
Serwer HTTP.sys (wcześniej nazywany WebListener) nie działa w konfiguracji odwrotnego serwera proxy z usługami IIS. Użyj serwera Kestrel .
Aby uzyskać informacje na temat hostowania na platformie Azure, zobacz Wdrażanie aplikacji ASP.NET Core w usłudze Azure App Service.
Aby uzyskać wskazówki dotyczące rozwiązywania problemów, zobacz Rozwiązywanie problemów i debugowanie projektów ASP.NET Core.
Obsługiwane platformy
Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wdróż aplikację 32-bitową za pomocą 32-bitowego zestawu SDK platformy .NET Core (x86), chyba że aplikacja:
- Wymaga większej przestrzeni adresowej pamięci wirtualnej dostępnej dla aplikacji 64-bitowej.
- Wymaga większego rozmiaru stosu usług IIS.
- Ma 64-bitowe zależności natywne.
Aplikacje opublikowane dla środowisk 32-bitowych (x86) muszą mieć włączone 32-bitowe pule aplikacji usług IIS. Aby uzyskać więcej informacji, zobacz sekcję Tworzenie witryny usług IIS.
Użyj 64-bitowego zestawu SDK platformy .NET Core (x64), aby opublikować 64-bitową aplikację. W systemie hosta musi znajdować się 64-bitowe środowisko uruchomieniowe.
Modele hostingu
Model hostingu wewnątrz procesu
W przypadku hostingu wewnątrz procesu aplikacja ASP.NET Core jest uruchamiana w tym samym procesie, co powiązany proces roboczy usług IIS. Hosting wewnątrz procesu zapewnia lepszą wydajność niż hosting poza procesem, ponieważ żądania nie są przekazywane za pośrednictwem adaptera sprzężenia zwrotnego, czyli interfejsu sieciowego przekazującego wychodzący ruch sieciowy z powrotem do tej samej maszyny. Usługi IIS obsługują zarządzanie procesami za pomocą usługi aktywacji procesów systemu Windows (WAS).
- Wykonuje inicjowanie aplikacji.
- Ładuje moduł CoreCLR.
- Wywołuje
Program.Main.
- Obsługuje okres istnienia żądania natywnego usług IIS.
Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną wewnątrz procesu:
- Żądanie jest dostarczane z Internetu do sterownika HTTP.sys trybu jądra.
- Sterownik kieruje żądanie natywne do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS).
- Moduł ASP.NET Core Module odbiera żądanie natywne i przekazuje je do serwera HTTP usług IIS (
IISHttpServer). Serwer HTTP usług IIS to implementacja serwera przetwarzania wewnątrz procesu dla usług IIS, która konwertuje żądanie z natywnego na zarządzane.
Po zakończeniu przetwarzania żądania przez serwer HTTP usług IIS:
- Żądanie jest wysyłane do potoku oprogramowania pośredniczącego ASP.NET Core.
- Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako wystąpienie obiektu
HttpContextdo logiki aplikacji. - Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS za pośrednictwem serwera HTTP usług IIS.
- Usługi IIS wysyłają odpowiedź do klienta, który zainicjował żądanie.
Hosting wewnątrz procesu jest zgodą dla istniejących aplikacji. Szablony internetowe ASP.NET Core używają modelu hostingu wewnątrz procesu.
CreateDefaultBuilder dodaje wystąpienie IServer, wywołując metodę UseIIS, aby uruchomić moduł CoreCLR i hostować aplikację wewnątrz procesu roboczego usług IIS (w3wp.exe lub iisexpress.exe). Testy wydajności wskazują, że hostowanie aplikacji .NET Core wewnątrz procesu zapewnia znacznie większą przepływność żądań w porównaniu z hostowaniem żądań poza procesem aplikacji i żądaniami proxy do usługi Kestrel.
Aplikacje opublikowane jako pojedynczy plik wykonywalny nie mogą być ładowane przez model hostingu wewnątrz procesu.
Model hostingu poza procesem
Ponieważ aplikacje ASP.NET Core działają w procesie oddzielonym od procesu roboczego usług IIS, moduł ASP.NET Core Module obsługuje zarządzanie procesami. Moduł uruchamia proces na potrzeby aplikacji ASP.NET Core po odebraniu pierwszego żądania i ponownie uruchamia aplikację, jeśli zostanie ona zamknięta lub ulegnie awarii. Jest to zasadniczo takie samo działanie jak w przypadku aplikacji uruchamianych wewnątrz procesu, zarządzanych przez usługę aktywacji procesów systemu Windows (WAS).
Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:
- Żądania z Internetu docierają do sterownika HTTP.sys trybu jądra.
- Sterownik kieruje żądania do usług IIS na skonfigurowanym porcie witryny internetowej. Skonfigurowany port to zwykle 80 (HTTP) lub 443 (HTTPS).
- Moduł przekazuje żądania do Kestrel na losowym porcie aplikacji. Losowy port nie jest portem 80 ani 443.
Moduł ASP.NET Core Module określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania. Rozszerzenie UseIISIntegration konfiguruje serwer do nasłuchiwania w systemie http://localhost:{PORT}. Wykonywane są dodatkowe kontrole, a żądania, które nie pochodzą z modułu, są odrzucane. Moduł nie obsługuje przekazywania HTTPS. Żądania są przekazywane za pośrednictwem protokołu HTTP, nawet jeśli są odbierane przez usługi IIS za pośrednictwem protokołu HTTPS.
Po odebraniu przez Kestrel żądania z modułu żądanie to jest przekazywane do potoku oprogramowania pośredniczącego ASP.NET Core. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako wystąpienie obiektu HttpContext do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację z usługami IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazanie żądania do serwera Kestrel. Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które przekazują ją z powrotem do klienta HTTP, który zainicjował żądanie.
Aby uzyskać wskazówki dotyczące konfiguracji modułu ASP.NET Core Module, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Aby uzyskać więcej informacji na temat hostingu, zobacz Host w ASP.NET Core.
Konfiguracja aplikacji
Włączanie składników IISIntegration
Podczas tworzenia hosta w elemencie CreateHostBuilder (Program.cs) wywołaj polecenie CreateDefaultBuilder w celu włączenia integracji usług IIS:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
...
Aby uzyskać więcej informacji na temat programu CreateDefaultBuilder, zobacz Host ogólny platformy .NET w ASP.NET Core.
Opcje usług IIS
Model hostingu wewnątrz procesu
Aby skonfigurować opcje serwera usług IIS, dołącz konfigurację usługi dla programu IISServerOptions w programie ConfigureServices. Poniższy przykład wyłącza funkcję AutomaticAuthentication:
services.Configure<IISServerOptions>(options =>
{
options.AutomaticAuthentication = false;
});
| Opcja | Wartość domyślna | Ustawienie |
|---|---|---|
AutomaticAuthentication |
true |
Jeśli true, program IIS Server ustawia HttpContext.User uwierzytelnione przez uwierzytelnianie systemu Windows. Jeśli false, serwer tylko udostępnia tożsamość HttpContext.User i odpowiada na wyzwania, gdy jest jawnie żądany przez AuthenticationScheme. Uwierzytelnianie systemu Windows musi być włączone w usługach IIS, aby AutomaticAuthentication działała. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie systemu Windows. |
AuthenticationDisplayName |
null |
Ustawia nazwę wyświetlaną pokazywaną użytkownikom na stronach logowania. |
AllowSynchronousIO |
false |
Czy synchroniczne operacje we/wy są dozwolone dla elementu HttpContext.Request i HttpContext.Response. |
MaxRequestBodySize |
30000000 |
Pobiera lub ustawia maksymalny rozmiar treści żądania dla elementu HttpRequest. Należy pamiętać, że same usługi IIS mają limit maxAllowedContentLength, który zostanie przetworzony przed ustawieniem MaxRequestBodySize w elemencie IISServerOptions. Zmiana MaxRequestBodySize nie wpłynie na element maxAllowedContentLength. Aby zwiększyć wartość maxAllowedContentLength, dodaj wpis w web.config, aby ustawić maxAllowedContentLength na wyższą wartość. Aby uzyskać więcej informacji, zobacz pozycję Konfiguracja. |
Model hostingu poza procesem
Aby skonfigurować opcje usług IIS, dołącz konfigurację usługi dla IISOptions w ConfigureServices. Poniższy przykład uniemożliwia wypełnianie HttpContext.Connection.ClientCertificate przez aplikację:
services.Configure<IISOptions>(options =>
{
options.ForwardClientCertificate = false;
});
| Opcja | Wartość domyślna | Ustawienie |
|---|---|---|
AutomaticAuthentication |
true |
Jeśli true, oprogramowanie pośredniczące integracji usług IIS ustawia HttpContext.User uwierzytelniony przez uwierzytelnianie systemu Windows. Jeśli false, oprogramowanie pośredniczące zapewnia tylko tożsamość dla HttpContext.User i odpowiada na wyzwania, gdy jest to jawnie wymagane przez AuthenticationScheme. Uwierzytelnianie systemu Windows musi być włączone w usługach IIS, aby AutomaticAuthentication działała. Aby uzyskać więcej informacji, zobacz temat Uwierzytelnianie systemu Windows. |
AuthenticationDisplayName |
null |
Ustawia nazwę wyświetlaną pokazywaną użytkownikom na stronach logowania. |
ForwardClientCertificate |
true |
Jeśli true i nagłówek żądania MS-ASPNETCORE-CLIENTCERT są obecne, HttpContext.Connection.ClientCertificate zostanie wypełniony. |
Scenariusze dotyczące serwera proxy i modułu równoważenia obciążenia
Oprogramowanie pośredniczące integracji usług IIS i moduł ASP.NET Core Module są skonfigurowane do przekazywania:
- Schematu (HTTP/HTTPS).
- Zdalnego adresu IP, z którego pochodzi żądanie.
Oprogramowanie pośredniczące integracji usług IIS konfiguruje oprogramowanie pośredniczące nagłówków przekazywanych.
Dodatkowa konfiguracja może być wymagana w przypadku aplikacji hostowanych za dodatkowymi serwerami proxy i modułami równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia.
Plik web.config
Plik web.config konfiguruje moduł ASP.NET Core Module. Tworzenie, przekształcanie i publikowanie pliku web.config jest obsługiwane przez obiekt docelowy MSBuild (_TransformWebConfig) po opublikowaniu projektu. Ten element docelowy znajduje się w elementach docelowych zestawu Web SDK (Microsoft.NET.Sdk.Web). Zestaw SDK jest ustawiany w górnej części pliku projektu:
<Project Sdk="Microsoft.NET.Sdk.Web">
Jeśli plik web.config nie występuje w projekcie, zostanie on utworzony z poprawną wartością processPath i arguments w celu skonfigurowania modułu ASP.NET Core Module i przeniesiony do opublikowanych danych wyjściowych.
Jeśli plik web.config występuje w projekcie, zostanie on przekształcony przy użyciu poprawnego processPath i arguments w celu skonfigurowania modułu ASP.NET Core Module i przeniesiony do opublikowanych danych wyjściowych. Przekształcenie nie modyfikuje ustawień konfiguracji usług IIS w pliku.
Plik web.config może zawierać dodatkowe ustawienia konfiguracji usług IIS kontrolujące aktywne moduły usług IIS. Aby uzyskać informacje na temat modułów usług IIS, które mogą przetwarzać żądania za pomocą aplikacji ASP.NET Core, zobacz temat Moduły usług IIS.
Aby uniemożliwić przekształcanie pliku web.config za pomocą internetowego zestawu SDK, użyj właściwości <IsTransformWebConfigDisabled> w pliku projektu:
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Podczas wyłączania w internetowym zestawie SDK możliwości przekształcania pliku element processPath i arguments powinien zostać ręcznie ustawiony przez dewelopera. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Lokalizacja pliku web.config
Aby poprawnie skonfigurować moduł ASP.NET Core Module, plik web.config musi znajdować się w ścieżce głównej zawartości (zazwyczaj to ścieżka podstawowa aplikacji) wdrożonej aplikacji. Jest to ta sama lokalizacja, co ścieżka fizyczna witryny internetowej dostarczona do usług IIS. Plik web.config jest wymagany w katalogu głównym aplikacji, aby umożliwić publikowanie wielu aplikacji przy użyciu narzędzia Web Deploy.
Poufne pliki istnieją na ścieżce fizycznej aplikacji, na przykład {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (komentarze dokumentacji XML) i {ASSEMBLY}.deps.json, gdzie symbol zastępczy {ASSEMBLY} jest nazwą zestawu. Gdy plik web.config występuje i witryna jest uruchamiana normalnie, usługi IIS nie obsługują tych poufnych plików, jeśli są one żądane. Jeśli brakuje pliku web.config, został on niepoprawnie nazwany, lub nie można skonfigurować lokacji na potrzeby normalnego uruchamiania, usługi IIS mogą publicznie obsługiwać poufne pliki.
Plik web.config musi występować we wdrożeniu przez cały czas, poprawnie nazwany, i w stanie skonfigurować lokację pod kątem normalnego uruchamiania. Nigdy nie usuwaj pliku web.config z wdrożenia produkcyjnego.
Przekształcanie pliku web.config
Jeśli musisz przekształcić web.config podczas publikowania, zobacz Przekształcanie web.config. Może być konieczne przekształcenie web.config podczas publikowania w celu ustawienia zmiennych środowiskowych na podstawie konfiguracji, profilu lub środowiska.
Konfiguracja usług IIS
Systemy operacyjne Windows Server
Włącz rolę serwera Web Server (IIS) i ustal usługi ról.
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).
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.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.
Przejdź do pozycji Panel sterowania>Programy>Programy i funkcje>Włącz lub wyłącz funkcje systemu Windows (po lewej stronie ekranu).
Otwórz węzeł Internet Information Services. Otwórz węzeł Internetowe narzędzia zarządzania.
Zaznacz pole wyboru konsoli zarządzania usługami IIS.
Zaznacz pole wyboru Usługi internetowe.
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.Jeśli instalacja usług IIS wymaga ponownego uruchomienia, uruchom ponownie system.
Instalowanie pakietu hostingu platformy .NET Core
Zainstaluj pakiet hostingu platformy .NET Core w systemie hostingu. Pakiet instaluje środowisko uruchomieniowe platformy .NET Core, bibliotekę .NET Core i moduł ASP.NET Core Module. Moduł umożliwia uruchamianie aplikacji ASP.NET Core za usługami IIS.
Ważne
Jeśli pakiet hostingowy jest zainstalowany przed usługami IIS, należy naprawić instalację pakietu. Ponownie uruchom instalatora pakietu hostingowego po zainstalowaniu usług IIS.
Jeśli pakiet hostingowy został zainstalowany po zainstalowaniu 64-bitowej (x64) wersji platformy .NET Core, może wydawać się, że brakuje zestawów SDK (Nie wykryto zestawów SDK platformy .NET Core). Aby rozwiązać ten problem, zobacz Rozwiązywanie problemów i debugowanie projektów ASP.NET Core.
Pobieranie bezpośrednie (bieżąca wersja)
Pobierz instalatora za pomocą następującego linku:
Bieżący instalator pakietu hostingowego platformy .NET Core (pobieranie bezpośrednie)
Wcześniejsze wersje instalatora
Aby uzyskać starszą wersję instalatora:
- Przejdź do strony Pobieranie platformy .NET Core.
- Wybierz żądaną wersję platformy .NET Core.
- W kolumnie Uruchamianie aplikacji — środowisko uruchomieniowe znajdź wiersz żądanej wersji środowiska uruchomieniowego platformy .NET Core.
- Pobierz instalatora przy użyciu linku pakietu hostingowego.
Ostrzeżenie
Niektóre instalatory zawierają wersje wydania, które osiągnęły koniec obsługi (EOL) i nie są już wspierane przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej.
Instalowanie pakietu hostingowego
Uruchom instalatora na serwerze. Następujące parametry są dostępne podczas uruchamiania instalatora w powłoce poleceń administratora:
OPT_NO_ANCM=1: Pomiń instalowanie modułu ASP.NET Core Module.OPT_NO_RUNTIME=1: Pomiń instalowanie środowiska uruchomieniowego platformy .NET Core. Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).OPT_NO_SHAREDFX=1: Pomiń instalowanie platformy udostępnionej ASP.NET (środowiska uruchomieniowego ASP.NET). Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).OPT_NO_X86=1: Pomiń instalowanie środowisk uruchomieniowych x86. Użyj tego parametru, gdy wiesz, że nie będziesz hostować aplikacji 32-bitowych. Jeśli istnieje jakiekolwiek prawdopodobieństwo hostowania aplikacji 32-bitowych i 64-bitowych w przyszłości, nie używaj tego parametru i zainstaluj oba środowiska uruchomieniowe.OPT_NO_SHARED_CONFIG_CHECK=1: Wyłącz sprawdzanie przy użyciu konfiguracji udostępnionej usług IIS, gdy konfiguracja udostępniona (applicationHost.config) znajduje się na tej samej maszynie co instalacja usług IIS. Dostępne tylko dla instalatorów pakietów hostingowych ASP.NET Core 2.2 lub nowszych. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Ponowne uruchomienie usług IIS powoduje zmianę zmiennej PATH systemu, czyli zmiennej środowiskowej wprowadzonej przez instalatora. Aby ponownie uruchomić serwer internetowy, zatrzymaj usługę aktywacji procesów systemu Windows (WAS), a następnie uruchom ponownie usługę publikowania w sieci World Wide Web (W3SVC). Uruchom ponownie system lub wykonaj następujące polecenia w powłoce poleceń z podwyższonym poziomem uprawnień:
net stop was /y net start w3svc
ASP.NET Core nie stosuje zachowania przechodzenia w przypadku wydań poprawek pakietów platform udostępnionych. Po uaktualnieniu struktury udostępnionej przez zainstalowanie nowego pakietu hostingowego uruchom ponownie system lub wykonaj następujące polecenia w powłoce poleceń z podwyższonym poziomem uprawnień:
net stop was /y
net start w3svc
Uwaga
Aby uzyskać informacje na temat konfiguracji udostępnionej usług IIS, zobacz Moduł ASP.NET Core Module z konfiguracją udostępnioną usług IIS.
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, użyj Instalatora platformy sieci Web (WebPI) lub zobacz Pliki do pobrania usług IIS: Web Deploy. Preferowaną metodą jest użycie instalatora WebPI. Instalator WebPI oferuje autonomiczną konfigurację i konfigurację dla dostawców hostingu.
Tworzenie witryny usług IIS
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.
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.
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/ihttp://+: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).W węźle serwera wybierz pozycję Pule aplikacji.
Kliknij prawym przyciskiem myszy pulę aplikacji witryny i wybierz pozycję Ustawienia podstawowe z menu kontekstowego.
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.
ASP.NET Core 2.2 lub nowszym:
W przypadku 32-bitowego (x86) samodzielnego wdrożenia opublikowanego przy użyciu 32-bitowego zestawu SDK korzystającego z modelu hostingu wewnątrz procesu 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 wewnątrz procesu 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.
Upewnij się, że tożsamość modelu procesu ma odpowiednie uprawnienia.
Jeśli domyślna tożsamość puli aplikacji (model procesu>Identity) zostanie zmieniona z puli aplikacjiIdentity na inną tożsamość, sprawdź, czy nowa tożsamość 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.
Wdrażanie aplikacji
Wdróż aplikację w folderze ścieżka fizyczna usług IIS, który został ustanowiony w sekcji Tworzenie witryny usług IIS. Narzędzie Web Deploy jest zalecanym mechanizmem wdrażania, ale istnieje kilka opcji przenoszenia aplikacji z folderu projektu publish do folderu wdrożenia systemu hostingowego.
Narzędzie Web Deploy z programem Visual Studio
Zobacz temat profile publikowania programu Visual Studio dla wdrażania aplikacji ASP.NET Core, aby dowiedzieć się, jak utworzyć profil publikowania do użycia z narzędziem Web Deploy. Jeśli dostawca hostingu udostępnia profil publikowania lub obsługę tworzenia takiego profilu, pobierz jego profil i zaimportuj go przy użyciu okna dialogowego Publikowanie programu Visual Studio:
Narzędzie Web Deploy poza programem Visual Studio
Narzędzia Web Deploy można również używać poza programem Visual Studio z poziomu wiersza polecenia. Aby uzyskać więcej informacji, zobacz Narzędzie Web Deploy.
Alternatywy dla narzędzia Web Deploy
Użyj dowolnej z kilku metod przenoszenia aplikacji do systemu hostingu, takich jak ręczne kopiowanie, Xcopy, Robocopy lub PowerShell.
Aby uzyskać więcej informacji na temat wdrażania ASP.NET Core w usługach IIS, zobacz sekcję Zasoby wdrażania dla administratorów usług IIS.
Przeglądanie witryny internetowej
Po wdrożeniu aplikacji w systemie hostingu prześlij żądanie do jednego z publicznych punktów końcowych aplikacji.
W poniższym przykładzie lokacja jest powiązana z nazwą hosta usług IIS na porcie 80.www.mysite.com Żądanie jest kierowane do http://www.mysite.com:
Zablokowane pliki wdrożenia
Pliki w folderze wdrożenia są zablokowane, gdy aplikacja jest uruchomiona. Zablokowanych plików nie można zastąpić podczas wdrażania. Aby zwolnić zablokowane pliki we wdrożeniu, zatrzymaj pulę aplikacji przy użyciu jednej z następujących metod:
Użyj narzędzia Web Deploy i odwołania
Microsoft.NET.Sdk.Webw pliku projektu. Plikapp_offline.htmjest umieszczany w katalogu głównym katalogu aplikacji internetowej. Gdy plik występuje, moduł ASP.NET Core Module bezpiecznie zamyka aplikację i obsługuje plikapp_offline.htmpodczas wdrażania. Aby uzyskać więcej informacji, zobacz dokumentację konfiguracji modułu ASP.NET Core Module.Ręcznie zatrzymaj pulę aplikacji w Menedżerze usług IIS na serwerze.
Użyj programu PowerShell, aby usunąć
app_offline.htm(wymaga programu PowerShell 5 lub nowszego):$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
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ń kluczy 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 ASP.NET Core MVC TempData cookies.
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 utrwalić 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, który jest dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane podczas magazynowania przy użyciu interfejsu DPAPI z kluczem obejmującym całą maszynę.
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 ochrony danych nie są szyfrowane. Upewnij się, że uprawnienia plików do 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 magazynowanych. Rozważ mechanizm zezwalania użytkownikom na przekazywanie certyfikatów: umieść certyfikaty w zaufanym magazynie 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ć szczegółowe informacje, zobacz Konfigurowanie ochrony danych ASP.NET Core.
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ściTrueklucze 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.Należy również włączyć atrybut setProfileEnvironment puli aplikacji. Wartość domyślna
setProfileEnvironmenttotrue. W niektórych scenariuszach (na przykład systemu operacyjnego Windows) opcjasetProfileEnvironmentjest ustawiona na wartośćfalse. Jeśli klucze nie są przechowywane w katalogu profilu użytkownika zgodnie z oczekiwaniami:- Przejdź do folderu %windir%/system32/inetsrv/config.
- Otwórz plik applicationHost.config.
- Znajdź element
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Upewnij się, że atrybut
setProfileEnvironmentnie występuje, co powoduje, że wartość domyślnie staje się równatrue, lub jawnie ustaw wartość atrybutu natrue.
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 ochrony danych dla całej maszyny
System ochrony danych ma ograniczoną obsługę ustawiania domyślnych zasad dla całej maszyny dla wszystkich aplikacji korzystających z interfejsów API ochrony danych. Aby uzyskać więcej informacji, zobacz Omówienie ochrony danych ASP.NET Core.
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 aplikacji podrzędnej powinny używać notacji tylda-ukośnik (~/). 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.
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:
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).
Dodaj witrynę główną w Menedżerze usług IIS za pomocą aplikacji podrzędnej w folderze w witrynie głównej.
Kliknij prawym przyciskiem myszy folder aplikacji podrzędnej w Menedżerze usług IIS i wybierz polecenie Konwertuj na aplikację.
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.
Konfiguracja usług IIS przy użyciu pliku web.config
Na konfigurację usług IIS ma wpływ sekcja <system.webServer> pliku web.config dla scenariuszy usług IIS, które są funkcjonalne dla aplikacji ASP.NET Core z modułem ASP.NET Core Module. Na przykład konfiguracja usług IIS jest funkcjonalna dla kompresji dynamicznej. Jeśli usługi IIS są skonfigurowane na poziomie serwera do korzystania z kompresji dynamicznej, element <urlCompression> w pliku web.config aplikacji może wyłączyć ją dla aplikacji ASP.NET Core.
Aby uzyskać więcej informacji, zobacz następujące tematy:
- Dokumentacja konfiguracji dla <system.webServer>
- Moduł ASP.NET Core (ANCM) dla usług IIS
- Moduły usług IIS z platformą ASP.NET Core
Aby ustawić zmienne środowiskowe dla poszczególnych aplikacji działających w izolowanych pulach aplikacji (obsługiwanych w usługach IIS 10.0 lub nowszych), zobacz sekcję Polecenie AppCmd.exe w temacie Zmienne środowiskowe <environmentVariables> w dokumentacji referencyjnej usług IIS.
Sekcje, które nie są używane przez ASP.NET Core
Sekcje konfiguracji aplikacji ASP.NET w pliku web.config nie są używane przez aplikacje ASP.NET Core do celów konfiguracji:
<system.web><appSettings><connectionStrings><location>
Aplikacje ASP.NET Core są konfigurowane przy użyciu innych dostawców konfiguracji. Aby uzyskać więcej informacji, zobacz pozycje Konfiguracja i Ustawienia konfiguracji środowiska uruchomieniowego platformy .NET Core
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 tożsamości puli aplikacji umożliwia uruchamianie aplikacji w ramach unikatowego konta bez konieczności tworzenia domen lub kont lokalnych i 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 jest wartość Identity jest ustawiona do używania 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 tej tożsamości. Jednak ta tożsamość nie jest rzeczywistym kontem użytkownika i nie jest wyświetlana 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ę:
Otwórz Eksploratora Windows i przejdź do katalogu.
Kliknij prawym przyciskiem myszy katalog i wybierz pozycję Właściwości.
Na karcie Zabezpieczenia wybierz przycisk Edytuj, a następnie przycisk Dodaj.
Wybierz przycisk Lokalizacje i upewnij się, że system jest wybrany.
Wprowadź
IIS AppPool\{APP POOL NAME}, gdzie symbol zastępczy{APP POOL NAME}jest nazwą puli aplikacji, w obszarze Wprowadź nazwy obiektów do wybrania. Wybierz przycisk Sprawdź nazwy. W przypadku puli DefaultAppPool sprawdź nazwy przy użyciu poleceniaIIS AppPool\DefaultAppPool. Po wybraniu przycisku Sprawdź nazwy wartośćDefaultAppPooljest wskazywana w obszarze nazw obiektów. Nie można wprowadzić nazwy puli aplikacji bezpośrednio w obszarze nazw obiektów. Użyj formatuIIS AppPool\{APP POOL NAME}, w którym symbol zastępczy{APP POOL NAME}jest nazwą puli aplikacji, podczas sprawdzania nazwy obiektu.
Wybierz przycisk OK.
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. Używając DefaultAppPool jako przykładu, wykorzystano następujące polecenie:
ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F
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: aplikacja hostowana wewnątrz procesu może nie być skonfigurowana do przekroczenia limitu 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:
- Przejdź do pozycji Panel sterowania>Programy>Programy i funkcje>Włącz lub wyłącz funkcje systemu Windows (po lewej stronie ekranu).
- Otwórz pozycję Internet Information Services>Usługi internetowe>Funkcje tworzenia aplikacji.
- Zaznacz pole wyboru Inicjowanie aplikacji.
W systemie Windows Server 2008 R2 lub nowszym:
- Otwórz Kreatora dodawania ról i funkcji.
- W panelu Wybieranie usług ról otwórz węzeł Tworzenie aplikacji.
- 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:
- Wybierz pozycję Pule aplikacji w panelu Połączenia.
- Kliknij prawym przyciskiem myszy pulę aplikacji na liście i wybierz pozycję Ustawienia zaawansowane.
- Domyślny tryb uruchamiania to OnDemand. Ustaw tryb uruchamiania na wartość AlwaysRunning. Wybierz przycisk OK.
- Otwórz węzeł Witryny w panelu Połączenia.
- Kliknij prawym przyciskiem myszy aplikację i wybierz pozycję Zarządzanie witrynami>Ustawienia zaawansowane.
- Domyślne ustawienie Wstępne ładowanie włączone ma wartość Fałsz. Ustaw wstępnie włączone ładowanie na wartość Prawda. Wybierz przycisk OK.
Za pomocą polecenia
web.configdodaj element<applicationInitialization>za pomocądoAppInitAfterRestartustawioną na wartośćtruedla elementów<system.webServer>w pliku web.config aplikacji:<?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:
- Wybierz pozycję Pule aplikacji w panelu Połączenia.
- Kliknij prawym przyciskiem myszy pulę aplikacji na liście i wybierz pozycję Ustawienia zaawansowane.
- Domyślny limit czasu bezczynności (minuty) wynosi 20 minut. Ustaw wartość limitu czasu bezczynności (minuty) na 0 (zero). Wybierz przycisk OK.
- 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 aplikacji <applicationInitialization>.
- Ustawienia modelu procesów dla puli aplikacji <processModel>.
Zasoby wdrażania dla administratorów usług IIS
- Dokumentacja usług IIS
- Wprowadzenie za pomocą Menedżera usług IIS w usługach IIS
- Wdrażanie aplikacji platformy .NET Core
- Moduł ASP.NET Core (ANCM) dla usług IIS
- Struktura katalogów platformy ASP.NET Core
- Moduły usług IIS z platformą ASP.NET Core
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
Dodatkowe zasoby
Aby zapoznać się z samouczkiem dotyczącym publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS.
Instalowanie pakietu hostingu platformy .NET Core
Obsługiwane systemy operacyjne
Obsługiwane są następujące systemy operacyjne:
- Windows 7 lub nowszy
- Windows Server 2008 R2 lub nowszy
Serwer HTTP.sys (wcześniej nazywany WebListener) nie działa w konfiguracji odwrotnego serwera proxy z usługami IIS. Użyj serwera Kestrel .
Aby uzyskać informacje na temat hostowania na platformie Azure, zobacz Wdrażanie aplikacji ASP.NET Core w usłudze Azure App Service.
Aby uzyskać wskazówki dotyczące rozwiązywania problemów, zobacz Rozwiązywanie problemów i debugowanie projektów ASP.NET Core.
Obsługiwane platformy
Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wdróż aplikację 32-bitową za pomocą 32-bitowego zestawu SDK platformy .NET Core (x86), chyba że aplikacja:
- Wymaga większej przestrzeni adresowej pamięci wirtualnej dostępnej dla aplikacji 64-bitowej.
- Wymaga większego rozmiaru stosu usług IIS.
- Ma 64-bitowe zależności natywne.
Użyj 64-bitowego zestawu SDK platformy .NET Core (x64), aby opublikować 64-bitową aplikację. W systemie hosta musi znajdować się 64-bitowe środowisko uruchomieniowe.
ASP.NET Core jest dostarczany z serwerem Kestrel , domyślnym, międzyplatformowym serwerem HTTP.
W przypadku korzystania z usług IIS lub IIS Express aplikacja jest uruchamiana w procesie oddzielnym od procesu roboczego usług IIS (poza procesem), z serwerem Kestrel.
Ponieważ aplikacje ASP.NET Core są uruchamiane w procesie oddzielnym od procesu roboczego usług IIS, moduł obsługuje zarządzanie procesami. Moduł uruchamia proces na potrzeby aplikacji ASP.NET Core po odebraniu pierwszego żądania i ponownie uruchamia aplikację, jeśli zostanie ona zamknięta lub ulegnie awarii. Jest to zasadniczo takie samo działanie jak w przypadku aplikacji uruchamianych wewnątrz procesu, zarządzanych przez usługę aktywacji procesów systemu Windows (WAS).
Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:
Żądania z Internetu docierają do sterownika HTTP.sys trybu jądra. Sterownik kieruje te żądania do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS). Moduł przekazuje żądania do serwera Kestrel na losowym porcie dla aplikacji, który nie jest portem 80 ani 443.
Moduł określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania, a oprogramowanie pośredniczące integracji usług IIS konfiguruje serwer do nasłuchiwania na porcie http://localhost:{port}. Wykonywane są dodatkowe kontrole, a żądania, które nie pochodzą z modułu, są odrzucane. Moduł nie obsługuje przekazywania HTTPS, dlatego żądania są przekazywane za pośrednictwem protokołu HTTP, nawet jeśli zostały odebrane przez usługi IIS za pośrednictwem protokołu HTTPS.
Żądanie z modułu odebrane przez serwer Kestrel jest wypychane do potoku oprogramowania pośredniczącego ASP.NET Core. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako wystąpienie obiektu HttpContext do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację z usługami IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazanie żądania do serwera Kestrel. Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które wypychają ją z powrotem do klienta HTTP, który zainicjował żądanie.
CreateDefaultBuilder konfiguruje serwer Kestrel jako serwer internetowy i włącza integrację usług IIS, konfigurując ścieżkę podstawową i port dla Modułu ASP.NET Core Module.
Moduł ASP.NET Core generuje port dynamiczny do przypisania do procesu zaplecza. CreateDefaultBuilder wywołuje metodę UseIISIntegration. UseIISIntegration konfiguruje Kestrel do nasłuchiwania na porcie dynamicznym pod adresem IP hosta lokalnego (127.0.0.1). Jeśli port dynamiczny to 1234, program Kestrel nasłuchuje na 127.0.0.1:1234. Ta konfiguracja zastępuje inne konfiguracje adresów URL udostępniane przez:
Wywołania interfejsu API UseUrls lub interfejsu API Kestrel Listen nie są wymagane podczas korzystania z modułu. Jeśli wywołano UseUrls lub Listen, program Kestrel nasłuchuje na porcie określonym tylko podczas uruchamiania aplikacji bez usług IIS.
Aby uzyskać wskazówki dotyczące konfiguracji modułu ASP.NET Core Module, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Aby uzyskać więcej informacji na temat hostingu, zobacz Host w ASP.NET Core.
Konfiguracja aplikacji
Włączanie składników IISIntegration
Podczas tworzenia hosta w elemencie CreateWebHostBuilder (Program.cs) wywołaj polecenie CreateDefaultBuilder w celu włączenia integracji usług IIS:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
...
Aby uzyskać więcej informacji o CreateDefaultBuilder, zobacz Host internetowy ASP.NET Core.
Opcje usług IIS
| Opcja | Wartość domyślna | Ustawienie |
|---|---|---|
AutomaticAuthentication |
true |
Jeśli true, program IIS Server ustawia HttpContext.User uwierzytelnione przez uwierzytelnianie systemu Windows. Jeśli false, serwer tylko udostępnia tożsamość HttpContext.User i odpowiada na wyzwania, gdy jest jawnie żądany przez AuthenticationScheme. Uwierzytelnianie systemu Windows musi być włączone w usługach IIS, aby AutomaticAuthentication działała. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie systemu Windows. |
AuthenticationDisplayName |
null |
Ustawia nazwę wyświetlaną pokazywaną użytkownikom na stronach logowania. |
Aby skonfigurować opcje usług IIS, dołącz konfigurację usługi dla IISOptions w ConfigureServices. Poniższy przykład uniemożliwia wypełnianie HttpContext.Connection.ClientCertificate przez aplikację:
services.Configure<IISOptions>(options =>
{
options.ForwardClientCertificate = false;
});
| Opcja | Wartość domyślna | Ustawienie |
|---|---|---|
AutomaticAuthentication |
true |
Jeśli true, oprogramowanie pośredniczące integracji usług IIS ustawia HttpContext.User uwierzytelniony przez uwierzytelnianie systemu Windows. Jeśli false, oprogramowanie pośredniczące zapewnia tylko tożsamość dla HttpContext.User i odpowiada na wyzwania, gdy jest to jawnie wymagane przez AuthenticationScheme. Uwierzytelnianie systemu Windows musi być włączone w usługach IIS, aby AutomaticAuthentication działała. Aby uzyskać więcej informacji, zobacz temat Uwierzytelnianie systemu Windows. |
AuthenticationDisplayName |
null |
Ustawia nazwę wyświetlaną pokazywaną użytkownikom na stronach logowania. |
ForwardClientCertificate |
true |
Jeśli true i nagłówek żądania MS-ASPNETCORE-CLIENTCERT są obecne, HttpContext.Connection.ClientCertificate zostanie wypełniony. |
Scenariusze dotyczące serwera proxy i modułu równoważenia obciążenia
Oprogramowanie pośredniczące integracji usług IIS, które konfiguruje oprogramowanie pośredniczące przekazywania nagłówków i moduł ASP.NET Core Module są skonfigurowane do przekazywania schematu (HTTP/HTTPS) i zdalnego adresu IP, z którego pochodzi żądanie. Dodatkowa konfiguracja może być wymagana w przypadku aplikacji hostowanych za dodatkowymi serwerami proxy i modułami równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia.
Plik web.config
Plik web.config konfiguruje Moduł ASP.NET Core Module. Tworzenie, przekształcanie i publikowanie pliku web.config jest obsługiwane przez obiekt docelowy MSBuild (_TransformWebConfig) podczas publikowania projektu. Ten element docelowy znajduje się w elementach docelowych zestawu Web SDK (Microsoft.NET.Sdk.Web). Zestaw SDK jest ustawiany w górnej części pliku projektu:
<Project Sdk="Microsoft.NET.Sdk.Web">
Jeśli plik web.config nie występuje w projekcie, zostanie on utworzony z prawidłowymi wartościami processPath i argumentami, aby skonfigurować moduł ASP.NET Core Module, i przeniesiony do opublikowanych danych wyjściowych.
Jeśli plik web.config występuje w projekcie, zostanie on przekształcony z prawidłowymi wartościami processPath i argumentami, aby skonfigurować moduł ASP.NET Core Module, i przeniesiony do opublikowanych danych wyjściowych. Przekształcenie nie modyfikuje ustawień konfiguracji usług IIS w pliku.
Plik web.config może zawierać dodatkowe ustawienia konfiguracji usług IIS kontrolujące aktywne moduły usług IIS. Aby uzyskać informacje na temat modułów usług IIS, które mogą przetwarzać żądania za pomocą aplikacji ASP.NET Core, zobacz temat Moduły usług IIS.
Aby uniemożliwić internetowemu zestawowi SDK przekształcanie pliku web.config, użyj właściwości <IsTransformWebConfigDisabled> w pliku projektu:
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Podczas wyłączania internetowego zestawu SDK z przekształcania pliku wartości processPath i argumenty muszą zostać ręcznie ustawione przez dewelopera. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Lokalizacja pliku web.config
Aby poprawnie skonfigurować moduł ASP.NET Core Module, plik web.config musi znajdować się w ścieżce katalogu głównego zawartości (zazwyczaj ścieżce podstawowej aplikacji) wdrożonej aplikacji. Jest to ta sama lokalizacja, co ścieżka fizyczna witryny internetowej dostarczona do usług IIS. Plik web.config jest wymagany w katalogu głównym aplikacji, aby umożliwić publikowanie wielu aplikacji przy użyciu narzędzia Web Deploy.
W ścieżce fizycznej aplikacji istnieją poufne pliki, takie jak <assembly>.runtimeconfig.json, <assembly>.xml (komentarze dokumentacji XML) i <assembly>.deps.json. Gdy plik web.config występuje i witryna jest uruchamiana normalnie, usługi IIS nie obsługują tych poufnych plików, jeśli są one żądane. Jeśli brakuje pliku web.config, został on niepoprawnie nazwany, lub nie można skonfigurować lokacji na potrzeby normalnego uruchamiania, usługi IIS mogą publicznie obsługiwać poufne pliki.
Plik web.config musi występować we wdrożeniu przez cały czas, poprawnie nazwany, i w stanie skonfigurować lokację pod kątem normalnego uruchamiania. Nigdy nie usuwaj pliku web.config z wdrożenia produkcyjnego.
Przekształcanie pliku web.config
Jeśli musisz przekształcić plik web.config podczas publikowania (na przykład ustawić zmienne środowiskowe na podstawie konfiguracji, profilu lub środowiska), zobacz Przekształcanie pliku web.config.
Konfiguracja usług IIS
Systemy operacyjne Windows Server
Włącz rolę serwera Web Server (IIS) i ustal usługi ról.
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).
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.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.
Przejdź do pozycji Panel sterowania>Programy>Programy i funkcje>Włącz lub wyłącz funkcje systemu Windows (po lewej stronie ekranu).
Otwórz węzeł Internet Information Services. Otwórz węzeł Internetowe narzędzia zarządzania.
Zaznacz pole wyboru konsoli zarządzania usługami IIS.
Zaznacz pole wyboru Usługi internetowe.
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.Jeśli instalacja usług IIS wymaga ponownego uruchomienia, uruchom ponownie system.
Instalowanie pakietu hostingu platformy .NET Core
Zainstaluj pakiet hostingu platformy .NET Core w systemie hostingu. Pakiet instaluje środowisko uruchomieniowe platformy .NET Core, bibliotekę .NET Core i moduł ASP.NET Core Module. Moduł umożliwia uruchamianie aplikacji ASP.NET Core za usługami IIS.
Ważne
Jeśli pakiet hostingowy jest zainstalowany przed usługami IIS, należy naprawić instalację pakietu. Ponownie uruchom instalatora pakietu hostingowego po zainstalowaniu usług IIS.
Jeśli pakiet hostingowy został zainstalowany po zainstalowaniu 64-bitowej (x64) wersji platformy .NET Core, może wydawać się, że brakuje zestawów SDK (Nie wykryto zestawów SDK platformy .NET Core). Aby rozwiązać ten problem, zobacz Rozwiązywanie problemów i debugowanie projektów ASP.NET Core.
Pobierz
- Przejdź do strony Pobieranie platformy .NET Core.
- Wybierz żądaną wersję platformy .NET Core.
- W kolumnie Uruchamianie aplikacji — środowisko uruchomieniowe znajdź wiersz żądanej wersji środowiska uruchomieniowego platformy .NET Core.
- Pobierz instalatora przy użyciu linku pakietu hostingowego.
Ostrzeżenie
Niektóre instalatory zawierają wersje wydania, które osiągnęły koniec obsługi (EOL) i nie są już wspierane przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej.
Instalowanie pakietu hostingowego
Uruchom instalatora na serwerze. Następujące parametry są dostępne podczas uruchamiania instalatora w powłoce poleceń administratora:
OPT_NO_ANCM=1: Pomiń instalowanie modułu ASP.NET Core Module.OPT_NO_RUNTIME=1: Pomiń instalowanie środowiska uruchomieniowego platformy .NET Core. Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).OPT_NO_SHAREDFX=1: Pomiń instalowanie platformy udostępnionej ASP.NET (środowiska uruchomieniowego ASP.NET). Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).OPT_NO_X86=1: Pomiń instalowanie środowisk uruchomieniowych x86. Użyj tego parametru, gdy wiesz, że nie będziesz hostować aplikacji 32-bitowych. Jeśli istnieje jakiekolwiek prawdopodobieństwo hostowania aplikacji 32-bitowych i 64-bitowych w przyszłości, nie używaj tego parametru i zainstaluj oba środowiska uruchomieniowe.OPT_NO_SHARED_CONFIG_CHECK=1: Wyłącz sprawdzanie przy użyciu konfiguracji udostępnionej usług IIS, gdy konfiguracja udostępniona (applicationHost.config) znajduje się na tej samej maszynie co instalacja usług IIS. Dostępne tylko dla instalatorów pakietów hostingowych ASP.NET Core 2.2 lub nowszych. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.
Uruchom ponownie system lub wykonaj następujące polecenia w powłoce poleceń:
net stop was /y net start w3svcPonowne uruchomienie usług IIS powoduje zmianę zmiennej PATH systemu, czyli zmiennej środowiskowej wprowadzonej przez instalatora.
Podczas instalowania pakietu hostingu nie trzeba ręcznie zatrzymywać poszczególnych witryn w usługach IIS. Hostowane aplikacje (witryny usług IIS) są ponownie uruchamiane po ponownym uruchomieniu usług IIS. Aplikacje są ponownie uruchamiane po otrzymaniu pierwszego żądania, a w tym z modułu inicjowania aplikacji.
ASP.NET Core stosuje zachowania przechodzenia w przypadku wydań poprawek pakietów platform udostępnionych. Po ponownym uruchomieniu aplikacji hostowanych przez usługi IIS za pomocą usług IIS aplikacje są ładowane z najnowszymi wersjami poprawek pakietów, do których się odwołują, gdy otrzymują pierwsze żądanie. Jeśli usługi IIS nie zostaną uruchomione ponownie, aplikacje zostaną uruchomione ponownie i będą przejawiały zachowanie przechodzenia, gdy ich procesy robocze zostaną odzyskane i otrzymają swoje pierwsze żądanie.
Uwaga
Aby uzyskać informacje na temat konfiguracji udostępnionej usług IIS, zobacz Moduł ASP.NET Core Module z konfiguracją udostępnioną usług IIS.
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, użyj Instalatora platformy sieci Web (WebPI) lub plików do pobrania usług IIS: Web Deploy. Preferowaną metodą jest użycie instalatora WebPI. Instalator WebPI oferuje autonomiczną konfigurację i konfigurację dla dostawców hostingu.
Tworzenie witryny usług IIS
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.
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.
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/ihttp://+: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).W węźle serwera wybierz pozycję Pule aplikacji.
Kliknij prawym przyciskiem myszy pulę aplikacji witryny i wybierz pozycję Ustawienia podstawowe z menu kontekstowego.
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 klasycznego środowiska CLR (.NET CLR) — podstawowe środowisko uruchomieniowe języka wspólnego (CoreCLR) dla platformy .NET Core jest uruchamiane w celu hostowania aplikacji w procesie roboczym. Ustawienie wersji środowiska .NET CLR na wartość Brak kodu zarządzanego jest opcjonalne, ale zalecane.
ASP.NET Core 2.2 lub nowszy: w przypadku samodzielnego wdrożenia 64-bitowego (x64) korzystającego z modelu hostingu wewnątrz procesu wyłącz pulę aplikacji dla procesów 32-bitowych (x86).
Na pasku bocznym Akcje menedżera usług IIS >Pule aplikacji wybierz pozycję Ustaw wartości domyślne puli aplikacji lub Ustawienia zaawansowane. Znajdź opcję Włącz aplikacje 32-bitowe i ustaw jej wartość na
False. To ustawienie nie ma wpływu na aplikacje wdrożone dla hostingu poza procesem.Upewnij się, że tożsamość modelu procesu ma odpowiednie uprawnienia.
Jeśli domyślna tożsamość puli aplikacji (model procesu>Identity) zostanie zmieniona z puli aplikacjiIdentity na inną tożsamość, sprawdź, czy nowa tożsamość 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.
Wdrażanie aplikacji
Wdróż aplikację w folderze ścieżka fizyczna usług IIS, który został ustanowiony w sekcji Tworzenie witryny usług IIS. Narzędzie Web Deploy jest zalecanym mechanizmem wdrażania, ale istnieje kilka opcji przenoszenia aplikacji z folderu publikowania projektu do folderu wdrożenia systemu hostingowego.
Narzędzie Web Deploy z programem Visual Studio
Zobacz temat profile publikowania programu Visual Studio dla wdrażania aplikacji ASP.NET Core, aby dowiedzieć się, jak utworzyć profil publikowania do użycia z narzędziem Web Deploy. Jeśli dostawca hostingu udostępnia profil publikowania lub obsługę tworzenia takiego profilu, pobierz jego profil i zaimportuj go przy użyciu okna dialogowego Publikowanie programu Visual Studio:
Narzędzie Web Deploy poza programem Visual Studio
Narzędzia Web Deploy można również używać poza programem Visual Studio z poziomu wiersza polecenia. Aby uzyskać więcej informacji, zobacz Narzędzie Web Deploy.
Alternatywy dla narzędzia Web Deploy
Użyj dowolnej z kilku metod przenoszenia aplikacji do systemu hostingu, takich jak ręczne kopiowanie, Xcopy, Robocopy lub PowerShell.
Aby uzyskać więcej informacji na temat wdrażania ASP.NET Core w usługach IIS, zobacz sekcję Zasoby wdrażania dla administratorów usług IIS.
Przeglądanie witryny internetowej
Po wdrożeniu aplikacji w systemie hostingu prześlij żądanie do jednego z publicznych punktów końcowych aplikacji.
W poniższym przykładzie lokacja jest powiązana z nazwą hosta usług IIS na porcie 80.www.mysite.com Żądanie jest kierowane do http://www.mysite.com:
Zablokowane pliki wdrożenia
Pliki w folderze wdrożenia są zablokowane, gdy aplikacja jest uruchomiona. Zablokowanych plików nie można zastąpić podczas wdrażania. Aby zwolnić zablokowane pliki we wdrożeniu, zatrzymaj pulę aplikacji przy użyciu jednej z następujących metod:
Użyj narzędzia Web Deploy i odwołania
Microsoft.NET.Sdk.Webw pliku projektu. Plikapp_offline.htmjest umieszczany w katalogu głównym katalogu aplikacji internetowej. Gdy plik występuje, moduł ASP.NET Core Module bezpiecznie zamyka aplikację i obsługuje plikapp_offline.htmpodczas wdrażania. Aby uzyskać więcej informacji, zobacz dokumentację konfiguracji modułu ASP.NET Core Module.Ręcznie zatrzymaj pulę aplikacji w Menedżerze usług IIS na serwerze.
Użyj programu PowerShell, aby usunąć
app_offline.htm(wymaga programu PowerShell 5 lub nowszego):$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
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ń kluczy 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 ASP.NET Core MVC TempData cookies.
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 utrwalić 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, który jest dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane podczas magazynowania przy użyciu interfejsu DPAPI z kluczem obejmującym całą maszynę.
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 ochrony danych nie są szyfrowane. Upewnij się, że uprawnienia plików do 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 magazynowanych. Rozważ mechanizm zezwalania użytkownikom na przekazywanie certyfikatów: umieść certyfikaty w zaufanym magazynie 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ć szczegółowe informacje, zobacz Konfigurowanie ochrony danych ASP.NET Core.
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ściTrueklucze 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.Należy również włączyć atrybut setProfileEnvironment puli aplikacji. Wartość domyślna
setProfileEnvironmenttotrue. W niektórych scenariuszach (na przykład systemu operacyjnego Windows) opcjasetProfileEnvironmentjest ustawiona na wartośćfalse. Jeśli klucze nie są przechowywane w katalogu profilu użytkownika zgodnie z oczekiwaniami:- Przejdź do folderu %windir%/system32/inetsrv/config.
- Otwórz plik applicationHost.config.
- Znajdź element
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>. - Upewnij się, że atrybut
setProfileEnvironmentnie występuje, co powoduje, że wartość domyślnie staje się równatrue, lub jawnie ustaw wartość atrybutu natrue.
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 ochrony danych dla całej maszyny
System ochrony danych ma ograniczoną obsługę ustawiania domyślnych zasad dla całej maszyny dla wszystkich aplikacji korzystających z interfejsów API ochrony danych. Aby uzyskać więcej informacji, zobacz Omówienie ochrony danych ASP.NET Core.
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.
Aplikacja podrzędna nie powinna zawierać modułu ASP.NET Core Module jako procedury obsługi. Jeśli moduł zostanie dodany jako procedura obsługi w pliku web.config podrzędnej aplikacji, podczas próby przeglądania aplikacji podrzędnej zostanie odebrany wewnętrzny błąd serwera 500.19 odwołujący się do błędu pliku konfiguracji.
W poniższym przykładzie pokazano opublikowany plik web.config podrzędnej aplikacji ASP.NET Core:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
W przypadku hostowania aplikacji podrzędnej innej niż ASP.NET Core poniżej aplikacji ASP.NET Core jawnie usuń odziedziczoną procedurę obsługi w pliku web.config podrzędnej aplikacji:
<?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>
Statyczne linki zasobów w aplikacji podrzędnej powinny używać notacji tylda-ukośnik (~/). 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.
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:
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).
Dodaj witrynę główną w Menedżerze usług IIS za pomocą aplikacji podrzędnej w folderze w witrynie głównej.
Kliknij prawym przyciskiem myszy folder aplikacji podrzędnej w Menedżerze usług IIS i wybierz polecenie Konwertuj na aplikację.
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.
Konfiguracja usług IIS przy użyciu pliku web.config
Na konfigurację usług IIS ma wpływ sekcja <system.webServer> pliku web.config dla scenariuszy usług IIS, które są funkcjonalne dla aplikacji ASP.NET Core z modułem ASP.NET Core Module. Na przykład konfiguracja usług IIS jest funkcjonalna dla kompresji dynamicznej. Jeśli usługi IIS są skonfigurowane na poziomie serwera do korzystania z kompresji dynamicznej, element <urlCompression> w pliku web.config aplikacji może wyłączyć ją dla aplikacji ASP.NET Core.
Aby uzyskać więcej informacji, zobacz następujące tematy:
- Dokumentacja konfiguracji dla <system.webServer>
- Moduł ASP.NET Core (ANCM) dla usług IIS
- Moduły usług IIS z platformą ASP.NET Core
Aby ustawić zmienne środowiskowe dla poszczególnych aplikacji działających w izolowanych pulach aplikacji (obsługiwanych w usługach IIS 10.0 lub nowszych), zobacz sekcję Polecenie AppCmd.exe w temacie Zmienne środowiskowe <environmentVariables> w dokumentacji referencyjnej usług IIS.
Sekcje, które nie są używane przez ASP.NET Core
Sekcje konfiguracji aplikacji ASP.NET 4.x w pliku web.config nie są używane przez aplikacje ASP.NET Core do konfiguracji:
<system.web><appSettings><connectionStrings><location>
Aplikacje ASP.NET Core są konfigurowane przy użyciu innych dostawców konfiguracji. Aby uzyskać więcej informacji, zobacz Konfiguracja.
Pule aplikacji
W przypadku hostowania wielu witryn internetowych na serwerze zalecamy odizolowanie aplikacji od siebie, uruchamiając każdą aplikację we własnej puli aplikacji. Domyślnie konfiguracja uzyskuje wartość w oknie dialogowym Dodawanie witryny internetowej usług IIS. 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 tożsamości puli aplikacji umożliwia uruchamianie aplikacji w ramach unikatowego konta bez konieczności tworzenia domen lub kont lokalnych i 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 jest wartość Identity jest ustawiona do używania 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 tej tożsamości. Jednak ta tożsamość nie jest rzeczywistym kontem użytkownika i nie jest wyświetlana 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ę:
Otwórz Eksploratora Windows i przejdź do katalogu.
Kliknij prawym przyciskiem myszy katalog i wybierz pozycję Właściwości.
Na karcie Zabezpieczenia wybierz przycisk Edytuj, a następnie przycisk Dodaj.
Wybierz przycisk Lokalizacje i upewnij się, że system jest wybrany.
Wprowadź nazwę IIS AppPool\<app_pool_name> w obszarze Wprowadź nazwy obiektów do wybrania. Wybierz przycisk Sprawdź nazwy. W przypadku DefaultAppPool sprawdź nazwy przy użyciu IIS AppPool\DefaultAppPool. Po naciśnięciu przycisku Sprawdź nazwy w obszarze nazw obiektów jest wskazywana wartość DefaultAppPool. Nie można wprowadzić nazwy puli aplikacji bezpośrednio w obszarze nazw obiektów. Użyj formatu IIS AppPool\<app_pool_name> podczas sprawdzania nazwy obiektu.
Wybierz przycisk OK.
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 korzystając z defaultAppPool, używane jest następujące polecenie:
ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F
Aby uzyskać więcej informacji, zobacz temat icacls.
Obsługa protokołu HTTP/2
Protokół HTTP/2 jest obsługiwany w przypadku wdrożeń poza procesem, które spełniają następujące podstawowe wymagania:
- 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.
- Platforma docelowa: nie dotyczy wdrożeń poza procesem, ponieważ połączenie HTTP/2 jest obsługiwane w całości przez usługi IIS.
- Połączenie TLS 1.2 lub nowsze
Jeśli połączenie HTTP/2 zostanie nawiązane, httpRequest.Protocol zgłasza HTTP/1.1.
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 pliku 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.
Zasoby wdrażania dla administratorów usług IIS
- Dokumentacja usług IIS
- Wprowadzenie za pomocą Menedżera usług IIS w usługach IIS
- Wdrażanie aplikacji platformy .NET Core
- Moduł ASP.NET Core (ANCM) dla usług IIS
- Struktura katalogów platformy ASP.NET Core
- Moduły usług IIS z platformą ASP.NET Core
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
- Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
