Hostowanie ASP.NET Core na Windows za pomocą usług IIS

Internet Information Services (IIS) to elastyczny, bezpieczny i dostępny w zarządzaniu serwer sieci Web do hostowania aplikacji internetowych, 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). Wd wdrażaj aplikację 32-bitową z 32-bitową (x86) zestaw .NET Core SDK 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 natywne zależności 64-bitowe.

Instalowanie ASP.NET Core/pakietu hostingu

Pobierz instalatora, korzystając z następującego linku:

Bieżący instalator pakietu hostingowego .NET Core (pobieranie bezpośrednie)

Aby uzyskać więcej szczegółowych instrukcji dotyczących instalowania modułu ASP.NET Core Module lub instalowania różnych wersji, zobacz Instalowanie pakietu hostingu .NET Core.

Rozpoczęcie pracy

Aby rozpocząć hostowanie witryny internetowej w usługach IIS, zobacz nasz przewodnik z wprowadzeniem.

Aby rozpocząć hostowanie witryny internetowej w usłudze Azure App Services, zobacz nasz przewodnik dotyczący wdrażania Azure App Service usługi.

Zasoby wdrażania dla administratorów usług IIS

Nakładające się kosze

Ogólnie rzecz biorąc, w przypadku wdrożeń bez przestojów zalecamy używanie wzorca, takiego jak wdrożenia z kolorem niebieskim i zielonym. Funkcje, takie jak Nakładające się kosze, pomagają, ale nie gwarantują, że można wykonać wdrożenie bez przestojów. Aby uzyskać więcej informacji, zobacz ten GitHub problem.

Opcjonalne certyfikaty klienta

Aby uzyskać informacje o aplikacjach, które muszą chronić podzbiór aplikacji przy użyciu certyfikatu, zobacz Opcjonalne certyfikaty klienta.

Dodatkowe zasoby

Aby uzyskać informacje na temat publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS .

Instalowanie pakietu hostingu .NET Core

Obsługiwane systemy operacyjne

Obsługiwane są następujące systemy operacyjne:

  • Windows 7 lub nowszy
  • Windows Server 2012 R2 lub nowszy

HTTP.sys serwera proxy (dawniej WebListener) nie działa w konfiguracji zwrotnego serwera proxy z usługami IIS. Użyj Kestrel serwera.

Aby uzyskać informacje na temat hostingu na platformie Azure, zobacz Wdróż aplikacje ASP.NET Core w Azure App Service .

Aby uzyskać wskazówki dotyczące rozwiązywania problemów, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Obsługiwane platformy

Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wd wdrażaj aplikację 32-bitową z 32-bitową (x86) zestaw .NET Core SDK 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 natywne zależności 64-bitowe.

Aplikacje opublikowane dla wersji 32-bitowej (x86) muszą mieć włączoną obsługę 32-bitowych pul aplikacji usług IIS. Aby uzyskać więcej informacji, zobacz sekcję Tworzenie witryny usług IIS.

Użyj wersji 64-bitowej (x64) zestaw .NET Core SDK publikowania aplikacji 64-bitowej. W systemie hosta musi być obecne 64-bitowe środowisko uruchomieniowe.

Modele hostingu

Model hostingu w procesie

Przy użyciu hostingu w procesie aplikacja ASP.NET Core działa w tym samym procesie co proces roboczy usług IIS. Hosting w procesie zapewnia lepszą wydajność w porównaniu z hostingiem poza procesem, ponieważ żądania nie są proxied przez kartę sprzężenia zwrotnego — interfejs sieciowy, który zwraca wychodzący ruch sieciowy z powrotem do tej samej maszyny. Usługi IIS obsługują zarządzanie procesami za pomocą usługi Windows Process Activation Service (WAS).

Moduł ASP.NET Core:

  • Wykonuje inicjowanie aplikacji.
    • Ładuje program CoreCLR.
    • Wywołuje Program.Main .
  • Obsługuje okres istnienia natywnego żądania usług IIS.

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną w procesie:

ASP.NET Core Moduł w scenariuszu hostingu w procesie

  1. Żądanie jest docierane z Internetu do trybu jądra HTTP.sys sterownika.
  2. Sterownik kieruje żądanie natywne do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS).
  3. Moduł ASP.NET Core odbiera żądanie natywne i przekazuje je do serwera HTTP usług IIS ( IISHttpServer ). Serwer HTTP usług IIS to implementacja serwera przetwarzania dla usług IIS, która konwertuje żądanie z natywnego na zarządzane.

Po zakończeniu przetwarzania żądania przez serwer HTTP usług IIS:

  1. Żądanie jest wysyłane do potoku oprogramowania ASP.NET Core pośredniczącego.
  2. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako HttpContext wystąpienie do logiki aplikacji.
  3. Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS za pośrednictwem serwera HTTP usług IIS.
  4. Usługi IIS wysyłają odpowiedź do klienta, który zainicjował żądanie.

Hosting w procesie jest opt-in dla istniejących aplikacji. Szablony ASP.NET Core używają modelu hostingu w procesie.

CreateDefaultBuilder dodaje wystąpienie, wywołując metodę w celu uruchomienia procesu IServer UseIIS coreCLR i hostowania aplikacji wewnątrz procesu roboczego usług IIS ( w3wp.exe lub iisexpress.exe ). Testy wydajności wskazują, że hostowanie aplikacji .NET Core w procesie zapewnia znacznie wyższą przepływność żądań w porównaniu z hostem aplikacji poza procesem i żądaniami proxy do Kestrel usługi .

Aplikacje opublikowane jako pojedynczy plik wykonywalny nie mogą być ładowane przez model hostingu w procesie.

Model hostingu poza procesem

Ponieważ ASP.NET Core są uruchamiane w procesie oddzielonym od procesu roboczego usług IIS, moduł ASP.NET Core obsługuje zarządzanie procesami. Moduł uruchamia proces dla aplikacji ASP.NET Core po przybyciu pierwszego żądania i uruchamia ponownie aplikację, jeśli zostanie zamknięta lub ulega awarii. Jest to zasadniczo takie samo zachowanie jak w przypadku aplikacji uruchamianych w procesie, które są zarządzane przez usługę Windows Process Activation Service (WAS).

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:

ASP.NET Core Moduł w scenariuszu hostingu poza procesem

  1. Żądania docierają z Internetu do trybu jądra HTTP.sys sterownika.
  2. Sterownik kieruje żądania do usług IIS na skonfigurowanym porcie witryny internetowej. Skonfigurowany port to zwykle 80 (HTTP) lub 443 (HTTPS).
  3. Moduł przekazuje żądania do usługi Kestrel na losowym porcie dla aplikacji. Losowy port nie jest portem 80 ani 443.

Moduł ASP.NET Core określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania. Rozszerzenie UseIISIntegration konfiguruje serwer do nasłuchiwać w 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 zostały odebrane przez usługi IIS za pośrednictwem protokołu HTTPS.

Po odebraniu żądania z modułu żądanie jest przekazywane do potoku Kestrel oprogramowania ASP.NET Core pośredniczącego. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako HttpContext wystąpienie do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację usług IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazywanie żądania do Kestrel usługi . Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które przekazuje ją z powrotem do klienta HTTP, który zainicjował żądanie.

Aby ASP.NET Core konfiguracji modułu, zobacz Moduł ASP.NET Core .

Aby uzyskać więcej informacji na temat hostingu, zobacz Host w ASP.NET Core.

Konfiguracja aplikacji

Włączanie składników IISIntegration

Podczas budowania hosta w CreateHostBuilder programie ( Program.cs ) wywołaj funkcję CreateDefaultBuilder , aby włączyć integrację usług IIS:

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

Aby uzyskać więcej informacji na CreateDefaultBuilder temat , zobacz Ogólny host .NET w programie ASP.NET Core .

Opcje usług IIS

Model hostingu w procesie

Aby skonfigurować opcje serwera usług IIS, uwzględnij konfigurację usługi dla programu IISServerOptions w programie ConfigureServices . Poniższy przykład wyłącza automaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true , serwer usług IIS ustawia HttpContext.User uwierzytelniony przez usługę Windows uwierzytelniania. Jeśli , serwer udostępnia tylko tożsamość dla i odpowiada na false HttpContext.User wyzwania, gdy jawnie zażądane przez AuthenticationScheme . Windows Aby można było działać, w usługach IIS musi AutomaticAuthentication być włączone uwierzytelnianie. Aby uzyskać więcej informacji, zobacz Windows Authentication (Uwierzytelnianie).
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.
AllowSynchronousIO false Określa, czy synchroniczne we/wy są dozwolone dla HttpContext.Request i HttpContext.Response .
MaxRequestBodySize 30000000 Pobiera lub ustawia maksymalny rozmiar treści żądania dla HttpRequest . Należy pamiętać, że same program IIS ma maxAllowedContentLength limit, który będzie przetwarzany przed MaxRequestBodySize ustawieniem w obiekcie IISServerOptions . Zmiana MaxRequestBodySize nie wpłynie na . maxAllowedContentLength Aby zwiększyć maxAllowedContentLength wartość , dodaj wpis w do ustawić na web.config maxAllowedContentLength wyższą wartość. Aby uzyskać więcej informacji, zobacz Konfiguracja.

Model hostingu poza procesem

Aby skonfigurować opcje usług IIS, uwzględnij konfigurację usługi dla programu IISOptions w programie ConfigureServices . Poniższy przykład uniemożliwia wypełnienie aplikacji HttpContext.Connection.ClientCertificate :

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true , oprogramowanie pośredniczące integracji usług IIS HttpContext.User ustawia uwierzytelnione przez Windows uwierzytelniania. Jeśli element , oprogramowanie pośredniczące dostarcza tylko tożsamość dla usługi i reaguje na wyzwania w przypadku false HttpContext.User jawnego zażądania przez . AuthenticationScheme Windows Aby można było działać, w usługach IIS musi AutomaticAuthentication być włączone uwierzytelnianie. Aby uzyskać więcej informacji, zobacz Windows Authentication (Uwierzytelnianie użytkowników).
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.
ForwardClientCertificate true Jeśli true w MS-ASPNETCORE-CLIENTCERT nagłówku żądania znajduje się nagłówek , pole HttpContext.Connection.ClientCertificate jest wypełniane.

Scenariusze serwera proxy i usługi równoważenia obciążenia

Oprogramowanie pośredniczące integracji usług IIS i moduł ASP.NET Core są skonfigurowane do przekazywania dalej:

  • Schemat (HTTP/HTTPS).
  • Zdalny adres IP, z którego pochodzi żądanie.

Oprogramowanie pośredniczące integracji usług IIS konfiguruje oprogramowanie pośredniczące Przekazane nagłówki.

W przypadku aplikacji hostowanych za dodatkowymi serwerami proxy i usługami równoważenia obciążenia może być wymagana dodatkowa konfiguracja. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami równoważenia obciążenia.

web.config Plik

Plik web.config konfiguruje moduł ASP.NET Core module. Tworzenie, przekształcanie i publikowanie pliku jest obsługiwane przez docelowy MSBuild ( ) podczas web.config _TransformWebConfig publikowania projektu. Ten element docelowy znajduje się w elementach docelowych zestawu SDK sieci Web ( Microsoft.NET.Sdk.Web ). Zestaw SDK jest ustawiany w górnej części pliku projektu:

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

Jeśli w projekcie nie ma pliku, zostanie on utworzony z poprawnym plikiem i w celu skonfigurowania modułu ASP.NET Core Module i przeniesiony do web.config processPath arguments opublikowanych danych wyjściowych.

Jeśli plik znajduje się w projekcie, plik jest przekształcany z poprawną i w celu skonfigurowania modułu ASP.NET Core module i przenoszony web.config processPath do arguments 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, które kontrolują aktywne moduły usług IIS. Aby uzyskać informacje na temat modułów usług IIS, które mogą przetwarzać żądania za pomocą ASP.NET Core, zobacz temat Moduły usług IIS.

Aby zapobiec przekształcaniu pliku przez internetowy zestaw SDK, użyj web.config właściwości w pliku <IsTransformWebConfigDisabled> projektu:

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

Podczas wyłączania zestawu SDK sieci Web z przekształcania pliku, processPath i arguments powinny być ustawiane ręcznie przez dewelopera. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.

web.config lokalizacja pliku

Aby poprawnie skonfigurować moduł ASP.NET Core, plik musi znajdować się w ścieżce katalogu głównego zawartości (zazwyczaj ścieżce podstawowej web.config aplikacji) wdrożonej aplikacji. Jest to ta sama lokalizacja co ścieżka fizyczna witryny internetowej dostarczana do usług IIS. Plik jest wymagany w katalogu głównym aplikacji, aby umożliwić publikowanie wielu aplikacji przy użyciu web.config Web Deploy.

Na ścieżce fizycznej aplikacji istnieją poufne pliki, takie jak , (komentarze dokumentacji XML) i , gdzie symbol zastępczy {ASSEMBLY}.runtimeconfig.json {ASSEMBLY}.xml jest nazwą {ASSEMBLY}.deps.json {ASSEMBLY} zestawu. Gdy plik jest obecny, a witryna jest uruchamiana normalnie, usługi IIS nie obsługują tych poufnych plików, jeśli web.config są one żądane. Jeśli brakuje pliku, jest on niepoprawnie nazwany lub nie można skonfigurować lokacji do normalnego uruchamiania, usługi IIS mogą publicznie obsługiwać web.config poufne pliki.

Plik musi być obecny we wdrożeniu przez cały czas, poprawnie nazwany i może skonfigurować lokację web.config do normalnego uruchamiania. Nigdy nie usuwaj web.config pliku z wdrożenia produkcyjnego.

Przekształcanie pliku web.config

Jeśli musisz przekształcić dane web.config podczas publikowania, zobacz Przekształcanie pliku web.config . Może być konieczne przekształcenie podczas web.config publikowania, aby ustawić zmienne środowiskowe na podstawie konfiguracji, profilu lub środowiska.

Konfiguracja usług IIS

Windows Systemy operacyjne serwera

Włącz rolę serwera sieci Web (IIS) i ustanów usługi roli.

  1. Użyj kreatora Dodaj role i funkcje z menu Zarządzaj lub linku w Menedżer serwera . W kroku Role serwera zaznacz pole wyboru Serwer sieci Web (IIS).

    Rola usług IIS serwera sieci Web jest zaznaczona w kroku Wybieranie ról serwera.

  2. Po kroku Funkcje krok Usługi ról jest ładowany dla serwera sieci Web (IIS). Wybierz żądane usługi ról IIS lub zaakceptuj domyślne usługi ról.

    Domyślne usługi ról są wybierane w kroku Wybieranie usług ról.

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

    WebSockets (opcjonalnie)
    Urządzenia WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć funkcję WebSocket, rozwiń następujące węzły: Web Server > Application Development. 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 serwera sieci Web (IIS).

Windows operacyjnych dla komputerów stacjonarnych

Włącz konsolę zarządzania usługami IIS i World Wide Web usług .

  1. Przejdź do Panel sterowania programy i funkcje Windows włączać i wyłączać funkcje > > > (po lewej stronie ekranu).

  2. Otwórz Internet Information Services węzeł. Otwórz węzeł Narzędzia do zarządzania siecią Web.

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

  4. Zaznacz pole wyboru dla usługi World Wide Web Services.

  5. Zaakceptuj domyślne funkcje usług World Wide Web Services lub dostosuj funkcje usług IIS.

    Windows Uwierzytelnianie (opcjonalne)
    Aby włączyć Windows, rozwiń następujące węzły: World Wide Web Services > Security. Wybierz funkcję Windows uwierzytelniania. Aby uzyskać więcej informacji, zobacz <windowsAuthentication> Windows Authentication (Uwierzytelnianie) i Configure Windows authentication (Konfigurowanie Windows uwierzytelniania).

    WebSockets (opcjonalnie)
    Urządzenia WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć funkcję WebSockets, rozwiń następujące węzły: World Wide Web Services Application > Development Features. Wybierz funkcję Protokół WebSocket. Aby uzyskać więcej informacji, zobacz WebSockets.

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

Konsola zarządzania usługami IIS i World Wide Web usługi są wybrane w Windows funkcje.

Instalowanie pakietu hostingu .NET Core

Zainstaluj pakiet hostingowy .NET Core w systemie hostingu. Pakiet instaluje środowisko uruchomieniowe .NET Core, bibliotekę .NET Core i moduł ASP.NET Core . Moduł umożliwia uruchamianie ASP.NET Core za usługami IIS.

Ważne

Jeśli pakiet hostingowy jest zainstalowany przed usługami IIS, instalacja pakietu musi zostać naprawiona. Uruchom ponownie instalator pakietu hostingu po zainstalowaniu usług IIS.

Jeśli pakiet hostingowy został zainstalowany po zainstalowaniu 64-bitowej wersji (x64) programu .NET Core, może się wydawać, że brakuje zestawów SDK (nie wykryto zestawówSDK .NET Core). Aby rozwiązać ten problem, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Bezpośrednie pobieranie (bieżąca wersja)

Pobierz instalatora, korzystając z następującego linku:

Bieżący instalator pakietu hostingowego .NET Core (pobieranie bezpośrednie)

Wcześniejsze wersje instalatora

Aby uzyskać wcześniejszą wersję instalatora:

  1. Przejdź do strony Pobierz program .NET Core.
  2. Wybierz odpowiednią wersję programu .NET Core.
  3. W kolumnie Run apps - Runtime (Uruchamianie aplikacji — środowisko uruchomieniowe) znajdź wiersz odpowiedniej wersji środowiska uruchomieniowego .NET Core.
  4. Pobierz instalatora, korzystając z linku Do pakietu hostingu.

Ostrzeżenie

Niektóre instalatory zawierają wersje wersji, które zakończyły okres eksploatacji (EOL) i nie są już obsługiwane przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej.

Instalowanie pakietu hostingu

  1. Uruchom instalatora na serwerze. Podczas uruchamiania instalatora z powłoki poleceń administratora są dostępne następujące parametry:

    • OPT_NO_ANCM=1: Pomiń instalowanie ASP.NET Core modułu.
    • OPT_NO_RUNTIME=1: Pomiń instalowanie środowiska uruchomieniowego .NET Core. Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD, self-contained deployments).
    • OPT_NO_SHAREDFX=1: Pomiń instalowanie ASP.NET Shared Framework (ASP.NET runtime). Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD, self-contained deployments).
    • OPT_NO_X86=1: Pomiń instalowanie środowisk uruchomieniowych x86. Użyj tego parametru, jeśli wiesz, że nie będziesz hostował aplikacji 32-bitowych. Jeśli istnieje możliwość hostowania w przyszłości aplikacji 32-bitowych i 64-bitowych, nie używaj tego parametru i instaluj obu środowisk uruchomieniowych.
    • OPT_NO_SHARED_CONFIG_CHECK=1: wyłącz sprawdzanie użycia konfiguracji udostępnionej usług IIS, gdy udostępniona konfiguracja ( ) znajduje się na tej samej maszynie co applicationHost.config instalacja usług IIS. Dostępne tylko dla ASP.NET Core instalatorów pakietu hostingu w wersji 2.2 lub nowszej. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.
  2. Ponowne uruchomienie usług IIS powoduje zmianę ścieżki systemowej, która jest zmienną środowiskową, dokonaną przez instalatora. Aby ponownie uruchomić serwer sieci Web, zatrzymaj usługę Windows Process Activation Service (WAS), a następnie uruchom ponownie usługę World Wide Web Publishing Service (W3SVC). Uruchom ponownie system lub wykonaj następujące polecenia w powłoki poleceń z podwyższonym poziomem uprawnień:

    net stop was /y
    net start w3svc
    

ASP.NET Core nie przyjmuje zachowania roll-forward dla wydań poprawek udostępnionych pakietów struktury. Po uaktualnieniu udostępnionej struktury przez zainstalowanie nowego pakietu hostingu uruchom ponownie system lub wykonaj następujące polecenia w powłoki 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 ASP.NET Core Module with IIS Shared Configuration (Modułkonfiguracji udostępnionej usług IIS).

Instalowanie Web Deploy podczas publikowania za pomocą Visual Studio

Podczas wdrażania aplikacji na serwerach Web Deploy programzainstaluj najnowszą wersję Web Deploy na serwerze. Aby zainstalować Web Deploy, użyj Instalatora platformy sieci Web (WebPI) lub uzyskaj instalatora bezpośrednio z Centrum pobierania Microsoft. Preferowaną metodą jest użycie interfejsu WebPI. Interfejs WebPI oferuje autonomiczną konfigurację i konfigurację dostawców hostingu.

Tworzenie witryny usług IIS

  1. W systemie hostingu utwórz folder zawierający opublikowane foldery i pliki aplikacji. W poniższym kroku ścieżka folderu jest dostarczana do usług IIS jako ścieżka fizyczna do aplikacji. Aby uzyskać więcej informacji na temat folderu wdrożenia aplikacji i układu pliku, zobacz ASP.NET Core struktury katalogów .

  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ą na folder wdrożenia aplikacji. Podaj konfigurację powiązania i utwórz witrynę internetową, wybierając przycisk OK:

    W kroku Dodawanie witryny sieci Web należy podać nazwę lokacji, ścieżkę fizyczną i nazwę hosta.

    Ostrzeżenie

    Powiązań najwyższego poziomu z symbolami wieloznacznych ( http://*:80/ i ) nie http://+:80 należy używać. Powiązania najwyższego poziomu z symbolami wieloznacznymi mogą otworzyć aplikację na luki w zabezpieczeniach. Dotyczy to zarówno silnych, jak i słabych symboli wieloznacznych. Używaj jawnych nazw hostów zamiast symboli wieloznacznych. Powiązanie z symbolami wieloznacznymi poddomeny (na przykład ) nie stanowi takiego zagrożenia dla bezpieczeństwa, jeśli kontrolujesz całą domenę nadrzędną (w przeciwieństwie do domeny , która *.mysub.com *.com jest podatna na zagrożenia). Aby uzyskać więcej informacji, zobacz sekcję rfc7230 section-5.4.

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

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

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

    Ustaw wartość Brak kodu zarządzanego dla wersji .NET CLR.

    ASP.NET Core jest uruchamiany w osobnym procesie i zarządza środowiskiem uruchomieniowym. ASP.NET Core nie polega na ładowaniu klasycznego clr (.NET CLR). Podstawowe środowisko uruchomieniowe języka wspólnego (CoreCLR) dla programu .NET Core jest uruchamiane w celu hostowania aplikacji w procesie procesu roboczego. Ustawienie wersji .NET CLR na Wartość Brak kodu zarządzanego jest opcjonalne, ale zalecane.

  7. ASP.NET Core 2.2 lub nowszego:

    • W przypadku samodzielnego wdrożenia 32-bitowego (x86) opublikowanego przy użyciu 32-bitowego zestawu SDK, który korzysta z modelu hostowaniaw procesie, włącz pulę aplikacji dla 32-bitowego. W Menedżerze usług IIS przejdź do puli aplikacji na pasku bocznym Połączenia. Wybierz pulę aplikacji aplikacji. Na pasku bocznym Akcje wybierz pozycję Zaawansowane Ustawienia. Ustaw opcję Włącz aplikacje 32-bitowe na wartość True .

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

  8. Potwierdź, że tożsamość modelu procesu ma odpowiednie uprawnienia.

    Jeśli domyślna tożsamość puli aplikacji (model procesu) zostanie zmieniona z > Identity Puli Identity aplikacji na inną, sprawdź, czy nowa tożsamość ma wymagane uprawnienia dostępu do folderu aplikacji, bazy danych i innych wymaganych zasobów. Na przykład pula aplikacji wymaga dostępu do odczytu i zapisu do folderów, w których aplikacja odczytuje i zapisuje pliki.

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

Wdrażanie aplikacji

Wd wdrażaj aplikację w folderze ścieżka fizyczna usług IIS, który został ustanowionych w sekcji Tworzenie witryny usług IIS. Web Deploy jest zalecanym mechanizmem wdrażania, ale istnieje kilka opcji przenoszenia aplikacji z folderu projektu do publish folderu wdrożenia systemu hostingu.

Web Deploy z Visual Studio

Zobacz temat Visual Studio publikowania profilów dla aplikacji ASP.NET Core, aby dowiedzieć się, jak utworzyć profil publikowania do użycia z Web Deploy. Jeśli dostawca hostingu zapewnia profil publikowania lub obsługuje jego tworzenie, pobierz jego profil i zaimportuj go przy użyciu Visual Studio publikowania:

Strona okna dialogowego Publikowanie

Web Deploy poza Visual Studio

Web Deploy można również używać poza Visual Studio z wiersza polecenia. Aby uzyskać więcej informacji, zobacz Web Deployment Tool.

Alternatywy dla Web Deploy

Aby przenieść aplikację do systemu hostingu, użyj dowolnej z kilku metod, takich jak kopiowanie ręczne, Xcopy, Robocopylub PowerShell.

Aby uzyskać więcej informacji na ASP.NET Core wdrażania 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 należy wykonać żą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 www.mysite.com porcie 80 . Żądanie jest dokonywane do http://www.mysite.com :

Przeglądarka Microsoft Edge załadowała stronę startową usług IIS.

Zablokowane pliki wdrożenia

Pliki w folderze wdrożenia są blokowane, gdy aplikacja jest uruchomiona. Zablokowanych plików nie można nadpisać podczas wdrażania. Aby zwolnić zablokowane pliki we wdrożeniu, zatrzymaj pulę aplikacji przy użyciu jednej z następujących metod:

  • Użyj Web Deploy i Microsoft.NET.Sdk.Web odwołania w pliku projektu. Plik app_offline.htm jest umieszczany w katalogu głównym katalogu aplikacji internetowej. Gdy plik jest obecny, moduł ASP.NET Core bezpiecznie zamyka aplikację i obsługuje app_offline.htm plik podczas wdrażania. Aby uzyskać więcej informacji, zobacz ASP.NET Core konfiguracji modułu .

  • 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 ASP.NET Core ochrony danych jest używany przez kilka ASP.NET Core pośredniczącego,w tym oprogramowanie pośredniczące używane do uwierzytelniania. Nawet jeśli interfejsy API ochrony danych nie są wywoływane przez kod użytkownika, ochronę danych należy skonfigurować za pomocą skryptu wdrażania lub kodu 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 jest przechowywany w pamięci po ponownym uruchomieniu aplikacji:

  • Wszystkie cookie tokeny uwierzytelniania oparte na systemie są unieważniane.
  • Użytkownicy muszą zalogować się ponownie przy następnym żądaniu.
  • 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 cookie s.

Aby skonfigurować ochronę danych w usługach 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 ASP.NET Core są przechowywane w rejestrze poza aplikacjami. Aby utrwalić klucze dla danej aplikacji, utwórz klucze rejestru dla puli aplikacji.

    W przypadku autonomicznych instalacji usług IIS innych niż webfarm skrypt programu PowerShell usługi Data Protection Provision-AutoGenKeys.ps1 może być używany dla każdej puli aplikacji używanej z ASP.NET Core aplikacji. Ten skrypt tworzy klucz rejestru w rejestrze HKLM, który jest dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane podczas spoczynku przy użyciu dpapi z kluczem dla całej maszyny.

    W scenariuszach farmy sieci Web aplikację można skonfigurować do używania ścieżki UNC do przechowywania pierścienia klucza ochrony danych. Domyślnie klucze ochrony danych nie są szyfrowane. Upewnij się, że uprawnienia do plików udziału sieciowego są ograniczone do Windows, w ramach których działa aplikacja. Certyfikat X509 może służyć do ochrony kluczy w spoczynku. 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. Zobacz Konfigurowanie ASP.NET Core ochrony danych, aby uzyskać szczegółowe informacje.

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

    To ustawienie znajduje się w sekcji Model procesu w sekcji Ustawienia dla puli aplikacji. Dla ustawienia Załaduj profil użytkownika ustaw wartość True . W przypadku ustawienia na wartość klucze są przechowywane w katalogu profilu użytkownika i chronione przy użyciu interfejsu DPAPI z kluczem True 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 setProfileEnvironment to true . W niektórych scenariuszach (na przykład w Windows systemu operacyjnego) wartość setProfileEnvironment jest ustawiona na 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 applicationHost.config plik.
    3. Znajdź <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element .
    4. Upewnij się, że atrybut nie jest obecny ( wartość domyślna to , lub jawnie ustaw setProfileEnvironment true 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ścieni kluczy. Użyj certyfikatu X509, aby chronić pierścień kluczy i upewnić się, że certyfikat jest zaufany. Jeśli certyfikat ma podpis własny, umieść go w zaufanym magazynie głównym.

    W przypadku korzystania z usług IIS w farmie sieci Web:

    • Użyj udziału plików dostępnego dla wszystkich maszyn.
    • Wd wdrażać certyfikat X509 na każdej maszynie. Konfigurowanie ochrony danych w kodzie.
  • Ustawianie zasad ochrony danych na całym komputerze

    System ochrony danych ma ograniczoną obsługę ustawiania domyślnych zasad dla całej maszyny dla wszystkich aplikacji, które zużywają interfejsy API ochrony danych. Aby uzyskać więcej informacji, zobacz ASP.NET Core Ochrona danych.

Katalogi wirtualne

Katalogi wirtualne usług IIS nie są obsługiwane w przypadku ASP.NET Core wirtualnych. Aplikacja może być hostowana jako aplikacja podrzędna.

Aplikacje podrzędne

Aplikacja ASP.NET Core może być hostowana jako aplikacja podrzędna usług IIS (aplikacja podrzędna). Ś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 tyldy-ukośnika ( ~/ ). Notacja tyldy-ukośnika wyzwala pomocnika tagów, aby dołączał bazę ścieżek aplikacji podrzędnej do renderowanego linku względnego. W przypadku aplikacji podrzędnej w pliku /subapp_path obraz połączony z src="~/image.png" elementem jest renderowany jako src="/subapp_path/image.png" . Oprogramowanie pośredniczące pliku statycznego aplikacji głównej nie przetwarza żądania pliku statycznego. Żądanie jest przetwarzane przez oprogramowanie pośredniczące pliku statycznego aplikacji podrzędnej.

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

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

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

  2. Dodaj witrynę główną w Menedżerze usług IIS z podaną aplikacją w folderze w ramach lokacji 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 w procesie.

Aby uzyskać więcej informacji na temat modelu hostingu w procesie i konfigurowania modułu ASP.NET Core, zobacz Moduł ASP.NET Core .

Konfiguracja usług IIS z web.config

Na konfigurację usług IIS ma wpływ sekcjaweb.configdla scenariuszy usług IIS, które są funkcjonalne ASP.NET Core aplikacji za pomocą <system.webServer> ASP.NET Core module. Na przykład konfiguracja usług IIS działa w przypadku kompresji dynamicznej. Jeśli usługi IIS są skonfigurowane na poziomie serwera do korzystania z kompresji dynamicznej, element w plikuweb.configaplikacji może go wyłączyć dla <urlCompression> ASP.NET Core aplikacji.

Aby uzyskać więcej informacji, zobacz następujące tematy:

Aby ustawić zmienne środowiskowe dla poszczególnych aplikacji uruchomionych w izolowanych pulach aplikacji (obsługiwanych w usługach IIS 10.0 lub nowszych), zobacz sekcję polecenia usługi AppCmd.exe w temacie Zmienne <environmentVariables> środowiskowe w dokumentacji referencyjnej usług IIS.

Sekcje, które nie są używane przez ASP.NET Core

Sekcje konfiguracji ASP.NET aplikacji w web.config nie są używane przez ASP.NET Core do konfiguracji:

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

ASP.NET Core są konfigurowane przy użyciu innych dostawców konfiguracji. Aby uzyskać więcej informacji, zobacz Configuration and .NET Core run-time configuration settings (Konfiguracja i ustawienia konfiguracji uruchomieniowej programu .NET Core)

Pule aplikacji

Izolacja puli aplikacji jest określana przez model hostingu:

  • Hosting w procesie: aplikacje muszą być uruchamiane w oddzielnych pulach aplikacji.
  • Hosting poza procesem: zalecamy izolowanie aplikacji od siebie, uruchamiając każdą aplikację w własnej puli aplikacji.

W oknie dialogowym Dodawanie witryny sieci Web usług IIS domyślnie domyślną pulą aplikacji na aplikację. Po podaniem nazwy lokacji 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 na unikatowym koncie bez konieczności tworzenia domen i kont lokalnych oraz zarządzania nimi. W usługach IIS 8.0 lub nowszych proces roboczy administratora usług IIS 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 Ustawienia Zaawansowane dla puli aplikacji upewnij się, że w obszarze jest ustawiona Identity wartość ApplicationPool: Identity

Okno dialogowe ustawień zaawansowanych puli aplikacji

Proces zarządzania usługami IIS tworzy bezpieczny identyfikator o nazwie puli aplikacji w Zabezpieczenia Windows System. Zasoby można zabezpieczyć przy użyciu tej tożsamości. Jednak ta tożsamość nie jest rzeczywistym kontem użytkownika i nie jest pokazywana w Windows zarządzania użytkownikami.

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

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

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

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

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

  5. Wprowadź IIS AppPool\{APP POOL NAME} wartość , gdzie symbol zastępczy jest nazwą puli aplikacji, w obszarze Wprowadź nazwy obiektów do {APP POOL NAME} wybrania. Wybierz przycisk Sprawdź nazwy. W przypadku puli DefaultAppPool sprawdź nazwy przy IIS AppPool\DefaultAppPool użyciu . Po wybraniu przycisku Sprawdź nazwy w obszarze nazw obiektów jest wskazana DefaultAppPool wartość . 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 jest nazwą puli aplikacji podczas sprawdzania nazwy {APP POOL NAME} obiektu.

    Okno dialogowe wybierania użytkowników lub grup dla folderu aplikacji: nazwa puli aplikacji "DefaultAppPool" jest dołączana do puli aplikacji usług IIS w obszarze nazw obiektów przed wybraniem opcji " "Sprawdź nazwy".

  6. Wybierz przycisk OK.

    Okno dialogowe Wybieranie użytkowników lub grup dla folderu aplikacji: po wybraniu opcji "Sprawdź nazwy" nazwa obiektu "DefaultAppPool" jest wyświetlana w obszarze nazw obiektów.

  7. Uprawnienia & do wykonywania odczytu powinny być przyznawane domyślnie. W razie potrzeby podaj dodatkowe uprawnienia.

Dostęp można również przyznać w wierszu polecenia za pomocą narzędzia ICACLS. Jako DefaultAppPool przykładu 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 ASP.NET Core w następujących scenariuszach wdrażania usług IIS:

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

W przypadku wdrożenia w procesie po nawiązaniu połączenia HTTP/2 program HttpRequest.Protocol zgłasza błąd HTTP/2 . W przypadku wdrożenia poza procesem po nawiązaniu połączenia HTTP/2 program HttpRequest.Protocol zgłasza błąd HTTP/1.1 .

Aby uzyskać więcej informacji na temat modeli hostowania w procesie i poza procesem, zobacz Moduł ASP.NET Core .

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

Żądania wstępne CORS

Ta sekcja dotyczy tylko ASP.NET Core aplikacji docelowych .NET Framework.

W przypadku ASP.NET Core aplikacji, która jest .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 programie w celu przekazania żądań OPTIONS, zobacz Enable web.config cross-origin requests in ASP.NET Web API 2: How CORS Works(Włączanie żądań między źródłami w interfejsie ASP.NET Web API 2: jak działa cors).

Moduł inicjowania aplikacji i limit czasu bezczynności

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

  • Moduł inicjowania aplikacji:hostowaną w procesie lub poza procesem aplikację można skonfigurować do automatycznego uruchamiania po ponownym uruchomieniu procesu roboczego lub ponownym uruchomieniu serwera.
  • Limit czasu bezczynności:hostowaną w procesie aplikację można skonfigurować tak, aby nie przeoczała limitu czasu w okresach braku aktywności.

Moduł inicjowania aplikacji

Dotyczy aplikacji hostowanych w procesie i poza procesem.

Inicjowanie aplikacji usług IIS to funkcja usług IIS, która wysyła żądanie HTTP do aplikacji, gdy pula aplikacji jest uruchamiana lub odzyskiwana. Żądanie wyzwala uruchomienie aplikacji. Domyślnie usługi IIS wyślą żądanie do głównego adresu URL aplikacji () w celu zainicjowania aplikacji (zobacz dodatkowe zasoby, aby uzyskać więcej informacji / na temat konfiguracji).

Upewnij się, że włączono funkcję roli inicjowania aplikacji usług IIS:

W Windows 7 lub nowszych w przypadku lokalnego korzystania z usług IIS:

  1. Przejdź do Panel sterowania programy i funkcje Windows włączać lub wyłączać > > > funkcje (po lewej stronie ekranu).
  2. Otwórz Internet Information Services > World Wide Web Services Application Development > Features.
  3. Zaznacz pole wyboru inicjowania aplikacji.

Na Windows Server 2008 R2 lub nowszy:

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

Aby włączyć moduł inicjowania aplikacji dla lokacji, użyj jednej z następujących metod:

  • Korzystanie z Menedżera usług IIS:

    1. Wybierz pozycję Pule aplikacji w panelu Połączenia.
    2. Kliknij prawym przyciskiem myszy pulę aplikacji aplikacji na liście i wybierz pozycję Zaawansowane Ustawienia.
    3. Domyślny tryb uruchamiania to OnDemand. W trybie uruchamiania ustaw wartość AlwaysRunning. Wybierz przycisk OK.
    4. Otwórz węzeł Lokacje w panelu Połączenia.
    5. Kliknij prawym przyciskiem myszy aplikację i wybierz pozycję Zarządzaj witryną internetową > Zaawansowane Ustawienia.
    6. Domyślne ustawienie Wstępne ładowanie włączone ma wartość Fałsz. Dla ustawienia Wstępne ładowanie włączone ustaw wartość True. Wybierz przycisk OK.
  • Za web.config pomocą elementu dodaj element z <applicationInitialization> doAppInitAfterRestart elementem o ustawionym na do elementów w pliku true " web.config<system.webServer> 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 w procesie.

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 aplikacji na liście i wybierz pozycję Zaawansowane Ustawienia.
  3. Domyślny limit czasu bezczynności (minuty) wynosi 20 minut. Ustaw wartość 0 (zero) dla wartości Time-out (minutes) (Czas bezczynności w minutach). Wybierz przycisk OK.
  4. Odtąd odtąd proces roboczy.

Aby zapobiec przechyłoceniu 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 zapewnić jej działanie.
  • Jeśli aplikacja hostuje tylko usługi w tle, należy unikać hostowania usług IIS i używać usługi Windows Service do hostowania ASP.NET Core aplikacji.

Dodatkowe zasoby dotyczące modułu inicjowania aplikacji i limitu czasu bezczynności

Zasoby wdrażania dla administratorów usług IIS

Dodatkowe zasoby

Aby uzyskać informacje na temat publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS .

Instalowanie pakietu hostingu .NET Core

Obsługiwane systemy operacyjne

Obsługiwane są następujące systemy operacyjne:

  • Windows 7 lub nowszy
  • Windows Server 2008 R2 lub nowszy

HTTP.sys serwera proxy (dawniej WebListener) nie działa w konfiguracji zwrotnego serwera proxy z usługami IIS. Użyj Kestrel serwera.

Aby uzyskać informacje na temat hostingu na platformie Azure, zobacz Wdróż aplikacje ASP.NET Core w Azure App Service .

Aby uzyskać wskazówki dotyczące rozwiązywania problemów, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Obsługiwane platformy

Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wd wdrażaj aplikację 32-bitową z 32-bitową (x86) zestaw .NET Core SDK 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 natywne zależności 64-bitowe.

Użyj wersji 64-bitowej (x64) zestaw .NET Core SDK publikowania aplikacji 64-bitowej. W systemie hosta musi być obecne 64-bitowe środowisko uruchomieniowe.

Modele hostingu

Model hostingu w procesie

Przy użyciu hostingu w procesie aplikacja ASP.NET Core działa w tym samym procesie co proces roboczy usług IIS. Hosting w procesie zapewnia lepszą wydajność niż hosting poza procesem, ponieważ:

  • Żądania nie są proxied przez adapter sprzężenia zwrotnego. Karta sprzężenia zwrotnego to interfejs sieciowy, który zwraca wychodzący ruch sieciowy z powrotem do tej samej maszyny.

Usługi IIS obsługują zarządzanie procesami za pomocą Windows Process Activation Service (WAS).

Moduł ASP.NET Core:

  • Wykonuje inicjowanie aplikacji.
    • Ładuje program CoreCLR.
    • Wywołuje Program.Main .
  • Obsługuje okres istnienia natywnego żądania usług IIS.

Model hostingu w procesie nie jest obsługiwany w przypadku ASP.NET Core docelowych aplikacji .NET Framework.

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną w procesie:

ASP.NET Core Moduł w scenariuszu hostingu w procesie

Żądanie jest docierane z Internetu do trybu jądra HTTP.sys sterownika. Sterownik kieruje żądanie natywne do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS). Moduł ASP.NET Core odbiera żądanie natywne i przekazuje je do serwera HTTP usług IIS ( IISHttpServer ). Serwer HTTP usług IIS to implementacja serwera przetwarzania dla usług IIS, która konwertuje żądanie z natywnego na zarządzane.

Gdy serwer HTTP usług IIS przetwarza żądanie, żądanie jest wypychane do potoku ASP.NET Core pośredniczącego. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako HttpContext wystąpienie do 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 w procesie jest opt-in dla istniejących aplikacji, ale dotnet new templates default to model hostingu w procesie dla wszystkich usług IIS i IIS Express scenariuszy.

CreateDefaultBuilder dodaje wystąpienie, wywołując metodę w celu uruchomienia procesu IServer UseIIS CoreCLR i hostowania ** aplikacji wewnątrz ** procesu roboczego usług IIS (w3wp.exelubiisexpress.exe). Testy wydajności wskazują, że hostowanie aplikacji .NET Core w procesie zapewnia znacznie wyższą przepływność żądań w porównaniu z hostem aplikacji poza procesem i żądaniami proxy do Kestrel serwera.

Model hostingu poza procesem

Ponieważ ASP.NET Core są uruchamiane w procesie oddzielonym od procesu roboczego usług IIS, moduł ASP.NET Core obsługuje zarządzanie procesami. Moduł uruchamia proces dla aplikacji ASP.NET Core po przybyciu pierwszego żądania i uruchamia ponownie aplikację, jeśli zostanie zamknięta lub ulega awarii. Jest to zasadniczo takie samo zachowanie jak w przypadku aplikacji uruchamianych w procesie zarządzanych przez usługę Windows Process Activation Service (WAS).

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:

ASP.NET Core Moduł w scenariuszu hostingu poza procesem

Żądania docierają z Internetu do trybu jądra HTTP.sys sterownika. Sterownik kieruje żądania do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS). Moduł przekazuje żądania do aplikacji na losowym porcie, który nie jest Kestrel portem 80 ani 443.

Moduł określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania, a rozszerzenie UseIISIntegration konfiguruje serwer do nasłuchiwać na serwerze 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.

Po odebraniu żądania z modułu żądanie jest wypychane do potoku Kestrel ASP.NET Core pośredniczącego. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako HttpContext wystąpienie do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację usług IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazywanie żądania do Kestrel usługi . Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które wypychają ją z powrotem do klienta HTTP, który zainicjował żądanie.

Aby ASP.NET Core konfiguracji modułu, zobacz Moduł ASP.NET Core .

Aby uzyskać więcej informacji na temat hostingu, zobacz Host w ASP.NET Core.

Konfiguracja aplikacji

Włączanie składników IISIntegration

Podczas budowania hosta w CreateWebHostBuilder programie (Program.cs) wywołaj funkcję , CreateDefaultBuilder aby włączyć integrację usług IIS:

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

Aby uzyskać więcej informacji na CreateDefaultBuilder temat , zobacz ASP.NET Core Web Host .

Opcje usług IIS

Model hostingu w procesie

Aby skonfigurować opcje serwera usług IIS, uwzględnij konfigurację usługi dla programu IISServerOptions w programie ConfigureServices . Poniższy przykład wyłącza automaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true , serwer usług IIS ustawia HttpContext.User uwierzytelniony przez usługę Windows uwierzytelniania. Jeśli , serwer udostępnia tylko tożsamość dla i odpowiada na false HttpContext.User wyzwania, gdy jawnie zażądane przez AuthenticationScheme . Windows Aby można było działać, w usługach IIS musi AutomaticAuthentication być włączone uwierzytelnianie. Aby uzyskać więcej informacji, zobacz Windows Authentication (Uwierzytelnianie).
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.

Model hostingu poza procesem

Aby skonfigurować opcje usług IIS, uwzględnij konfigurację usługi dla programu IISOptions w programie ConfigureServices . Poniższy przykład uniemożliwia wypełnienie aplikacji HttpContext.Connection.ClientCertificate :

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true , oprogramowanie pośredniczące integracji usług IIS HttpContext.User ustawia uwierzytelnione przez usługę Windows uwierzytelniania. Jeśli element , oprogramowanie pośredniczące dostarcza tylko tożsamość dla usługi i reaguje na wyzwania w przypadku false HttpContext.User jawnego zażądania przez . AuthenticationScheme Windows Aby można było działać, w usługach IIS musi AutomaticAuthentication być włączone uwierzytelnianie. Aby uzyskać więcej informacji, zobacz Windows Authentication (Uwierzytelnianie użytkowników).
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.
ForwardClientCertificate true Jeśli true w MS-ASPNETCORE-CLIENTCERT nagłówku żądania znajduje się nagłówek , pole HttpContext.Connection.ClientCertificate jest wypełniane.

Scenariusze serwera proxy i usługi równoważenia obciążenia

Oprogramowanie pośredniczące integracji usług IIS, które konfiguruje oprogramowanie pośredniczące Nagłówki dalej, ASP.NET Core Module jest skonfigurowane do przekazywania schematu (HTTP/HTTPS) i zdalnego adresu IP, z którego pochodzi żądanie. W przypadku aplikacji hostowanych za dodatkowymi serwerami proxy i usługami równoważenia obciążenia może być wymagana dodatkowa konfiguracja. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami 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 MSBuild docelowy ( ) podczas _TransformWebConfig publikowania projektu. Ten element docelowy znajduje się w elementach docelowych zestawu SDK sieci Web ( Microsoft.NET.Sdk.Web ). Zestaw SDK jest ustawiany w górnej części pliku projektu:

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

Jeśli web.config nie ma pliku w projekcie, zostanie on utworzony z poprawną wartością processPath i argumentami w celu skonfigurowania modułu ASP.NET Core Module i przeniesiony do opublikowanych danych wyjściowych.

Jeśli web.config znajduje się w projekcie, plik jest przekształcany z poprawną wartością processPath i argumentami w celu skonfigurowania modułu ASP.NET Core Module i przenoszony 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, które kontrolują aktywne moduły usług IIS. Aby uzyskać informacje na temat modułów usług IIS, które mogą przetwarzać żądania za ASP.NET Core, zobacz temat Moduły usług IIS.

Aby zapobiec przekształcaniu plikuweb.config SDK sieci Web, użyj właściwości w <IsTransformWebConfigDisabled> pliku projektu:

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

W przypadku wyłączenia internetowego zestawu SDK z przekształcania pliku deweloper powinien ręcznie ustawić argumenty i processPath. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.

web.config lokalizacji pliku

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 dostarczana do usług IIS. Plik web.config jest wymagany w katalogu głównym aplikacji, aby umożliwić publikowanie wielu aplikacji przy użyciu Web Deploy.

Na ścieżce fizycznej aplikacji istnieją poufne pliki, takie jak pliki.runtimeconfig.js <assembly> , <assembly>.xml (komentarze dokumentacji XML) i.deps.js <assembly> na . Gdy plik web.config jest obecny, a witryna jest uruchamiana normalnie, usługi IIS nie obsługują tych poufnych plików, jeśli są żądane. Jeśli brakujeweb.config lub niepoprawnie nazwanego pliku albo nie można skonfigurować lokacji do normalnego uruchamiania, usługi IIS mogą publicznie obsługiwać poufne pliki.

Plik web.config musi być obecny we wdrożeniu przez cały czas, poprawnie nazwany i może skonfigurować lokację do normalnego uruchamiania. Nigdy nie usuwajweb.config z wdrożenia produkcyjnego.

Przekształcanie pliku web.config

Jeśli musisz przekształcić dane web.config publikowania (na przykład ustawić zmienne środowiskowe na podstawie konfiguracji, profilu lub środowiska), zobacz Przekształcanie pliku web.config .

Konfiguracja usług IIS

Windows Systemy operacyjne serwera

Włącz rolę serwera sieci Web (IIS) i ustanów usługi roli.

  1. Użyj kreatora Dodaj role i funkcje z menu Zarządzaj lub linku w Menedżer serwera . W kroku Role serwera zaznacz pole wyboru Serwer sieci Web (IIS).

    Rola usług IIS serwera sieci Web jest zaznaczona w kroku Wybieranie ról serwera.

  2. Po kroku Funkcje krok Usługi ról jest ładowany dla serwera sieci Web (IIS). Wybierz żądane usługi ról IIS lub zaakceptuj domyślne usługi ról.

    Domyślne usługi ról są wybierane w kroku Wybieranie usług ról.

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

    WebSockets (opcjonalnie)
    Urządzenia WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć funkcję WebSocket, rozwiń następujące węzły: Web Server > Application Development. 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 serwera sieci Web (IIS).

Windows operacyjnych dla komputerów stacjonarnych

Włącz konsolę zarządzania usługami IIS i World Wide Web usług .

  1. Przejdź do Panel sterowania programy i funkcje Windows włączać lub wyłączać > > > funkcje (po lewej stronie ekranu).

  2. Otwórz Internet Information Services węzeł. Otwórz węzeł Narzędzia do zarządzania siecią Web.

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

  4. Zaznacz pole wyboru obok World Wide Web Services.

  5. Zaakceptuj funkcje domyślne usług World Wide Web Services lub dostosuj funkcje usług IIS.

    Windows Uwierzytelnianie (opcjonalne)
    Aby włączyć Windows, rozwiń następujące węzły: World Wide Web Services > Security. Wybierz funkcję Windows uwierzytelniania. Aby uzyskać więcej informacji, zobacz <windowsAuthentication> Windows Authentication (Uwierzytelnianie) i Configure Windows authentication (Konfigurowanie Windows uwierzytelniania).

    WebSockets (opcjonalnie)
    Urządzenia WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć funkcję WebSockets, rozwiń następujące węzły: World Wide Web Services Application > Development Features. Wybierz funkcję Protokół WebSocket. Aby uzyskać więcej informacji, zobacz WebSockets.

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

Konsola zarządzania usługami IIS i World Wide Web usługi są wybrane w Windows funkcje.

Instalowanie pakietu hostingu .NET Core

Zainstaluj pakiet hostingowy .NET Core w systemie hostingu. Pakiet instaluje środowisko uruchomieniowe .NET Core, bibliotekę .NET Core i moduł ASP.NET Core . Moduł umożliwia uruchamianie ASP.NET Core za usługami IIS.

Ważne

Jeśli pakiet hostingowy jest zainstalowany przed usługami IIS, instalacja pakietu musi zostać naprawiona. Uruchom ponownie instalator pakietu hostingu po zainstalowaniu usług IIS.

Jeśli pakiet hostingowy został zainstalowany po zainstalowaniu 64-bitowej wersji (x64) programu .NET Core, może się wydawać, że brakuje zestawów SDK (nie wykryto zestawówSDK .NET Core). Aby rozwiązać ten problem, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Pobierz

  1. Przejdź do strony Pobierz program .NET Core.
  2. Wybierz odpowiednią wersję programu .NET Core.
  3. W kolumnie Run apps - Runtime (Uruchamianie aplikacji — środowisko uruchomieniowe) znajdź wiersz odpowiedniej wersji środowiska uruchomieniowego .NET Core.
  4. Pobierz instalatora, korzystając z linku Do pakietu hostingu.

Ostrzeżenie

Niektóre instalatory zawierają wersje wersji, które zakończyły okres eksploatacji (EOL) i nie są już obsługiwane przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej.

Instalowanie pakietu hostingu

  1. Uruchom instalatora na serwerze. Podczas uruchamiania instalatora z powłoki poleceń administratora są dostępne następujące parametry:

    • OPT_NO_ANCM=1: Pomiń instalowanie ASP.NET Core modułu.
    • OPT_NO_RUNTIME=1: Pomiń instalowanie środowiska uruchomieniowego .NET Core. Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD, self-contained deployments).
    • OPT_NO_SHAREDFX=1: Pomiń instalowanie ASP.NET Shared Framework (ASP.NET runtime). Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD, self-contained deployments).
    • OPT_NO_X86=1: Pomiń instalowanie środowisk uruchomieniowych x86. Użyj tego parametru, jeśli wiesz, że nie będziesz hostował aplikacji 32-bitowych. Jeśli istnieje możliwość hostowania w przyszłości aplikacji 32-bitowych i 64-bitowych, nie używaj tego parametru i instaluj obu środowisk uruchomieniowych.
    • OPT_NO_SHARED_CONFIG_CHECK=1: wyłącz sprawdzanie użycia 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 ASP.NET Core instalatorów pakietu hostingu w wersji 2.2 lub nowszej. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.
  2. Uruchom ponownie system lub wykonaj następujące polecenia w powłoki poleceń:

    net stop was /y
    net start w3svc
    

    Ponowne uruchomienie usług IIS powoduje zmianę ścieżki systemowej, która jest zmienną środowiskową, dokonaną przez instalatora.

Nie trzeba ręcznie zatrzymywać poszczególnych witryn w usługach IIS podczas instalowania pakietu hostingu. Hostowane aplikacje (witryny usług IIS) są ponownie uruchomione po ponownym uruchomieniu usług IIS. Aplikacje są ponownie uruchamiane po otrzymaniu pierwszego żądania, w tym z modułu inicjowania aplikacji.

ASP.NET Core przyjmuje zachowanie wsadowe dla wydań poprawek udostępnionych pakietów struktury. Po ponownym uruchomieniu aplikacji hostowanych przez usługi IIS z usługami 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ą wykazywać zachowanie w przyszłości, gdy procesy robocze zostaną odzyskane i otrzymają pierwsze żądanie.

Uwaga

Aby uzyskać informacje na temat konfiguracji udostępnionej usług IIS, zobacz ASP.NET Core Module with IIS Shared Configuration (Modułkonfiguracji udostępnionej usług IIS).

Instalowanie Web Deploy podczas publikowania za pomocą Visual Studio

Podczas wdrażania aplikacji na serwerach z Web Deploy programuzainstaluj najnowszą wersję Web Deploy na serwerze. Aby zainstalować Web Deploy, użyj Instalatora platformy internetowej (WebPI) lub uzyskaj instalatora bezpośrednio z Centrum pobierania Microsoft. Preferowaną metodą jest użycie interfejsu WebPI. Interfejs WebPI oferuje autonomiczną konfigurację i konfigurację dla dostawców hostingu.

Tworzenie witryny usług IIS

  1. W systemie hostingu utwórz folder zawierający opublikowane foldery i pliki aplikacji. W poniższym kroku ścieżka folderu jest dostarczana do usług IIS jako ścieżka fizyczna do aplikacji. Aby uzyskać więcej informacji na temat folderu wdrożenia aplikacji i układu pliku, zobacz ASP.NET Core struktury katalogów .

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

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

    W kroku Dodawanie witryny sieci Web należy podać nazwę lokacji, ścieżkę fizyczną i nazwę hosta.

    Ostrzeżenie

    Powiązań najwyższego poziomu z symbolami wieloznacznych ( http://*:80/ i ) nie http://+:80 należy używać. Powiązania najwyższego poziomu z symbolami wieloznacznymi mogą otworzyć aplikację na luki w zabezpieczeniach. Dotyczy to zarówno silnych, jak i słabych symboli wieloznacznych. Użyj jawnych nazw hostów zamiast symboli wieloznacznych. Powiązanie z symbolami wieloznacznymi poddomeny (na przykład ) nie stanowi zagrożenia dla bezpieczeństwa, jeśli kontrolujesz całą domenę nadrzędną (w przeciwieństwie do domeny *.mysub.com *.com narażonej na zagrożenia). Aby uzyskać więcej informacji, zobacz sekcję rfc7230 section-5.4.

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

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

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

    Ustaw wartość Brak kodu zarządzanego dla wersji .NET CLR.

    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), a środowisko — Core Common Language Runtime (CoreCLR) dla programu .NET Core jest uruchamiane w celu hostowania aplikacji w procesie procesu roboczego. Ustawienie wersji clr .NET na wartość Brak kodu zarządzanego jest opcjonalne, ale zalecane.

  7. ASP.NET Core 2.2 lub nowsze: w przypadku samodzielnego wdrożenia 64-bitowego (x64) korzystającego z modelu hostingu w procesie wyłącz pulę aplikacji dla 32-bitowych procesów (x86).

    Na pasku bocznym Akcje Menedżera usług IIS > pul aplikacji wybierz pozycję Ustaw wartości domyślne puli aplikacji lub Zaawansowane Ustawienia. Znajdź opcję Włącz aplikacje 32-bitowe i ustaw wartość na False . To ustawienie nie ma wpływu na aplikacje wdrożone do hostowania poza procesem.

  8. Potwierdź, że tożsamość modelu procesu ma odpowiednie uprawnienia.

    Jeśli domyślna tożsamość puli aplikacji (model procesu) zostanie zmieniona z > Identity Puli Identity aplikacji na inną tożsamość, sprawdź, czy nowa tożsamość ma uprawnienia wymagane do uzyskania dostępu do folderu aplikacji, bazy danych i innych wymaganych zasobów. Na przykład pula aplikacji wymaga dostępu do odczytu i zapisu do folderów, w których aplikacja odczytuje i zapisuje pliki.

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

Wdrażanie aplikacji

Wd wdrażaj aplikację w folderze ścieżki fizycznej usług IIS, który został ustalony w sekcji Tworzenie witryny usług IIS. Web Deploy jest zalecanym mechanizmem wdrażania, ale istnieje kilka opcji przenoszenia aplikacji z folderu publikowania projektu do folderu wdrożenia systemu hostingu.

Web Deploy z Visual Studio

Zobacz temat Visual Studio publikowania dla ASP.NET Core aplikacji, aby dowiedzieć się, jak utworzyć profil publikowania do użycia z Web Deploy. Jeśli dostawca hostingu udostępnia profil publikowania lub obsługuje jego tworzenie, pobierz jego profil i zaimportuj go przy użyciu Visual Studio publikowania:

Strona okna dialogowego Publikowanie

Web Deploy poza Visual Studio

Web Deploy można również używać poza Visual Studio z wiersza polecenia. Aby uzyskać więcej informacji, zobacz Web Deployment Tool.

Alternatywy dla Web Deploy

Użyj dowolnej z kilku metod przenoszenia aplikacji do systemu hostingu, takich jak kopiowanie ręczne, Xcopy, Robocopylub PowerShell.

Aby uzyskać więcej informacji na ASP.NET Core wdrażania 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 należy wykonać żą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 www.mysite.com porcie 80 . Żądanie jest dokonywane do http://www.mysite.com :

Przeglądarka Microsoft Edge załadowała stronę startową usług IIS.

Zablokowane pliki wdrożenia

Pliki w folderze wdrożenia są blokowane, gdy aplikacja jest uruchomiona. Zablokowanych plików nie można nadpisać podczas wdrażania. Aby zwolnić zablokowane pliki we wdrożeniu, zatrzymaj pulę aplikacji przy użyciu jednej z następujących metod:

  • Użyj Web Deploy i Microsoft.NET.Sdk.Web odwołania w pliku projektu. Plik app_offline.htm znajduje się w katalogu głównym katalogu aplikacji internetowej. Gdy plik jest obecny, moduł ASP.NET Core bezpiecznie zamyka aplikację i obsługuje plikapp_offline.htm podczas wdrażania. Aby uzyskać więcej informacji, zobacz ASP.NET Core konfiguracji modułu .

  • 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 ASP.NET Core Data Protection jest używany przez kilka ASP.NET Core pośredniczące, w tym oprogramowanie pośredniczące używane do uwierzytelniania. Nawet jeśli interfejsy API ochrony danych nie są wywoływane przez kod użytkownika, ochronę danych należy skonfigurować 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 jest przechowywany w pamięci po ponownym uruchomieniu aplikacji:

  • Wszystkie cookie tokeny uwierzytelniania oparte na systemie są unieważniane.
  • Użytkownicy muszą zalogować się ponownie przy następnym żądaniu.
  • 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 cookie s.

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

  • Tworzenie kluczy rejestru ochrony danych

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

    W przypadku autonomicznych instalacji usług IIS innych niż webfarm skrypt programu PowerShell Provision-AutoGenKeys.ps1 Data Protection może być używany dla każdej puli aplikacji używanej z ASP.NET Core aplikacji. Ten skrypt tworzy klucz rejestru w rejestrze HKLM, który jest dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane podczas spoczynku przy użyciu dpapi z kluczem na całej maszynie.

    W scenariuszach farmy sieci Web aplikację można skonfigurować do używania ścieżki UNC do przechowywania pierścienia klucza ochrony danych. Domyślnie klucze ochrony danych nie są szyfrowane. Upewnij się, że uprawnienia do plików dla udziału sieciowego są ograniczone do Windows, w ramach których działa aplikacja. Certyfikat X509 może służyć do ochrony kluczy w spoczynku. 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 maszynach, na których działa aplikacja użytkownika. Aby uzyskać szczegółowe informacje, zobacz ASP.NET Core Konfigurowanie ochrony danych.

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

    To ustawienie znajduje się w sekcji Model procesu w sekcji Ustawienia dla puli aplikacji. Dla ustawienia Załaduj profil użytkownika ustaw wartość True . W przypadku ustawienia na wartość klucze są przechowywane w katalogu profilu użytkownika i chronione przy użyciu interfejsu DPAPI z kluczem True 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 to setProfileEnvironment true . W niektórych scenariuszach (na przykład w Windows systemu operacyjnego) setProfileEnvironment jest ustawiona 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 applicationHost.config plik.
    3. Znajdź <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element .
    4. Upewnij się, że atrybut nie jest obecny, co domyślnie ustawia wartość na , lub jawnie ustaw setProfileEnvironment true 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ścieni 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ść go w zaufanym magazynie głównym.

    W przypadku korzystania z usług IIS w farmie sieci Web:

    • Użyj udziału plików, do który mają dostęp wszystkie maszyny.
    • Wdrażanie certyfikatu 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, które zużywają interfejsy API ochrony danych. Aby uzyskać więcej informacji, zobacz ASP.NET Core Ochrona danych.

Katalogi wirtualne

Katalogi wirtualne usług IIS nie są obsługiwane ASP.NET Core aplikacji. Aplikacja może być hostowana jako aplikacja podrzędna.

Aplikacje podrzędne

Aplikacja ASP.NET Core może być hostowana jako aplikacja podrzędna usług IIS (aplikacja podrzędna). Ś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 ~/ tyldy-ukośnika ( ). Notacja tyldy-ukośnika wyzwala pomocnika tagów, aby dołączał bazę ścieżek aplikacji podrzędnej do renderowanego linku względnego. W przypadku aplikacji podrzędnej w pliku /subapp_path obraz połączony z src="~/image.png" elementem jest renderowany jako src="/subapp_path/image.png" . Oprogramowanie pośredniczące plików statycznych aplikacji głównej nie przetwarza żądania pliku statycznego. Żądanie jest przetwarzane przez oprogramowanie pośredniczące plików statycznych aplikacji podrzędnej.

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

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

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

  2. Dodaj lokację główną w Menedżerze usług IIS z podaną aplikacją w folderze w lokacji głównej.

  3. Kliknij prawym przyciskiem myszy folder podaplikowania 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 w procesie.

Aby uzyskać więcej informacji na temat modelu hostingu w procesie i konfigurowania modułu ASP.NET Core, zobacz Moduł ASP.NET Core .

Konfiguracja usług IIS przy użyciu web.config

Na konfigurację usług IIS ma wpływ sekcjaweb.configscenariuszy usług IIS, które są funkcjonalne ASP.NET Core aplikacji za pomocą <system.webServer> ASP.NET Core Module. Na przykład konfiguracja usług IIS działa w przypadku kompresji dynamicznej. Jeśli usługi IIS są skonfigurowane na poziomie serwera do korzystania z kompresji dynamicznej, element w plikuweb.configaplikacji może go wyłączyć dla <urlCompression> ASP.NET Core aplikacji.

Aby uzyskać więcej informacji, zobacz następujące tematy:

Aby ustawić zmienne środowiskowe dla poszczególnych aplikacji uruchomionych w izolowanych pulach aplikacji (obsługiwanych w usługach IIS 10.0 lub nowszych), zobacz sekcję polecenia usługiAppCmd.exe w temacie Zmienne <environmentVariables> środowiskowe w dokumentacji referencyjnej usług IIS.

Sekcje, które nie są używane przez ASP.NET Core

Sekcje konfiguracji ASP.NET 4.x w programieweb.config nie są używane przez ASP.NET Core do konfiguracji:

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

ASP.NET Core są konfigurowane przy użyciu innych dostawców konfiguracji. Aby uzyskać więcej informacji, zobacz Konfiguracja.

Pule aplikacji

Izolacja puli aplikacji jest określana przez model hostingu:

  • Hosting w procesie: aplikacje muszą być uruchamiane w oddzielnych pulach aplikacji.
  • Hosting poza procesem: zalecamy izolowanie aplikacji od siebie przez uruchamianie każdej aplikacji w własnej puli aplikacji.

W oknie dialogowym Dodawanie witryny sieci Web usług IIS domyślnie jest łączona jedna pula aplikacji na aplikację. Po podano nazwę lokacji, 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 ani kont lokalnych oraz zarządzania nimi. W usługach IIS 8.0 lub nowszych proces administracyjny 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 Ustawienia zaawansowanej puli aplikacji upewnij się, że ustawiono użycie Identity puli Identity aplikacji:

Okno dialogowe ustawień zaawansowanych puli aplikacji

Proces zarządzania usługami IIS tworzy bezpieczny identyfikator z nazwą puli aplikacji w Zabezpieczenia Windows System. Zasoby można zabezpieczyć przy użyciu tej tożsamości. Ta tożsamość nie jest jednak rzeczywistym kontem użytkownika i nie jest pokazywana w Windows zarządzania użytkownikami.

Jeśli proces roboczy usług IIS wymaga podwyższonego poziomu dostępu do aplikacji, zmodyfikuj listę Access Control katalogów zawierających aplikację:

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

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

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

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

  5. Wprowadź wartość IIS AppPool \<app_pool_name> wprowadź nazwy obiektów do wybrania w obszarze. Wybierz przycisk Sprawdź nazwy. W przypadku puli DefaultAppPool sprawdź nazwy przy użyciu puli IIS AppPool\DefaultAppPool. Po wybraniu 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. Podczas sprawdzania nazwy obiektu użyj \<app_pool_name>AppPool usług IIS.

    Okno dialogowe Wybieranie użytkowników lub grup dla folderu aplikacji: nazwa puli aplikacji "DefaultAppPool" jest dołączana do puli aplikacji usług IIS w obszarze nazw obiektów przed wybraniem opcji " "Sprawdź nazwy".

  6. Wybierz przycisk OK.

    Okno dialogowe Wybieranie użytkowników lub grup dla folderu aplikacji: po wybraniu opcji "Sprawdź nazwy" nazwa obiektu "DefaultAppPool" jest wyświetlana w obszarze nazw obiektów.

  7. Uprawnienia & do wykonywania odczytu powinny być przyznawane domyślnie. W razie potrzeby podaj dodatkowe uprawnienia.

Dostęp można również przyznać w wierszu polecenia za pomocą narzędzia ICACLS. Na przykład przy użyciu puli 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 ASP.NET Core w następujących scenariuszach wdrażania usług IIS:

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

W przypadku wdrożenia w procesie po nawiązaniu połączenia HTTP/2 protokół HttpRequest.Protocol zgłasza błąd HTTP/2 . W przypadku wdrożenia poza procesem po nawiązaniu połączenia HTTP/2 protokół HttpRequest.Protocol zgłasza błąd HTTP/1.1 .

Aby uzyskać więcej informacji na temat modeli hostowania w procesie i poza procesem, zobacz Moduł ASP.NET Core .

Protokół HTTP/2 jest domyślnie włączony. Jeśli połączenie HTTP/2 nie zostanie nawiązane, połączenia wracają do protokołu HTTP/1.1. 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 ASP.NET Core aplikacji docelowych .NET Framework.

W przypadku ASP.NET Core aplikacji, która jest .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 programie web.config w celu przekazania żądań OPTIONS, zobacz Włączanie żądań między źródłami w interfejsie ASP.NET Web API 2:Jak działa cors .

Moduł inicjowania aplikacji i limit czasu bezczynności

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

  • Moduł inicjowania aplikacji:Hostowane w procesie lub poza procesem aplikacje można skonfigurować do automatycznego uruchamiania po ponownym uruchomieniu procesu roboczego lub ponownym uruchomieniu serwera.
  • Limit czasu bezczynności:hostowane w procesie aplikacje można skonfigurować tak, aby nie były limitami czasu w okresach braku aktywności.

Moduł inicjowania aplikacji

Dotyczy aplikacji hostowanych w procesie i poza procesem.

Inicjowanie aplikacji usług IIS to funkcja usług IIS, która wysyła żądanie HTTP do aplikacji, gdy pula aplikacji jest uruchamiana lub odzyskiwana. Żądanie wyzwala uruchomienie aplikacji. Domyślnie usługi IIS wyślą żądanie do głównego adresu URL aplikacji () w celu zainicjowania aplikacji (zobacz dodatkowe zasoby, aby uzyskać więcej informacji / na temat konfiguracji).

Upewnij się, że włączono funkcję roli inicjowania aplikacji usług IIS:

W Windows 7 lub nowszych w przypadku lokalnego korzystania z usług IIS:

  1. Przejdź do Panel sterowania programy i funkcje Windows włączać lub wyłączać > > > funkcje (po lewej stronie ekranu).
  2. Otwórz Internet Information Services > World Wide Web Services Application Development > Features.
  3. Zaznacz pole wyboru inicjowania aplikacji.

Na Windows Server 2008 R2 lub nowszy:

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

Aby włączyć moduł inicjowania aplikacji dla lokacji, użyj jednej z następujących metod:

  • Korzystanie z Menedżera usług IIS:

    1. Wybierz pozycję Pule aplikacji w panelu Połączenia.
    2. Kliknij prawym przyciskiem myszy pulę aplikacji aplikacji na liście i wybierz pozycję Zaawansowane Ustawienia.
    3. Domyślny tryb uruchamiania to OnDemand. W trybie uruchamiania ustaw wartość AlwaysRunning. Wybierz przycisk OK.
    4. Otwórz węzeł Lokacje w panelu Połączenia.
    5. Kliknij prawym przyciskiem myszy aplikację i wybierz pozycję Zarządzaj witryną internetową > Zaawansowane Ustawienia.
    6. Domyślne ustawienie Wstępne ładowanie włączone ma wartość Fałsz. Dla ustawienia Wstępne ładowanie włączone ustaw wartość True. Wybierz przycisk OK.
  • Za web.config dodaj element <applicationInitialization> z ustawieniem do elementów w plikuweb.configdoAppInitAfterRestart true <system.webServer> 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 w procesie.

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 aplikacji na liście i wybierz pozycję Zaawansowane Ustawienia.
  3. Domyślny limit czasu bezczynności (minuty) wynosi 20 minut. Ustaw wartość 0 (zero) dla wartości Time-out (minutes) (Czas bezczynności w minutach). Wybierz przycisk OK.
  4. Odtąd odtąd proces roboczy.

Aby zapobiec przechyłoceniu 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 zapewnić jej działanie.
  • Jeśli aplikacja hostuje tylko usługi w tle, należy unikać hostowania usług IIS i używać usługi Windows Service do hostowania ASP.NET Core aplikacji.

Dodatkowe zasoby dotyczące modułu inicjowania aplikacji i limitu czasu bezczynności

Zasoby wdrażania dla administratorów usług IIS

Dodatkowe zasoby

Aby uzyskać informacje na temat publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS .

Instalowanie pakietu hostingu .NET Core

Obsługiwane systemy operacyjne

Obsługiwane są następujące systemy operacyjne:

  • Windows 7 lub nowszy
  • Windows Server 2008 R2 lub nowszy

HTTP.sys serwera proxy (dawniej WebListener) nie działa w konfiguracji zwrotnego serwera proxy z usługami IIS. Użyj Kestrel serwera.

Aby uzyskać informacje na temat hostingu na platformie Azure, zobacz Wdróż aplikacje ASP.NET Core w Azure App Service .

Aby uzyskać wskazówki dotyczące rozwiązywania problemów, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Obsługiwane platformy

Obsługiwane są aplikacje opublikowane dla wdrożenia 32-bitowego (x86) lub 64-bitowego (x64). Wd wdrażaj aplikację 32-bitową z 32-bitową (x86) zestaw .NET Core SDK 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 natywne zależności 64-bitowe.

Użyj wersji 64-bitowej (x64) zestaw .NET Core SDK publikowania aplikacji 64-bitowej. W systemie hosta musi być obecne 64-bitowe środowisko uruchomieniowe.

ASP.NET Core jest dostarczany Kestrel z serwerem, domyślnym, międzyplatformowym serwerem HTTP.

W przypadku korzystania z usług IIS lub IIS Expressaplikacja jest uruchamiana w procesie oddzielonym od procesu roboczego usług IIS (poza procesem) na Kestrel serwerze.

Ponieważ ASP.NET Core są uruchamiane w procesie oddzielonym od procesu roboczego usług IIS, moduł obsługuje zarządzanie procesami. Moduł uruchamia proces dla aplikacji ASP.NET Core po przybyciu pierwszego żądania i uruchamia ponownie aplikację, jeśli zostanie zamknięta lub ulega awarii. Jest to zasadniczo takie samo zachowanie jak w przypadku aplikacji uruchamianych w procesie zarządzanych przez usługę Windows Process Activation Service (WAS).

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:

Moduł ASP.NET Core

Żądania docierają z Internetu do trybu jądra HTTP.sys sterownika. Sterownik kieruje żądania do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS). Moduł przekazuje żądania do aplikacji na losowym porcie, który nie jest Kestrel 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łuchiwać na serwerze 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.

Po odebraniu żądania z modułu żądanie jest wypychane do potoku Kestrel ASP.NET Core pośredniczącego. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako HttpContext wystąpienie do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację usług IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazywanie żądania do Kestrel usługi . Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które wypychają ją z powrotem do klienta HTTP, który zainicjował żądanie.

CreateDefaultBuilderKonfiguruje serwer jako serwer internetowy i włącza integrację usług IIS, konfigurując ścieżkę podstawową i port Kestrel dla modułu ASP.NET Core.

Moduł ASP.NET Core generuje port dynamiczny do przypisania do procesu zaplecza. CreateDefaultBuilder Metoda wywołuje UseIISIntegration metodę . UseIISIntegration Konfiguruje Kestrel nasłuchiwać na porcie dynamicznym pod adresem IP hosta lokalnego ( 127.0.0.1 ). Jeśli port dynamiczny to 1234, funkcja Kestrel nasłuchuje w . 127.0.0.1:1234 Ta konfiguracja zastępuje inne konfiguracje adresów URL udostępniane przez:

Wywołania UseUrls Kestrel interfejsu API lub Listen nie są wymagane podczas korzystania z modułu. Jeśli UseUrls lub Listen jest wywoływana, Kestrel nasłuchuje na określonym porcie tylko podczas uruchamiania aplikacji bez usług IIS.

Aby ASP.NET Core konfiguracji modułu, zobacz Moduł ASP.NET Core .

Aby uzyskać więcej informacji na temat hostingu, zobacz Host w ASP.NET Core.

Konfiguracja aplikacji

Włączanie składników IISIntegration

Podczas budowania hosta w CreateWebHostBuilder programie (Program.cs) wywołaj funkcję , CreateDefaultBuilder aby włączyć integrację usług IIS:

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

Aby uzyskać więcej informacji na CreateDefaultBuilder temat , zobacz ASP.NET Core Web Host .

Opcje usług IIS

Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true program , serwer usług IIS ustawia HttpContext.User uwierzytelniony przez usługę Windows uwierzytelniania. Jeśli , serwer zapewnia tylko tożsamość dla i odpowiada na false HttpContext.User wyzwania, gdy jawnie zażądane przez AuthenticationScheme . Windows Aby uwierzytelnianie działało, w usługach IIS AutomaticAuthentication musi być włączone. Aby uzyskać więcej informacji, zobacz Windows Authentication.
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.

Aby skonfigurować opcje usług IIS, uwzględnij konfigurację usługi dla programu IISOptions w programie ConfigureServices . Poniższy przykład uniemożliwia wypełnianie aplikacji HttpContext.Connection.ClientCertificate :

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opcja Domyślne Ustawienie
AutomaticAuthentication true Jeśli true program , oprogramowanie pośredniczące integracji usług IIS HttpContext.User ustawia uwierzytelnione przez Windows uwierzytelniania. Jeśli element , oprogramowanie pośredniczące zapewnia tożsamość dla usługi i odpowiada na wyzwania tylko wtedy, gdy jest false HttpContext.User jawnie żądane przez . AuthenticationScheme Windows Aby uwierzytelnianie działało, w usługach IIS AutomaticAuthentication musi być włączone. Aby uzyskać więcej informacji, zobacz temat Windows Authentication (Uwierzytelnianie użytkowników).
AuthenticationDisplayName null Ustawia nazwę wyświetlaną wyświetlaną użytkownikom na stronach logowania.
ForwardClientCertificate true Jeśli true i nagłówek żądania jest MS-ASPNETCORE-CLIENTCERT obecny, pole jest HttpContext.Connection.ClientCertificate wypełniane.

Scenariusze serwera proxy i usługi równoważenia obciążenia

Oprogramowanie pośredniczące integracjiusług IIS , które konfiguruje oprogramowanie pośredniczące Przekazywane nagłówki, oraz moduł ASP.NET Core są skonfigurowane do przekazywania schematu (HTTP/HTTPS) i zdalnego adresu IP, z którego pochodzi żądanie. W przypadku aplikacji hostowanych za dodatkowymi serwerami proxy i usługami równoważenia obciążenia może być wymagana dodatkowa konfiguracja. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami 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 MSBuild docelowy ( ) podczas _TransformWebConfig publikowania projektu. Ten element docelowy znajduje się w elementach docelowych zestawu SDK sieci Web ( 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 jest obecny w projekcie, zostanie utworzony z poprawną wartością processPath i argumentami w celu skonfigurowania modułu ASP.NET Core i przeniesiony do opublikowanych danych wyjściowych.

Jeśli plik web.config znajduje się w projekcie, jest on przekształcany z poprawną wartością processPath i argumentami w celu skonfigurowania modułu ASP.NET Core Module i przenoszony 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, które kontrolują aktywne moduły usług IIS. Aby uzyskać informacje na temat modułów usług IIS, które mogą przetwarzać żądania za pomocą ASP.NET Core, zobacz temat Moduły usług IIS.

Aby zapobiec przekształcaniu plikuweb.config SDK sieci Web, użyj właściwości w <IsTransformWebConfigDisabled> pliku projektu:

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

Podczas wyłączania internetowego zestawu SDK z przekształcania pliku deweloper powinien ręcznie ustawić argumenty i processPath. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.

web.config lokalizacji pliku

Aby poprawnie skonfigurować moduł ASP.NET Core, plik web.config musi znajdować się w ścieżce głównej zawartości (zazwyczaj ścieżce podstawowej aplikacji) wdrożonej aplikacji. Jest to ta sama lokalizacja co ścieżka fizyczna witryny internetowej dostarczana do usług IIS. Plik web.config jest wymagany w katalogu głównym aplikacji, aby umożliwić publikowanie wielu aplikacji przy użyciu Web Deploy.

W ścieżce fizycznej aplikacji istnieją poufne pliki, takie jak pliki.runtimeconfig.js <assembly> , <assembly>.xml (komentarze dokumentacji XML) i.deps.js <assembly> na. Gdy plik web.config jest obecny i witryna jest uruchamiana normalnie, usługi IIS nie obsługują tych poufnych plików, jeśli są żądane. Jeśli brakujeweb.config lub niepoprawnie nazwanego pliku albo nie można skonfigurować lokacji do normalnego uruchamiania, usługi IIS mogą publicznie obsługiwać poufne pliki.

Plik web.config musi być obecny we wdrożeniu przez cały czas, prawidłowo nazwany i może skonfigurować lokację do normalnego uruchamiania. Nigdy nie usuwajweb.config z wdrożenia produkcyjnego.

Przekształcanie pliku web.config

Jeśli musisz przekształcić dane web.config publikowania (na przykład ustawić zmienne środowiskowe na podstawie konfiguracji, profilu lub środowiska), zobacz Przekształcanie pliku web.config .

Konfiguracja usług IIS

Windows Systemy operacyjne serwera

Włącz rolę serwera sieci Web (IIS) i ustanów usługi roli.

  1. Użyj kreatora Dodaj role i funkcje z menu Zarządzaj lub linku w Menedżer serwera. W kroku Role serwera zaznacz pole wyboru Serwer sieci Web (IIS).

    Rola usług IIS serwera sieci Web jest zaznaczona w kroku Wybieranie ról serwera.

  2. Po kroku Funkcje krok Usługi ról jest ładowany dla serwera sieci Web (IIS). Wybierz żądane usługi ról IIS lub zaakceptuj domyślne usługi ról.

    Domyślne usługi ról są wybierane w kroku Wybieranie usług ról.

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

    WebSockets (opcjonalnie)
    Interfejsy WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć funkcję WebSockets, rozwiń następujące węzły: Tworzenie aplikacji serwera > internetowego. 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 serwera sieci Web (IIS).

Windows systemów operacyjnych dla komputerów stacjonarnych

Włącz konsolę zarządzania usługami IIS i World Wide Web Services.

  1. Przejdź do Panel sterowania programy i funkcje Windows włączać i wyłączać funkcje > > > (po lewej stronie ekranu).

  2. Otwórz Internet Information Services węzła. Otwórz węzeł Narzędzia do zarządzania sieci Web.

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

  4. Zaznacz pole wyboru dla usługi World Wide Web Services.

  5. Zaakceptuj domyślne funkcje usług World Wide Web Services lub dostosuj funkcje usług IIS.

    Windows Uwierzytelnianie (opcjonalne)
    Aby włączyć Windows uwierzytelniania, rozwiń następujące węzły: World Wide Web Services > Security. Wybierz funkcję Windows uwierzytelniania. Aby uzyskać więcej informacji, zobacz Windows Authentication <windowsAuthentication> (Uwierzytelnianie i konfigurowanie Windows uwierzytelniania).

    WebSockets (opcjonalnie)
    Interfejsy WebSocket są obsługiwane w ASP.NET Core 1.1 lub nowszej. Aby włączyć obiekty WebSocket, rozwiń następujące węzły: World Wide Web Services Application > Development Features. Wybierz funkcję Protokół WebSocket. Aby uzyskać więcej informacji, zobacz WebSockets.

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

Konsola zarządzania usługami IIS i World Wide Web usługi są wybrane w Windows funkcje.

Instalowanie pakietu hostingu .NET Core

Zainstaluj pakiet hostingowy .NET Core w systemie hostingu. Pakiet instaluje środowisko uruchomieniowe .NET Core, bibliotekę .NET Core i moduł ASP.NET Core . Moduł umożliwia uruchamianie ASP.NET Core za usługami IIS.

Ważne

Jeśli pakiet hostingowy jest zainstalowany przed usługami IIS, instalacja pakietu musi zostać naprawiona. Uruchom ponownie instalator pakietu hostingu po zainstalowaniu usług IIS.

Jeśli pakiet hostingu został zainstalowany po zainstalowaniu 64-bitowej (x64) wersji programu .NET Core, może się wydawać, że brakuje zestawów SDK (nie wykryto zestawówSDK .NET Core). Aby rozwiązać ten problem, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Pobierz

  1. Przejdź do strony Pobieranie .NET Core.
  2. Wybierz odpowiednią wersję programu .NET Core.
  3. W kolumnie Uruchamianie aplikacji — środowisko uruchomieniowe znajdź wiersz odpowiedniej wersji środowiska uruchomieniowego .NET Core.
  4. Pobierz instalatora, korzystając z linku Pakiet hostingu.

Ostrzeżenie

Niektóre instalatory zawierają wersje wersji, które zakończyły okres eksploatacji (EOL) i nie są już obsługiwane przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej.

Instalowanie pakietu hostingu

  1. Uruchom instalatora na serwerze. Podczas uruchamiania instalatora z powłoki poleceń administratora są dostępne następujące parametry:

    • OPT_NO_ANCM=1: Pomiń instalowanie ASP.NET Core modułu.
    • OPT_NO_RUNTIME=1: Pomiń instalowanie środowiska uruchomieniowego .NET Core. Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).
    • OPT_NO_SHAREDFX=1: Pomiń instalowanie ASP.NET Shared Framework (ASP.NET runtime). Używany, gdy serwer hostuje tylko wdrożenia samodzielne (SCD).
    • OPT_NO_X86=1: Pomiń instalowanie środowisk uruchomieniowych x86. Użyj tego parametru, jeśli wiesz, że nie będziesz hostował aplikacji 32-bitowych. Jeśli istnieje możliwość hostowania aplikacji 32-bitowych i 64-bitowych w przyszłości, nie używaj tego parametru ani instaluj obu środowisk uruchomieniowych.
    • OPT_NO_SHARED_CONFIG_CHECK=1: wyłącz sprawdzanie użycia 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 ASP.NET Core instalatorów pakietu hostingu w wersji 2.2 lub nowszej. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core.
  2. Uruchom ponownie system lub wykonaj następujące polecenia w powłoki poleceń:

    net stop was /y
    net start w3svc
    

    Ponowne uruchomienie usług IIS powoduje zmianę ścieżki systemowej, która jest zmienną środowiskową, dokonaną 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 uruchomione po ponownym uruchomieniu usług IIS. Aplikacje są ponownie uruchamiane po otrzymaniu pierwszego żądania, w tym z modułu inicjowania aplikacji.

ASP.NET Core przyjmuje zachowanie roll-forward dla wydań poprawek udostępnionych pakietów struktury. Po ponownym uruchomieniu aplikacji hostowanych przez usługi IIS z usługami IIS aplikacje są ładowane z najnowszymi wersjami poprawek pakietów, do których się odwołują, gdy odbierają pierwsze żądanie. Jeśli usługi IIS nie zostaną uruchomione ponownie, aplikacje zostaną uruchomione ponownie i będą wycofywały działanie, gdy procesy robocze zostaną odzyskane i otrzymają pierwsze żądanie.

Uwaga

Aby uzyskać informacje na temat konfiguracji udostępnionej usług IIS, zobacz ASP.NET Core Module with IIS Shared Configuration (Moduł konfiguracji udostępnionej usług IIS).

Instalowanie Web Deploy podczas publikowania za pomocą Visual Studio

Podczas wdrażania aplikacji na serwerach Web Deploy programzainstaluj najnowszą wersję Web Deploy na serwerze. Aby zainstalować Web Deploy, użyj Instalatora platformy internetowej (WebPI) lub uzyskaj instalatora bezpośrednio z Centrum pobierania Microsoft. Preferowaną metodą jest użycie interfejsu WebPI. Interfejs WebPI oferuje autonomiczną konfigurację i konfigurację dla dostawców hostingu.

Tworzenie witryny usług IIS

  1. W systemie hostingu utwórz folder zawierający opublikowane foldery i pliki aplikacji. W poniższym kroku ścieżka folderu jest dostarczana do usług IIS jako ścieżka fizyczna do aplikacji. Aby uzyskać więcej informacji na temat folderu wdrożenia aplikacji i układu pliku, zobacz ASP.NET Core struktury katalogów .

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

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

    W kroku Dodawanie witryny sieci Web należy podać nazwę lokacji, ścieżkę fizyczną i nazwę hosta.

    Ostrzeżenie

    Powiązań najwyższego poziomu z symbolami wieloznacznych ( http://*:80/ i ) nie http://+:80 należy używać. Powiązania najwyższego poziomu z symbolami wieloznacznymi mogą otworzyć aplikację na luki w zabezpieczeniach. Dotyczy to zarówno silnych, jak i słabych symboli wieloznacznych. Użyj jawnych nazw hostów zamiast symboli wieloznacznych. Powiązanie z symbolami wieloznacznymi poddomeny (na przykład ) nie stanowi zagrożenia dla bezpieczeństwa, jeśli kontrolujesz całą domenę nadrzędną (w przeciwieństwie do domeny *.mysub.com *.com narażonej na zagrożenia). Aby uzyskać więcej informacji, zobacz sekcję rfc7230 section-5.4.

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

  5. Kliknij prawym przyciskiem myszy pulę aplikacji witryny, a następnie wybierz Ustawienia z menu kontekstowego.

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

    Ustaw wartość Brak kodu zarządzanego dla wersji .NET CLR.

    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), a środowisko — Core Common Language Runtime (CoreCLR) dla programu .NET Core jest uruchamiane w celu hostowania aplikacji w procesie procesu roboczego. Ustawienie wersji clr .NET na wartość Brak kodu zarządzanego jest opcjonalne, ale zalecane.

  7. ASP.NET Core 2.2 lub nowsze: w przypadku samodzielnego wdrożenia 64-bitowego (x64) korzystającego z modelu hostingu w procesie wyłącz pulę aplikacji dla 32-bitowych procesów (x86).

    Na pasku bocznym Akcje Menedżera usług IIS > pul aplikacji wybierz pozycję Ustaw wartości domyślne puli aplikacji lub Zaawansowane Ustawienia. Znajdź opcję Włącz aplikacje 32-bitowe i ustaw wartość na False . To ustawienie nie ma wpływu na aplikacje wdrożone do hostowania poza procesem.

  8. Potwierdź, że tożsamość modelu procesu ma odpowiednie uprawnienia.

    Jeśli domyślna tożsamość puli aplikacji (model procesu) zostanie zmieniona z > Identity Puli Identity aplikacji na inną tożsamość, sprawdź, czy nowa tożsamość ma uprawnienia wymagane do uzyskania dostępu do folderu aplikacji, bazy danych i innych wymaganych zasobów. Na przykład pula aplikacji wymaga dostępu do odczytu i zapisu do folderów, w których aplikacja odczytuje i zapisuje pliki.

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

Wdrażanie aplikacji

Wd wdrażaj aplikację w folderze ścieżki fizycznej usług IIS, który został ustalony w sekcji Tworzenie witryny usług IIS. Web Deploy jest zalecanym mechanizmem wdrażania, ale istnieje kilka opcji przenoszenia aplikacji z folderu publikowania projektu do folderu wdrożenia systemu hostingu.

Web Deploy z Visual Studio

Zobacz temat Visual Studio publikowania dla ASP.NET Core aplikacji, aby dowiedzieć się, jak utworzyć profil publikowania do użycia z Web Deploy. Jeśli dostawca hostingu udostępnia profil publikowania lub obsługuje jego tworzenie, pobierz jego profil i zaimportuj go przy użyciu Visual Studio publikowania:

Strona okna dialogowego Publikowanie

Web Deploy poza Visual Studio

Web Deploy można również używać poza Visual Studio z wiersza polecenia. Aby uzyskać więcej informacji, zobacz Web Deployment Tool.

Alternatywy dla Web Deploy

Użyj dowolnej z kilku metod przenoszenia aplikacji do systemu hostingu, takich jak kopiowanie ręczne, Xcopy, Robocopylub PowerShell.

Aby uzyskać więcej informacji na ASP.NET Core wdrażania 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 należy wykonać żą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 www.mysite.com porcie 80 . Żądanie jest dokonywane do http://www.mysite.com :

Przeglądarka Microsoft Edge załadowała stronę startową usług IIS.

Zablokowane pliki wdrożenia

Pliki w folderze wdrożenia są blokowane, gdy aplikacja jest uruchomiona. Zablokowanych plików nie można nadpisać podczas wdrażania. Aby zwolnić zablokowane pliki we wdrożeniu, zatrzymaj pulę aplikacji przy użyciu jednej z następujących metod:

  • Użyj Web Deploy i Microsoft.NET.Sdk.Web odwołania w pliku projektu. Plik app_offline.htm znajduje się w katalogu głównym katalogu aplikacji internetowej. Gdy plik jest obecny, moduł ASP.NET Core bezpiecznie zamyka aplikację i obsługuje plik app_offline.htm podczas wdrażania. Aby uzyskać więcej informacji, zobacz ASP.NET Core konfiguracji modułu .

  • 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 ASP.NET Core Data Protection jest używany przez kilka ASP.NET Core pośredniczące, w tym oprogramowanie pośredniczące używane do uwierzytelniania. Nawet jeśli interfejsy API ochrony danych nie są wywoływane przez kod użytkownika, ochronę danych należy skonfigurować 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 jest przechowywany w pamięci po ponownym uruchomieniu aplikacji:

  • Wszystkie cookie tokeny uwierzytelniania oparte na systemie są unieważniane.
  • Użytkownicy muszą zalogować się ponownie przy następnym żądaniu.
  • 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 cookie s.

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

  • Tworzenie kluczy rejestru ochrony danych

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

    W przypadku autonomicznych instalacji usług IIS innych niż webfarm skrypt programu PowerShell usługi Data Protection Provision-AutoGenKeys.ps1 może być używany dla każdej puli aplikacji używanej z ASP.NET Core aplikacji. Ten skrypt tworzy klucz rejestru w rejestrze HKLM, który jest dostępny tylko dla konta procesu roboczego puli aplikacji. Klucze są szyfrowane podczas spoczynku przy użyciu dpapi z kluczem na całej maszynie.

    W scenariuszach farmy sieci Web aplikację można skonfigurować do używania ścieżki UNC do przechowywania pierścienia klucza ochrony danych. Domyślnie klucze ochrony danych nie są szyfrowane. Upewnij się, że uprawnienia do plików dla udziału sieciowego są ograniczone Windows konta, w ramach których działa aplikacja. Certyfikat X509 może służyć do ochrony kluczy w spoczynku. 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 maszynach, na których działa aplikacja użytkownika. Aby uzyskać szczegółowe informacje, ASP.NET Core konfigurowanie ochrony danych.

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

    To ustawienie znajduje się w sekcji Model przetwarzania w obszarze Ustawienia dla puli aplikacji. Dla ustawienia Załaduj profil użytkownika ustaw wartość True . W przypadku ustawienia na wartość klucze są przechowywane w katalogu profilu użytkownika i chronione przy użyciu interfejsu DPAPI z kluczem True 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 to setProfileEnvironment true . W niektórych scenariuszach (na przykład w Windows systemu operacyjnego) setProfileEnvironment jest ustawiona 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 applicationHost.config plik.
    3. Znajdź <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element .
    4. Upewnij się, że atrybut nie jest obecny, co domyślnie ustawia wartość na , lub jawnie ustaw setProfileEnvironment true 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ścieni 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ść go w zaufanym magazynie głównym.

    W przypadku korzystania z usług IIS w farmie sieci Web:

    • Użyj udziału plików, do który mają dostęp wszystkie maszyny.
    • Wdrażanie certyfikatu 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, które zużywają interfejsy API ochrony danych. Aby uzyskać więcej informacji, zobacz ASP.NET Core Ochrona danych.

Katalogi wirtualne

Katalogi wirtualne usług IIS nie są obsługiwane ASP.NET Core aplikacji. Aplikacja może być hostowana jako aplikacja podrzędna.

Aplikacje podrzędne

Aplikacja ASP.NET Core może być hostowana jako aplikacja podrzędna usług IIS (aplikacja podrzędna). Ś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 jako procedury obsługi. Jeśli moduł zostanie dodany jako procedura obsługi w pliku web.config aplikacji podrzędnej, 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.

Poniższy przykład przedstawia opublikowany plikweb.config dla ASP.NET Core podrzędnej:

<?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 spoza ASP.NET Core pod aplikacją ASP.NET Core jawnie usuń odziedziczony program obsługi w plikuweb.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 ~/ tyldy-ukośnika ( ). Notacja tyldy-ukośnika wyzwala pomocnika tagów, aby dołączał bazę ścieżek aplikacji podrzędnej do renderowanego linku względnego. W przypadku aplikacji podrzędnej w pliku /subapp_path obraz połączony z src="~/image.png" elementem jest renderowany jako src="/subapp_path/image.png" . Oprogramowanie pośredniczące plików statycznych aplikacji głównej nie przetwarza żądania pliku statycznego. Żądanie jest przetwarzane przez oprogramowanie pośredniczące plików statycznych aplikacji podrzędnej.

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

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

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

  2. Dodaj lokację główną w Menedżerze usług IIS z podaną aplikacją w folderze w lokacji głównej.

  3. Kliknij prawym przyciskiem myszy folder podaplikowania 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 w procesie.

Aby uzyskać więcej informacji na temat modelu hostingu w procesie i konfigurowania modułu ASP.NET Core, zobacz Moduł ASP.NET Core .

Konfiguracja usług IIS z web.config

Na konfigurację usług IIS ma wpływ sekcjaweb.configscenariuszy usług IIS, które są funkcjonalne ASP.NET Core aplikacji za pomocą <system.webServer> ASP.NET Core Module. Na przykład konfiguracja usług IIS działa w przypadku kompresji dynamicznej. Jeśli usługi IIS są skonfigurowane na poziomie serwera do korzystania z kompresji dynamicznej, element w plikuweb.configaplikacji może go wyłączyć dla <urlCompression> ASP.NET Core aplikacji.

Aby uzyskać więcej informacji, zobacz następujące tematy:

Aby ustawić zmienne środowiskowe dla poszczególnych aplikacji uruchomionych w izolowanych pulach aplikacji (obsługiwanych w usługach IIS 10.0 lub nowszych), zobacz sekcję polecenia usługiAppCmd.exe w temacie Zmienne <environmentVariables> środowiskowe w dokumentacji referencyjnej usług IIS.

Sekcje, które nie są używane przez ASP.NET Core

Sekcje konfiguracji ASP.NET 4.x w programie web.config nie są używane przez ASP.NET Core do konfiguracji:

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

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ę w własnej puli aplikacji. Domyślnie dla tej konfiguracji jest wyświetlane okno dialogowe Dodawanie witryny sieci Web usług IIS. Po podano nazwę lokacji, 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 ani kont lokalnych oraz zarządzania nimi. W usługach IIS 8.0 lub nowszych proces administracyjny 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 Ustawienia zaawansowanej dla puli aplikacji upewnij się, że dla ustawienia ustawiono Identity użycie puli aplikacji: Identity

Okno dialogowe ustawień zaawansowanych puli aplikacji

Proces zarządzania usługami IIS tworzy bezpieczny identyfikator z nazwą puli aplikacji w Zabezpieczenia Windows System. Zasoby można zabezpieczyć przy użyciu tej tożsamości. Ta tożsamość nie jest jednak rzeczywistym kontem użytkownika i nie jest pokazywana w Windows zarządzania użytkownikami.

Jeśli proces roboczy usług IIS wymaga podwyższonego poziomu dostępu do aplikacji, zmodyfikuj listę Access Control katalogów zawierających aplikację:

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

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

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

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

  5. Wprowadź wartość IIS AppPool \<app_pool_name> wprowadź nazwy obiektów do wybrania w obszarze. Wybierz przycisk Sprawdź nazwy. W przypadku puli DefaultAppPool sprawdź nazwy przy użyciu puli IIS AppPool\DefaultAppPool. Po wybraniu 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. Podczas sprawdzania nazwy obiektu użyj \<app_pool_name>AppPool usług IIS.

    Okno dialogowe Wybieranie użytkowników lub grup dla folderu aplikacji: nazwa puli aplikacji "DefaultAppPool" jest dołączana do puli aplikacji usług IIS w obszarze nazw obiektów przed wybraniem opcji " "Sprawdź nazwy".

  6. Wybierz przycisk OK.

    Okno dialogowe Wybieranie użytkowników lub grup dla folderu aplikacji: po wybraniu opcji "Sprawdź nazwy" nazwa obiektu "DefaultAppPool" jest wyświetlana w obszarze nazw obiektów.

  7. Uprawnienia & do wykonywania odczytu powinny być przyznawane domyślnie. W razie potrzeby podaj dodatkowe uprawnienia.

Dostęp można również przyznać w wierszu polecenia za pomocą narzędzia ICACLS. Na przykład przy użyciu puli 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 wymagania podstawowe:

  • Windows Server 2016/Windows 10 lub nowszy; IIS 10 lub nowszy
  • Publiczne połączenia serwera brzegowego używają protokołu HTTP/2, Kestrel ale odwrotne połączenie serwera proxy z serwerem używa protokołu HTTP/1.1.
  • Docelowa framework: 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 protokołu HTTP/1.1, jeśli nie nawiąż połączenia HTTP/2. Aby uzyskać więcej informacji na temat konfiguracji HTTP/2 z wdrożeniami usług IIS, zobacz HTTP/2 w usługach IIS.

Żądania wstępne CORS

Ta sekcja dotyczy tylko ASP.NET Core aplikacji docelowych .NET Framework.

W przypadku ASP.NET Core aplikacji, która jest .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 programie web.config w celu przekazania żądań OPTIONS, zobacz Enable cross-origin requests in ASP.NET Web API 2: How CORS Works.

Zasoby wdrażania dla administratorów usług IIS

Dodatkowe zasoby