Moduł ASP.NET Core Module (ANCM) dla usług IIS

Moduł ASP.NET Core (ANCM) to natywny moduł usług IIS, który podłącza się do potoku usług IIS, umożliwiając ASP.NET Core aplikacjom pracować z usługami IIS. Uruchom aplikacje ASP.NET Core z usługami IIS, wykonując jedną z następujących czynności:

• Hostowanie aplikacji ASP.NET Core wewnątrz procesu roboczego usług IIS (w3wp.exe), nazywanego modelem hostingu w procesie.
• Przekazywanie żądań internetowych do zaplecza ASP.NET Core aplikacji z uruchomionym serweremKestrel, nazywanej modelem hostingu poza procesem.

Istnieją kompromisy między poszczególnymi modelami hostingu. Domyślnie model hostingu w procesie jest używany ze względu na lepszą wydajność i diagnostykę.

Aby uzyskać więcej informacji i wskazówek dotyczących konfiguracji, zobacz następujące tematy:

• Implementacje serwera internetowego w środowisku ASP.NET Core

Instalowanie modułu ASP.NET Core (ANCM)

Moduł ASP.NET Core (ANCM) jest instalowany przy użyciu środowiska uruchomieniowego platformy .NET Core z pakietu hostingu platformy .NET Core. Moduł ASP.NET Core jest do przodu i do tyłu zgodny z wersjami LTS platformy .NET.

Zmiany powodujące niezgodność i biuletyny zabezpieczeń są raportowane w repozytorium Anonsy. Ogłoszenia mogą być ograniczone do określonej wersji, wybierając filtr Etykieta .

Pobierz instalatora za pomocą następującego linku:

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

Aby uzyskać więcej informacji, w tym instalowanie wcześniejszej wersji modułu, zobacz Hosting Bundle (Pakiet hostingu).

Aby zapoznać się z samouczkiem dotyczącym publikowania aplikacji ASP.NET Core na serwerze usług IIS, zobacz Publikowanie aplikacji ASP.NET Core w usługach IIS.

Moduł ASP.NET Core (ANCM) to natywny moduł usług IIS, który podłącza potok usług IIS do jednego z następujących elementów:

• Hostowanie aplikacji ASP.NET Core wewnątrz procesu roboczego usług IIS (w3wp.exe) nazywanego modelem hostingu w procesie przetwarzania.
• Przekazywanie żądań internetowych do zaplecza ASP.NET Core aplikacji z uruchomionym serweremKestrel, nazywanej modelem hostingu poza procesem.

Obsługiwane wersje systemu Windows:

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

Podczas hostowania w procesie moduł używa implementacji serwera przetwarzania dla usług IIS o nazwie Serwer HTTP usług IIS (IISHttpServer).

Podczas hostowania poza procesem moduł działa tylko z Kestrelprogramem . Moduł nie działa z HTTP.sys.

Modele hostingu

Model hostingu wewnątrz procesu

ASP.NET Core aplikacje domyślne do modelu hostingu w procesie.

Podczas hostingu w trakcie przetwarzania mają zastosowanie następujące cechy:

• Serwer HTTP usług IIS (IISHttpServer) jest używany zamiast Kestrel serwera. W przypadku wywołań UseIISmetody CreateDefaultBuilder w procesie:

  • Zarejestruj element IISHttpServer.
  • Skonfiguruj port i ścieżkę podstawową, na którym serwer powinien nasłuchiwać podczas uruchamiania za modułem ASP.NET Core.
  • Skonfiguruj hosta do przechwytywania błędów uruchamiania.

• Atrybut requestTimeout nie ma zastosowania do hostingu w procesie.

• Udostępnianie puli aplikacji między aplikacjami nie jest obsługiwane. Użyj jednej puli aplikacji na aplikację.

• W przypadku korzystania z narzędzia Web Deploy lub ręcznego umieszczania app_offline.htm pliku we wdrożeniu aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie protokołu WebSocket może opóźnić zamknięcie aplikacji.

• Architektura (bitowość) aplikacji i zainstalowane środowisko uruchomieniowe (x64 lub x86) muszą być zgodne z architekturą puli aplikacji.

• Wykryto rozłączenia klienta. Token HttpContext.RequestAborted anulowania jest anulowany po rozłączeniu klienta.

• W ASP.NET Core 2.2.1 lub starszej GetCurrentDirectory zwraca katalog roboczy procesu roboczego procesu uruchomionego przez usługi IIS, a nie katalog aplikacji (na przykład C:\Windows\System32\inetsrv ).w3wp.exe

  Aby uzyskać przykładowy kod, który ustawia bieżący katalog aplikacji, zobacz klasęCurrentDirectoryHelpers. Wywołaj metodę SetCurrentDirectory . Kolejne wywołania w celu GetCurrentDirectory udostępnienia katalogu aplikacji.

• W przypadku hostowania w procesie nie jest wywoływana wewnętrznie, AuthenticateAsync aby zainicjować użytkownika. W związku z tym implementacja IClaimsTransformation używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie aktywowana. Podczas przekształcania oświadczeń przy użyciu implementacji wywołaj metodę IClaimsTransformationAddAuthentication , aby dodać usługi uwierzytelniania:

  public void ConfigureServices(IServiceCollection services)
  {
      services.AddTransient<IClaimsTransformation, ClaimsTransformer>();
      services.AddAuthentication(IISServerDefaults.AuthenticationScheme);
  }
  
  public void Configure(IApplicationBuilder app)
  {
      app.UseAuthentication();
  }
  

  • Wdrożenia pakietu internetowego (z jednym plikiem) nie są obsługiwane.

Model hostingu poza procesem

Aby skonfigurować aplikację na potrzeby hostingu poza procesem, ustaw wartość <AspNetCoreHostingModel> właściwości na OutOfProcess w pliku projektu (.csproj):

<PropertyGroup>
  <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

Hosting w procesie jest ustawiany z wartością InProcess, która jest wartością domyślną.

Wartość jest <AspNetCoreHostingModel> niewrażliwa na wielkość liter, więc inprocess i outofprocess są prawidłowymi wartościami.

Kestrel Serwer jest używany zamiast serwera HTTP usług IIS (IISHttpServer).

W przypadku braku procesu CreateDefaultBuilder wywołania UseIISIntegration :

• Skonfiguruj port i ścieżkę podstawową, na którym serwer powinien nasłuchiwać podczas uruchamiania za modułem ASP.NET Core.
• Skonfiguruj hosta do przechwytywania błędów uruchamiania.

Zmiany modelu hostingu

hostingModel Jeśli ustawienie zostanie zmienione w web.config pliku (wyjaśnione w sekcji Konfiguracja za pomocąweb.config), moduł przetwarza proces roboczy dla usług IIS.

W przypadku IIS Express moduł nie przetwarza procesu roboczego, ale zamiast tego wyzwala bezproblemowe zamknięcie bieżącego procesu IIS Express. Następne żądanie do aplikacji zduplikuje nowy proces IIS Express.

Nazwa procesu

Process.GetCurrentProcess().ProcessName raporty w3wp/iisexpress (proces) lub dotnet (poza procesem).

Wiele modułów natywnych, takich jak uwierzytelnianie systemu Windows, pozostaje aktywnych. Aby dowiedzieć się więcej na temat modułów usług IIS aktywnych za pomocą modułu ASP.NET Core, zobacz Moduły usług IIS z ASP.NET Core.

Moduł ASP.NET Core może również wykonywać następujące czynności:

• Ustaw zmienne środowiskowe dla procesu roboczego.
• Rejestrowanie danych wyjściowych stdout w magazynie plików na potrzeby rozwiązywania problemów z uruchamianiem.
• Przekazywanie tokenów uwierzytelniania systemu Windows.

Jak zainstalować moduł ASP.NET Core (ANCM) i korzystać z niego

Aby uzyskać instrukcje dotyczące sposobu instalowania modułu ASP.NET Core, zobacz Instalowanie pakietu hostingu platformy .NET Core. Moduł ASP.NET Core jest do przodu i do tyłu zgodny z wersjami LTS platformy .NET.

Zmiany powodujące niezgodność i biuletyny zabezpieczeń są raportowane w repozytorium Anonsy. Ogłoszenia mogą być ograniczone do określonej wersji, wybierając filtr Etykieta .

Konfiguracja przy użyciu web.config

Moduł ASP.NET Core jest skonfigurowany z sekcją aspNetCoresystem.webServer węzła w pliku web.configlokacji.

Następujący web.config plik jest publikowany dla wdrożenia zależnego od platformy i konfiguruje moduł ASP.NET Core do obsługi żądań lokacji:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet"
                  arguments=".\MyApp.dll"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout"
                  hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Następujące web.config są publikowane dla samodzielnego wdrożenia:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\MyApp.exe"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout"
                  hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Właściwość jest ustawiona InheritInChildApplications na wartość , aby wskazać false , że ustawienia określone w elemecie <location> nie są dziedziczone przez aplikacje znajdujące się w podkatalogu aplikacji.

Po wdrożeniu aplikacji w Azure App Service ścieżka jest ustawiona stdoutLogFile na \\?\%home%\LogFiles\stdout. Ścieżka zapisuje dzienniki stdout w LogFiles folderze, który jest lokalizacją automatycznie utworzoną przez usługę.

Aby uzyskać informacje na temat konfiguracji podapliki usług IIS, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

Atrybuty elementu aspNetCore

Atrybut	Opis	Domyślny
arguments	Opcjonalny atrybut ciągu. Argumenty do pliku wykonywalnego określonego w processPath.
disableStartUpErrorPage	Opcjonalny atrybut logiczny. Jeśli wartość true, strona 502.5 — Niepowodzenie procesu jest pomijana, a strona kodowa stanu 502 skonfigurowana w web.config ma pierwszeństwo.	false
forwardWindowsAuthToken	Opcjonalny atrybut logiczny. Jeśli wartość true, token jest przekazywany do procesu podrzędnego nasłuchiwania %ASPNETCORE_PORT% jako nagłówek 'MS-ASPNETCORE-WINAUTHTOKEN' na żądanie. Jest to odpowiedzialność za wywołanie metody CloseHandle na tym tokenie na żądanie.	true
hostingModel	Opcjonalny atrybut ciągu. Określa model hostingu jako proces (InProcess/inprocess) lub poza procesem ().OutOfProcess/outofprocess	InProcess inprocess
processesPerApplication	Opcjonalny atrybut liczby całkowitej. Określa liczbę wystąpień procesu określonego w ustawieniu processPath , które można połączyć dla aplikacji. †Do hostingu w procesie wartość jest ograniczona do 1. Nie zaleca się ustawiania processesPerApplication . Ten atrybut zostanie usunięty w przyszłej wersji.	Domyślny: 1 Min: 1 Maks.: 100†
processPath	Wymagany atrybut ciągu. Ścieżka do pliku wykonywalnego, który uruchamia proces nasłuchiwania żądań HTTP. Ścieżki względne są obsługiwane. Jeśli ścieżka zaczyna się od ., ścieżka jest uważana za względną względem katalogu głównego witryny.
rapidFailsPerMinute	Opcjonalny atrybut liczby całkowitej. Określa, ile razy proces określony w processPath może ulec awarii na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces w pozostałej części minuty. Nieobsługiwane w przypadku hostingu w procesie.	Domyślny: 10 Min: 0 Max: 100
requestTimeout	Opcjonalny atrybut przedziału czasu. Określa czas trwania oczekiwania modułu ASP.NET Core na odpowiedź z procesu nasłuchiwania %ASPNETCORE_PORT%. W wersjach modułu ASP.NET Core dostarczanego z wydaniem ASP.NET Core 2.1 lub nowszym parametr requestTimeout jest określony w godzinach, minutach i sekundach. Nie dotyczy hostingu w procesie. W przypadku hostingu w procesie moduł czeka na przetworzenie żądania przez aplikację. Prawidłowe wartości dla minut i sekund segmentów ciągu znajdują się w zakresie od 0 do 59. Użycie wartości 60 w ciągu minut lub sekund powoduje błąd 500 — wewnętrzny błąd serwera.	Domyślny: 00:02:00 Min: 00:00:00 Max: 360:00:00
shutdownTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na bezproblemowe zamknięcie pliku wykonywalnego po app_offline.htm wykryciu pliku.	Domyślny: 10 Min: 0 Max: 600
startupTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na uruchomienie procesu nasłuchiwania na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zabije proces. Podczas hostowania w procesie: proces nie jest uruchamiany ponownie i nie używa ustawienia rapidFailsPerMinute . Podczas hostowania procesu poza procesem: moduł próbuje ponownie uruchomić proces po odebraniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu na kolejnych żądaniach przychodzących, chyba że aplikacja nie uruchomi funkcji rapidFailsPerMinute kilka razy w ostatniej chwili. Wartość 0 (zero) nie jest uważana za nieskończony limit czasu.	Domyślny: 120 Min: 0 Max: 3600
stdoutLogEnabled	Opcjonalny atrybut logiczny. Jeśli wartość true, stdout i stderr dla procesu określonego w processPath są przekierowywane do pliku określonego w stdoutLogFile.	false
stdoutLogFile	Opcjonalny atrybut ciągu. Określa względną lub bezwzględną ścieżkę pliku, dla której są rejestrowane ścieżki stdout i stderr z procesu określonego w processPath . Ścieżki względne są względne względem katalogu głównego witryny. Każda ścieżka rozpoczynająca się od . ścieżki jest względna względem katalogu głównego witryny, a wszystkie inne ścieżki są traktowane jako ścieżki bezwzględne. Wszystkie foldery podane w ścieżce są tworzone przez moduł podczas tworzenia pliku dziennika. Przy użyciu ograniczników podkreślenia znaczniki czasu, identyfikatora procesu i rozszerzenia pliku (.log) są dodawane do ostatniego segmentu ścieżki stdoutLogFile . Jeśli .\logs\stdout zostanie podana jako wartość, przykładowy dziennik stdout jest zapisywany jako stdout_20180205194132_1934.log w logs folderze zapisanym w dniu 2/5/2018 o godzinie 19:41:32 z identyfikatorem procesu 1934.	aspnetcore-stdout

Ustawianie zmiennych środowiskowych

Zmienne środowiskowe można określić dla procesu w atrybucie processPath . Określ zmienną środowiskową z <environmentVariable> elementem podrzędnym <environmentVariables> elementu kolekcji. Zmienne środowiskowe ustawione w tej sekcji mają pierwszeństwo przed zmiennymi środowiskowymi systemu.

W poniższym przykładzie ustawiono dwie zmienne środowiskowe w pliku web.config. ASPNETCORE_ENVIRONMENT konfiguruje środowisko aplikacji na Development. Deweloper może tymczasowo ustawić tę wartość w pliku, web.config aby wymusić załadowanie strony wyjątku dewelopera podczas debugowania wyjątku aplikacji. CONFIG_DIR to przykład zmiennej środowiskowej zdefiniowanej przez użytkownika, w której deweloper napisał kod, który odczytuje wartość podczas uruchamiania, aby utworzyć ścieżkę ładowania pliku konfiguracji aplikacji.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="inprocess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
    <environmentVariable name="CONFIG_DIR" value="f:\application_config" />
  </environmentVariables>
</aspNetCore>

Uwaga

Alternatywą dla ustawienia środowiska bezpośrednio w web.config programie jest uwzględnienie <EnvironmentName> właściwości w profilu publikowania (.pubxml) lub pliku projektu. To podejście ustawia środowisko w web.config momencie opublikowania projektu:

<PropertyGroup>
  <EnvironmentName>Development</EnvironmentName>
</PropertyGroup>

Ostrzeżenie

Ustaw zmienną ASPNETCORE_ENVIRONMENT środowiskową Development tylko na serwery przejściowe i testowe, które nie są dostępne dla niezaufanych sieci, takich jak Internet.

app_offline.htm

Jeśli plik o nazwie app_offline.htm zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core próbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie żądań przychodzących. Jeśli aplikacja jest nadal uruchomiona po liczbie sekund zdefiniowanych w shutdownTimeLimitpliku , moduł ASP.NET Core zabija uruchomiony proces.

app_offline.htm Gdy plik jest obecny, moduł ASP.NET Core odpowiada na żądania, wysyłając z powrotem zawartość app_offline.htm pliku. Po usunięciu app_offline.htm pliku następne żądanie uruchomi aplikację.

W przypadku korzystania z modelu hostingu poza procesem aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie protokołu WebSocket może opóźnić zamknięcie aplikacji.

Strona błędu uruchamiania

Zarówno w procesie, jak i poza procesem hostingu generują niestandardowe strony błędów, gdy nie można uruchomić aplikacji.

Jeśli moduł ASP.NET Core nie może znaleźć procedury obsługi żądań w procesie lub poza procesem, zostanie wyświetlona strona kodowa stanu błędu błędu ładowania 500.0 — In-Process/Out-Of-Process Handler.

W przypadku hostowania w trakcie przetwarzania, jeśli moduł ASP.NET Core nie może uruchomić aplikacji, zostanie wyświetlona strona kodowa stanu błędu 500.30 .

W przypadku hostowania poza procesem, jeśli moduł ASP.NET Core nie może uruchomić procesu zaplecza lub proces zaplecza zostanie uruchomiony, ale nie można nasłuchiwać na skonfigurowanym porcie, zostanie wyświetlona strona kodowa stanu błędu procesu 502.5.

Aby pominąć tę stronę i przywrócić domyślną stronę kodów stanu usług IIS 5xx, użyj atrybutu disableStartUpErrorPage . Aby uzyskać więcej informacji na temat konfigurowania niestandardowych komunikatów o błędach, zobacz Błędy <httpErrors>HTTP .

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe konsoli stdout i stderr do dysku, jeśli stdoutLogEnabled ustawiono atrybuty aspNetCore i stdoutLogFile elementu. Wszystkie foldery w ścieżce stdoutLogFile są tworzone przez moduł podczas tworzenia pliku dziennika. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (użyj polecenia IIS AppPool\<app_pool_name> w celu udzielenia uprawnień do zapisu).

Dzienniki nie są obracane, chyba że nastąpi ponowne odtwarzanie/ponowne uruchamianie procesów. Obowiązkiem dostawcy usług hostingowych jest ograniczenie miejsca na dysku używanego przez dzienniki.

Korzystanie z dziennika stdout jest zalecane tylko w przypadku rozwiązywania problemów z uruchamianiem aplikacji podczas hostowania w usługach IIS lub korzystania z obsługi czasu programowania dla usług IIS w programie Visual Studio, a nie podczas debugowania lokalnie i uruchamiania aplikacji z IIS Express.

Nie używaj dziennika stdout do ogólnych celów rejestrowania aplikacji. W przypadku rutynowego rejestrowania w aplikacji ASP.NET Core użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Sygnatura czasowa i rozszerzenie pliku są dodawane automatycznie po utworzeniu pliku dziennika. Nazwa pliku dziennika składa się z dołączania znacznika czasu, identyfikatora procesu i rozszerzenia pliku (.log) do ostatniego segmentu stdoutLogFile ścieżki (zazwyczaj stdout) rozdzielanego znakami podkreślenia. stdoutLogFile Jeśli ścieżka kończy się ciągiem stdout, dziennik aplikacji z identyfikatorem PID z 1934 r. utworzonym 5.02.2018 o godzinie 19:42:32 ma nazwę stdout_20180205194132_1934.logpliku .

Jeśli stdoutLogEnabled ma wartość false, błędy występujące podczas uruchamiania aplikacji są przechwytywane i emitowane do dziennika zdarzeń do 30 KB. Po uruchomieniu wszystkie dodatkowe dzienniki zostaną odrzucone.

Poniższy przykładowy aspNetCore element konfiguruje rejestrowanie stdout w ścieżce .\log\względnej . Upewnij się, że tożsamość użytkownika puli aplikacji ma uprawnienia do zapisu w podanej ścieżce.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout"
    hostingModel="inprocess">
</aspNetCore>

Podczas publikowania aplikacji na potrzeby wdrożenia Azure App Service zestaw SDK sieci Web ustawia stdoutLogFile wartość na \\?\%home%\LogFiles\stdout. Zmienna %home środowiskowa jest wstępnie zdefiniowana dla aplikacji hostowanych przez Azure App Service.

Aby utworzyć reguły filtru rejestrowania, zobacz sekcję Stosowanie reguł filtrowania dzienników w dokumentacji dotyczącej rejestrowania ASP.NET Core.

Aby uzyskać więcej informacji na temat formatów ścieżek, zobacz Formaty ścieżek plików w systemach Windows.

Rozszerzone dzienniki diagnostyczne

Moduł ASP.NET Core można skonfigurować w celu zapewnienia rozszerzonych dzienników diagnostycznych. <handlerSettings> Dodaj element do elementu w pliku <aspNetCore>web.config. Ustawienie elementu debugLevel w celu TRACE uwidocznienia większej wierności informacji diagnostycznych:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
    <handlerSetting name="debugLevel" value="FILE,TRACE" />
  </handlerSettings>
</aspNetCore>

Wszystkie foldery w ścieżce (logs w poprzednim przykładzie) są tworzone przez moduł podczas tworzenia pliku dziennika. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (użyj IIS AppPool\{APP POOL NAME}polecenia , gdzie symbol zastępczy {APP POOL NAME} jest nazwą puli aplikacji, aby zapewnić uprawnienie do zapisu).

Wartości poziomu debugowania (debugLevel) mogą obejmować zarówno poziom, jak i lokalizację.

Poziomy (w kolejności od najmniejszej do najbardziej pełnej):

• BŁĄD
• OSTRZEŻENIE
• INFORMACJI
• TRACE

Lokalizacje (dozwolone są wiele lokalizacji):

• KONSOLI
• EVENTLOG
• PLIK

Ustawienia procedury obsługi można również udostępnić za pomocą zmiennych środowiskowych:

• ASPNETCORE_MODULE_DEBUG_FILE: ścieżka do pliku dziennika debugowania. (Ustawienie domyślne: aspnetcore-debug.log)
• ASPNETCORE_MODULE_DEBUG: Ustawienie poziomu debugowania.

Ostrzeżenie

Nie pozostawiaj włączonego rejestrowania debugowania we wdrożeniu dłużej niż jest to wymagane do rozwiązania problemu. Rozmiar dziennika nie jest ograniczony. Pozostawienie włączonego dziennika debugowania może wyczerpać dostępne miejsce na dysku i awarii serwera lub usługi App Service.

Zobacz Configuration with web.config(Konfiguracja z web.config ), aby zapoznać się z przykładem aspNetCore elementu w web.config pliku .

Modyfikowanie rozmiaru stosu

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

Skonfiguruj rozmiar zarządzanego stosu stackSize przy użyciu ustawienia w bajtach w pliku web.config. Domyślny rozmiar to 1 048 576 bajtów (1 MB).

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

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

Dotyczy tylko hostingu poza procesem.

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

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

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

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

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

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

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

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

Dzienniki instalatora wersji modułu i pakietu hostingowego

Aby określić wersję zainstalowanego modułu ASP.NET Core:

1. W systemie hostingu przejdź do adresu %windir%\System32\inetsrv.
2. aspnetcore.dll Znajdź plik.
3. Kliknij plik prawym przyciskiem myszy i wybierz polecenie Właściwości z menu kontekstowego.
4. Wybierz kartę Szczegóły . Wersja pliku i wersja produktu reprezentują zainstalowaną wersję modułu.

Dzienniki instalatora pakietu hostingu dla modułu znajdują się pod adresem C:\Users\%UserName%\AppData\Local\Temp. Plik ma nazwę dd_DotNetCoreWinSvrHosting__{TIMESTAMP}_000_AspNetCoreModule_x64.log.

Lokalizacje plików modułu, schematu i konfiguracji

Moduł

IIS (x86/amd64):

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

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

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

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

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

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

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

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

Schemat

IIS

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

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

IIS Express

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

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

Konfigurowanie

IIS

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

IIS Express

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

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

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

Moduł ASP.NET Core (ANCM) to natywny moduł usług IIS, który podłącza potok usług IIS do jednego z następujących elementów:

• Hostowanie aplikacji ASP.NET Core wewnątrz procesu roboczego usług IIS (w3wp.exe) nazywanego modelem hostingu w procesie przetwarzania.
• Przekazywanie żądań internetowych do zaplecza ASP.NET Core aplikacji z uruchomionym serweremKestrel, nazywanej modelem hostingu poza procesem.

Obsługiwane wersje systemu Windows:

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

Podczas hostowania w procesie moduł używa implementacji serwera przetwarzania dla usług IIS o nazwie Serwer HTTP usług IIS (IISHttpServer).

Podczas hostowania poza procesem moduł działa tylko z Kestrelprogramem . Moduł nie działa z HTTP.sys.

Modele hostingu

Model hostingu wewnątrz procesu

Aby skonfigurować aplikację do hostowania procesów, dodaj <AspNetCoreHostingModel> właściwość do pliku projektu aplikacji z wartością InProcess (hosting poza procesem jest ustawiony na OutOfProcesswartość ):

<PropertyGroup>
  <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>

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

Wartość jest <AspNetCoreHostingModel> niewrażliwa na wielkość liter, więc inprocess i outofprocess są prawidłowymi wartościami.

<AspNetCoreHostingModel> Jeśli właściwość nie znajduje się w pliku, wartość domyślna to OutOfProcess.

Podczas hostingu w trakcie przetwarzania mają zastosowanie następujące cechy:

• Serwer HTTP usług IIS (IISHttpServer) jest używany zamiast Kestrel serwera. W przypadku wywołań UseIISmetody CreateDefaultBuilder w procesie:

  • Zarejestruj element IISHttpServer.
  • Skonfiguruj port i ścieżkę podstawową, na którym serwer powinien nasłuchiwać podczas uruchamiania za modułem ASP.NET Core.
  • Skonfiguruj hosta do przechwytywania błędów uruchamiania.

• Atrybut requestTimeout nie ma zastosowania do hostingu w procesie.

• Udostępnianie puli aplikacji między aplikacjami nie jest obsługiwane. Użyj jednej puli aplikacji na aplikację.

• W przypadku korzystania z narzędzia Web Deploy lub ręcznego umieszczenia plikuapp_offline.htm we wdrożeniu aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie protokołu websocket może opóźnić zamknięcie aplikacji.

• Architektura (bitowość) aplikacji i zainstalowane środowisko uruchomieniowe (x64 lub x86) muszą być zgodne z architekturą puli aplikacji.

• Wykryto rozłączenia klienta. Token anulowania HttpContext.RequestAborted jest anulowany po rozłączeniu klienta.

• W ASP.NET Core 2.2.1 lub starszej GetCurrentDirectory zwraca katalog roboczy procesu uruchomionego przez usługi IIS, a nie katalog aplikacji (na przykład C:\Windows\System32\inetsrv dla w3wp.exe).

  Aby uzyskać przykładowy kod, który ustawia bieżący katalog aplikacji, zobacz klasę CurrentDirectoryHelpers. Wywołaj metodę SetCurrentDirectory . Kolejne wywołania w celu GetCurrentDirectory udostępnienia katalogu aplikacji.

• W przypadku hostowania w procesie nie jest wywoływana wewnętrznie, AuthenticateAsync aby zainicjować użytkownika. W związku z tym implementacja IClaimsTransformation używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie aktywowana. Podczas przekształcania oświadczeń przy użyciu implementacji wywołaj metodę IClaimsTransformationAddAuthentication , aby dodać usługi uwierzytelniania:

  public void ConfigureServices(IServiceCollection services)
  {
      services.AddTransient<IClaimsTransformation, ClaimsTransformer>();
      services.AddAuthentication(IISServerDefaults.AuthenticationScheme);
  }
  
  public void Configure(IApplicationBuilder app)
  {
      app.UseAuthentication();
  }
  

Model hostingu poza procesem

Aby skonfigurować aplikację na potrzeby hostingu poza procesem, użyj jednej z następujących metod w pliku projektu:

• Nie określaj <AspNetCoreHostingModel> właściwości . <AspNetCoreHostingModel> Jeśli właściwość nie znajduje się w pliku, wartość domyślna to OutOfProcess.
• Ustaw wartość <AspNetCoreHostingModel> właściwości na OutOfProcess (hosting w procesie jest ustawiony na InProcesswartość ):

<PropertyGroup>
  <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

Wartość jest niewrażliwa na wielkość liter, więc inprocess i outofprocess są prawidłowymi wartościami.

Kestrel Serwer jest używany zamiast serwera HTTP usług IIS (IISHttpServer).

W przypadku braku procesu wywołania UseIISIntegrationmetody CreateDefaultBuilder do:

• Skonfiguruj port i ścieżkę podstawową, na którym serwer powinien nasłuchiwać podczas uruchamiania za modułem ASP.NET Core.
• Skonfiguruj hosta do przechwytywania błędów uruchamiania.

Zmiany modelu hostingu

hostingModel Jeśli ustawienie zostanie zmienione w pliku web.config (wyjaśnione w sekcji Konfiguracja przy użyciu web.config), moduł przetwarza proces roboczy dla usług IIS.

W przypadku IIS Express moduł nie przetwarza procesu roboczego, ale zamiast tego wyzwala bezproblemowe zamknięcie bieżącego procesu IIS Express. Następne żądanie do aplikacji zduplikuje nowy proces IIS Express.

Nazwa procesu

Process.GetCurrentProcess().ProcessName raporty w3wp/iisexpress (proces) lub dotnet (poza procesem).

Wiele modułów natywnych, takich jak uwierzytelnianie systemu Windows, pozostaje aktywnych. Aby dowiedzieć się więcej na temat modułów usług IIS aktywnych za pomocą modułu ASP.NET Core, zobacz Moduły usług IIS z ASP.NET Core.

Moduł ASP.NET Core może również wykonywać następujące czynności:

• Ustaw zmienne środowiskowe dla procesu roboczego.
• Rejestrowanie danych wyjściowych stdout w magazynie plików na potrzeby rozwiązywania problemów z uruchamianiem.
• Przekazywanie tokenów uwierzytelniania systemu Windows.

Jak zainstalować moduł ASP.NET Core (ANCM) i korzystać z niego

Aby uzyskać instrukcje dotyczące sposobu instalowania modułu ASP.NET Core, zobacz Instalowanie pakietu hostingu platformy .NET Core. Moduł ASP.NET Core jest do przodu i do tyłu zgodny z wersjami LTS platformy .NET.

Zmiany powodujące niezgodność i biuletyny zabezpieczeń są raportowane w repozytorium Anonsy. Ogłoszenia mogą być ograniczone do określonej wersji, wybierając filtr Etykieta .

Konfiguracja przy użyciu web.config

Moduł ASP.NET Core jest skonfigurowany z sekcją aspNetCoresystem.webServer węzła w pliku web.configlokacji.

Następujący plik web.config jest publikowany na potrzeby wdrożenia zależnego od platformy i konfiguruje moduł ASP.NET Core do obsługi żądań lokacji:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet"
                  arguments=".\MyApp.dll"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout"
                  hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Następujące web.config są publikowane dla samodzielnego wdrożenia:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\MyApp.exe"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout"
                  hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Właściwość jest ustawiona InheritInChildApplications na wartość , aby wskazać false , że ustawienia określone w elemecie <location> nie są dziedziczone przez aplikacje znajdujące się w podkatalogu aplikacji.

Po wdrożeniu aplikacji w Azure App Service ścieżka jest ustawiona stdoutLogFile na \\?\%home%\LogFiles\stdout. Ścieżka zapisuje dzienniki stdout w folderze LogFiles , który jest lokalizacją utworzoną automatycznie przez usługę.

Aby uzyskać informacje na temat konfiguracji podapliki usług IIS, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

Atrybuty elementu aspNetCore

Atrybut	Opis	Domyślny
arguments	Opcjonalny atrybut ciągu. Argumenty pliku wykonywalnego określonego w pliku processPath.
disableStartUpErrorPage	Opcjonalny atrybut logiczny. Jeśli wartość true, strona 502.5 — Niepowodzenie procesu jest pomijana, a strona kodowa stanu 502 skonfigurowana w web.config ma pierwszeństwo.	false
forwardWindowsAuthToken	Opcjonalny atrybut logiczny. Jeśli wartość true, token jest przekazywany do procesu podrzędnego nasłuchiwania w %ASPNETCORE_PORT% jako nagłówek "MS-ASPNETCORE-WINAUTHTOKEN" na żądanie. Jest to odpowiedzialność za wywołanie metody CloseHandle na tym tokenie na żądanie.	true
hostingModel	Opcjonalny atrybut ciągu. Określa model hostingu jako proces (InProcess/inprocess) lub poza procesem ().OutOfProcess/outofprocess	OutOfProcess outofprocess
processesPerApplication	Opcjonalny atrybut liczby całkowitej. Określa liczbę wystąpień procesu określonego processPath w ustawieniu, które można połączyć dla aplikacji. †Do hostingu w procesie wartość jest ograniczona do 1. Nie zaleca się ustawiania processesPerApplication . Ten atrybut zostanie usunięty w przyszłej wersji.	Domyślny: 1 Min: 1 Maks.: 100†
processPath	Wymagany atrybut ciągu. Ścieżka do pliku wykonywalnego, który uruchamia proces nasłuchiwania żądań HTTP. Ścieżki względne są obsługiwane. Jeśli ścieżka zaczyna się od ., ścieżka jest uważana za względną względem katalogu głównego witryny.
rapidFailsPerMinute	Opcjonalny atrybut liczby całkowitej. Określa liczbę przypadków, w których proces określony w processPath programie może ulec awarii na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces w pozostałej części minuty. Nieobsługiwane w przypadku hostingu w procesie.	Domyślny: 10 Min: 0 Max: 100
requestTimeout	Opcjonalny atrybut przedziału czasu. Określa czas trwania oczekiwania modułu ASP.NET Core na odpowiedź z procesu nasłuchiwania %ASPNETCORE_PORT%. W wersjach modułu ASP.NET Core dostarczanego z wydaniem ASP.NET Core 2.1 lub nowszym parametr requestTimeout jest określony w godzinach, minutach i sekundach. Nie dotyczy hostingu w procesie. W przypadku hostingu w procesie moduł czeka na przetworzenie żądania przez aplikację. Prawidłowe wartości dla minut i sekund segmentów ciągu znajdują się w zakresie od 0 do 59. Użycie wartości 60 w ciągu minut lub sekund powoduje błąd 500 — wewnętrzny błąd serwera.	Domyślny: 00:02:00 Min: 00:00:00 Max: 360:00:00
shutdownTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na bezproblemowe zamknięcie pliku wykonywalnego po app_offline.htm wykryciu pliku.	Domyślny: 10 Min: 0 Max: 600
startupTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na uruchomienie procesu nasłuchiwania na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zabije proces. Podczas hostowania w procesie: proces nie jest uruchamiany ponownie i nie używa rapidFailsPerMinute tego ustawienia. Podczas hostowania procesu poza procesem: moduł próbuje ponownie uruchomić rapidFailsPerMinute proces po odebraniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu na kolejnych żądaniach przychodzących, chyba że uruchomienie aplikacji nie powiedzie się liczbą razy w ostatniej chwili. Wartość 0 (zero) nie jest uważana za nieskończony limit czasu.	Domyślny: 120 Min: 0 Max: 3600
stdoutLogEnabled	Opcjonalny atrybut logiczny. Jeśli wartość true, stdout i stderr dla procesu określonego w processPath parametrze są przekierowywane do pliku określonego w pliku stdoutLogFile.	false
stdoutLogFile	Opcjonalny atrybut ciągu. Określa względną lub bezwzględną ścieżkę pliku, dla której stdout i stderr z procesu określonego w pliku processPath są rejestrowane. Ścieżki względne są względne względem katalogu głównego witryny. Każda ścieżka rozpoczynająca się od . jest względna względem katalogu głównego witryny, a wszystkie inne ścieżki są traktowane jako ścieżki bezwzględne. Wszystkie foldery podane w ścieżce są tworzone przez moduł podczas tworzenia pliku dziennika. Przy użyciu ograniczników podkreślenia znacznik czasu, identyfikator procesu i rozszerzenia pliku (.log) są dodawane do ostatniego segmentu stdoutLogFile ścieżki. Jeśli .\logs\stdout zostanie podany jako wartość, przykładowy dziennik stdout jest zapisywany jako stdout_20180205194132_1934.log w logs folderze zapisanym w dniu 2/5/2018 o 19:41:32 z identyfikatorem procesu 1934.	aspnetcore-stdout

Ustawianie zmiennych środowiskowych

Zmienne środowiskowe można określić dla procesu w atrybucie processPath . Określ zmienną środowiskową z <environmentVariable> elementem podrzędnym <environmentVariables> elementu kolekcji. Zmienne środowiskowe ustawione w tej sekcji mają pierwszeństwo przed zmiennymi środowiskowymi systemu.

W poniższym przykładzie ustawiono dwie zmienne środowiskowe. ASPNETCORE_ENVIRONMENT konfiguruje środowisko aplikacji na Development. Deweloper może tymczasowo ustawić tę wartość w pliku, web.config aby wymusić załadowanie strony wyjątków dla deweloperów podczas debugowania wyjątku aplikacji. CONFIG_DIR jest przykładem zmiennej środowiskowej zdefiniowanej przez użytkownika, w której deweloper napisał kod, który odczytuje wartość podczas uruchamiania, aby utworzyć ścieżkę ładowania pliku konfiguracji aplikacji.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="inprocess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
    <environmentVariable name="CONFIG_DIR" value="f:\application_config" />
  </environmentVariables>
</aspNetCore>

Uwaga

Alternatywą dla ustawienia środowiska bezpośrednio w programie web.config jest uwzględnienie <EnvironmentName> właściwości w profilu publikowania (.pubxml) lub pliku projektu. To podejście ustawia środowisko w web.config momencie opublikowania projektu:

<PropertyGroup>
  <EnvironmentName>Development</EnvironmentName>
</PropertyGroup>

Ostrzeżenie

Ustaw zmienną ASPNETCORE_ENVIRONMENT środowiskową na Development na serwery przejściowe i testowe, które nie są dostępne dla niezaufanych sieci, takich jak Internet.

app_offline.htm

Jeśli plik o nazwie app_offline.htm zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core próbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie żądań przychodzących. Jeśli aplikacja jest nadal uruchomiona po liczbie sekund zdefiniowanych w programie shutdownTimeLimit, moduł ASP.NET Core zabija uruchomiony proces.

app_offline.htm Gdy plik jest obecny, moduł ASP.NET Core odpowiada na żądania, wysyłając z powrotem zawartość app_offline.htm pliku. Po usunięciu app_offline.htm pliku następne żądanie uruchamia aplikację.

W przypadku korzystania z modelu hostingu poza procesem aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie protokołu websocket może opóźnić zamknięcie aplikacji.

Strona błędu uruchamiania

Zarówno w procesie, jak i poza procesem hostingu generują niestandardowe strony błędów, gdy nie można uruchomić aplikacji.

Jeśli moduł ASP.NET Core nie może znaleźć procedury obsługi żądań w procesie lub poza procesem, zostanie wyświetlona strona kodowa stanu błędu ładowania 500.0 — In-Process/Out-Of-Process Handler.

W przypadku hostowania w procesie, jeśli nie można uruchomić aplikacji modułu ASP.NET Core, zostanie wyświetlona strona kod stanu błędu 500.30.

W przypadku hostowania poza procesem, jeśli moduł ASP.NET Core nie uruchamia procesu zaplecza lub proces zaplecza rozpoczyna się, ale nie można nasłuchiwać na skonfigurowanym porcie, zostanie wyświetlona strona kod stanu błędu procesu 502.5.

Aby pominąć tę stronę i przywrócić domyślną stronę kodu stanu usług IIS 5xx, użyj atrybutu disableStartUpErrorPage . Aby uzyskać więcej informacji na temat konfigurowania niestandardowych komunikatów o błędach, zobacz Http Errors httpErrors> (Błędy <HTTP).

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe stdout i stderr konsoli do dysku, jeśli stdoutLogEnabled ustawiono atrybuty i stdoutLogFile elementuaspNetCore. Wszystkie foldery w ścieżce stdoutLogFile są tworzone przez moduł podczas tworzenia pliku dziennika. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (służy IIS AppPool\{APP POOL NAME} do udostępniania uprawnień do zapisu, gdzie symbol zastępczy {APP POOL NAME} jest nazwą puli aplikacji).

Dzienniki nie są obracane, chyba że nastąpi ponowne odtwarzanie/ponowne uruchomienie procesu. Jest to odpowiedzialność hosta za ograniczenie miejsca na dysku używanego przez dzienniki.

Korzystanie z dziennika stdout jest zalecane tylko do rozwiązywania problemów z uruchamianiem aplikacji podczas hostowania w usługach IIS lub korzystania z obsługi czasu programowania usług IIS w programie Visual Studio, a nie podczas debugowania lokalnie i uruchamiania aplikacji za pomocą IIS Express.

Nie używaj dziennika stdout do ogólnych celów rejestrowania aplikacji. W przypadku rutynowego rejestrowania w aplikacji ASP.NET Core użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Sygnatura czasowa i rozszerzenie pliku są dodawane automatycznie po utworzeniu pliku dziennika. Nazwa pliku dziennika składa się z dołączania sygnatury czasowej, identyfikatora procesu i rozszerzenia pliku () do ostatniego segmentu stdoutLogFile ścieżki (.logzazwyczaj stdout) rozdzielanej znakami podkreślenia. stdoutLogFile Jeśli ścieżka zakończy się ciągiem stdout, dziennik aplikacji o identyfikatorze PID z 1934 r. utworzonym 2.5.2018 o godzinie 19:42:32 ma nazwę stdout_20180205194132_1934.logpliku .

Jeśli stdoutLogEnabled jest to fałsz, błędy występujące podczas uruchamiania aplikacji są przechwytywane i emitowane do dziennika zdarzeń do 30 KB. Po uruchomieniu wszystkie dodatkowe dzienniki zostaną odrzucone.

Poniższy przykładowy aspNetCore element konfiguruje rejestrowanie stdout w ścieżce .\log\względnej . Upewnij się, że tożsamość użytkownika puli aplikacji ma uprawnienia do zapisu w podanej ścieżce.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout"
    hostingModel="inprocess">
</aspNetCore>

Podczas publikowania aplikacji na potrzeby wdrożenia Azure App Service zestaw Web SDK ustawia stdoutLogFile wartość na \\?\%home%\LogFiles\stdout. Zmienna %home środowiskowa jest wstępnie zdefiniowana dla aplikacji hostowanych przez Azure App Service.

Aby uzyskać więcej informacji na temat formatów ścieżek, zobacz Formaty ścieżek plików w systemach Windows.

Rozszerzone dzienniki diagnostyczne

Moduł ASP.NET Core można skonfigurować w celu zapewnienia rozszerzonych dzienników diagnostycznych. <handlerSettings> Dodaj element do elementu w pliku <aspNetCore>web.config. Ustawienie wartości w debugLevel celu TRACE uwidocznienia wyższej wierności informacji diagnostycznych:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
    <handlerSetting name="debugLevel" value="FILE,TRACE" />
  </handlerSettings>
</aspNetCore>

Foldery w ścieżce podanej <handlerSetting> do wartości (logs w poprzednim przykładzie) nie są tworzone automatycznie przez moduł i powinny istnieć wstępnie we wdrożeniu. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (służy IIS AppPool\{APP POOL NAME} do udostępniania uprawnień do zapisu, gdzie symbol zastępczy {APP POOL NAME} jest nazwą puli aplikacji).

Wartości poziomu debugowania (debugLevel) mogą obejmować zarówno poziom, jak i lokalizację.

Poziomy (w kolejności od najmniejszej do najbardziej pełnej):

• BŁĄD
• OSTRZEŻENIE
• INFORMACJI
• TRACE

Lokalizacje (dozwolone są wiele lokalizacji):

• KONSOLI
• EVENTLOG
• PLIK

Ustawienia procedury obsługi można również podać za pomocą zmiennych środowiskowych:

• ASPNETCORE_MODULE_DEBUG_FILE: ścieżka do pliku dziennika debugowania. (Wartość domyślna: aspnetcore-debug.log)
• ASPNETCORE_MODULE_DEBUG: Ustawienie poziomu debugowania.

Ostrzeżenie

Nie pozostawiaj włączonego rejestrowania debugowania we wdrożeniu dłużej niż wymagane do rozwiązania problemu. Rozmiar dziennika nie jest ograniczony. Pozostawienie włączonego dziennika debugowania może wyczerpać dostępne miejsce na dysku i awarii serwera lub usługi App Service.

Zobacz Configuration with web.config(Konfiguracja z web.config ), aby zapoznać się z przykładem aspNetCore elementu w web.config pliku.

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

Dotyczy tylko hostingu poza procesem.

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

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

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

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

W przypadku korzystania z konfiguracji udostępnionej usług IIS na tej samej maszynie co instalacja usług IIS uruchom instalatora pakietu hostingowego ASP.NET Core z parametrem ustawionym na OPT_NO_SHARED_CONFIG_CHECK1:

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

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

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

Dzienniki instalatora wersji modułu i pakietu hostingowego

Aby określić wersję zainstalowanego modułu ASP.NET Core:

1. W systemie hostingu przejdź do adresu %windir%\System32\inetsrv.
2. aspnetcore.dll Znajdź plik.
3. Kliknij plik prawym przyciskiem myszy i wybierz polecenie Właściwości z menu kontekstowego.
4. Wybierz kartę Szczegóły . Wersja pliku i wersja produktu reprezentują zainstalowaną wersję modułu.

Dzienniki instalatora pakietu hostingu dla modułu znajdują się pod adresem C:\\Users\\%UserName%\\AppData\\Local\\Temp. Plik ma nazwę dd_DotNetCoreWinSvrHosting__\{TIMESTAMP}_000_AspNetCoreModule_x64.log, gdzie symbol zastępczy {TIMESTAMP} to sygnatura czasowa.

Lokalizacje plików modułu, schematu i konfiguracji

Moduł

IIS (x86/amd64):

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

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

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

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

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

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

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

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

Schemat

IIS

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

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

IIS Express

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

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

Konfigurowanie

IIS

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

IIS Express

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

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

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

Moduł ASP.NET Core (ANCM) to natywny moduł usług IIS, który podłącza potok usług IIS do przekazywania żądań internetowych do zaplecza ASP.NET Core aplikacji.

Obsługiwane wersje systemu Windows:

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

Moduł działa tylko z programem Kestrel. Moduł jest niezgodny z HTTP.sys.

Ponieważ ASP.NET Core aplikacje działają w procesie oddzielnym od procesu roboczego usług IIS, moduł obsługuje również zarządzanie procesami. Moduł uruchamia proces aplikacji ASP.NET Core po odebraniu pierwszego żądania i ponownym uruchomieniu aplikacji w przypadku awarii. Jest to zasadniczo takie samo zachowanie jak w przypadku aplikacji ASP.NET 4.x, które są uruchamiane w ramach procesów w usługach IIS zarządzanych przez usługę aktywacji procesów systemu Windows (WAS).

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

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

Moduł określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania, a oprogramowanie pośredniczące integracji usług IIS konfiguruje serwer do nasłuchiwania na porcie http://localhost:{port}. Wykonywane są dodatkowe kontrole, a żądania, które nie pochodzą z modułu, są odrzucane. Moduł nie obsługuje przekazywania HTTPS, dlatego żądania są przekazywane za pośrednictwem protokołu HTTP, nawet jeśli zostały odebrane przez usługi IIS za pośrednictwem protokołu HTTPS.

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

Wiele modułów natywnych, takich jak uwierzytelnianie systemu Windows, pozostaje aktywnych. Aby dowiedzieć się więcej na temat modułów usług IIS aktywnych za pomocą modułu ASP.NET Core, zobacz Moduły usług IIS z ASP.NET Core.

Moduł ASP.NET Core może również wykonywać następujące czynności:

• Ustaw zmienne środowiskowe dla procesu roboczego.
• Rejestrowanie danych wyjściowych stdout w magazynie plików na potrzeby rozwiązywania problemów z uruchamianiem.
• Przekazywanie tokenów uwierzytelniania systemu Windows.

Jak zainstalować moduł ASP.NET Core (ANCM) i korzystać z niego

Aby uzyskać instrukcje dotyczące sposobu instalowania modułu ASP.NET Core, zobacz Instalowanie pakietu hostingu platformy .NET Core.

Konfiguracja przy użyciu web.config

Moduł ASP.NET Core jest skonfigurowany z sekcją aspNetCoresystem.webServer węzła w pliku web.configlokacji.

Następujący plik web.config jest publikowany na potrzeby wdrożenia zależnego od platformy i konfiguruje moduł ASP.NET Core do obsługi żądań lokacji:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet"
                arguments=".\MyApp.dll"
                stdoutLogEnabled="false"
                stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Następujące web.config są publikowane dla samodzielnego wdrożenia:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\MyApp.exe"
                stdoutLogEnabled="false"
                stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Po wdrożeniu aplikacji w Azure App Service ścieżka jest ustawiona stdoutLogFile na \\?\%home%\LogFiles\stdout. Ścieżka zapisuje dzienniki stdout w folderze LogFiles , który jest lokalizacją utworzoną automatycznie przez usługę.

Aby uzyskać informacje na temat konfiguracji podapliki usług IIS, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

Atrybuty elementu aspNetCore

Atrybut	Opis	Domyślny
arguments	Opcjonalny atrybut ciągu. Argumenty do pliku wykonywalnego określonego w processPath.
disableStartUpErrorPage	Opcjonalny atrybut logiczny. Jeśli wartość true, strona 502.5 — Niepowodzenie procesu jest pomijana, a strona kodowa stanu 502 skonfigurowana w web.config ma pierwszeństwo.	false
forwardWindowsAuthToken	Opcjonalny atrybut logiczny. Jeśli wartość true, token jest przekazywany do procesu podrzędnego nasłuchiwania w %ASPNETCORE_PORT% jako nagłówek "MS-ASPNETCORE-WINAUTHTOKEN" na żądanie. Jest to odpowiedzialność za wywołanie metody CloseHandle na tym tokenie na żądanie.	true
processesPerApplication	Opcjonalny atrybut liczby całkowitej. Określa liczbę wystąpień procesu określonego w ustawieniu processPath , które można połączyć dla aplikacji. Nie zaleca się ustawiania processesPerApplication . Ten atrybut zostanie usunięty w przyszłej wersji.	Domyślny: 1 Min: 1 Max: 100
processPath	Wymagany atrybut ciągu. Ścieżka do pliku wykonywalnego, który uruchamia proces nasłuchiwania żądań HTTP. Ścieżki względne są obsługiwane. Jeśli ścieżka zaczyna się od ., ścieżka jest uważana za względną względem katalogu głównego witryny.
rapidFailsPerMinute	Opcjonalny atrybut liczby całkowitej. Określa, ile razy proces określony w processPath może ulec awarii na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces w pozostałej części minuty.	Domyślny: 10 Min: 0 Max: 100
requestTimeout	Opcjonalny atrybut przedziału czasu. Określa czas trwania oczekiwania modułu ASP.NET Core na odpowiedź z procesu nasłuchiwania %ASPNETCORE_PORT%. W wersjach modułu ASP.NET Core dostarczanego z wydaniem ASP.NET Core 2.1 lub nowszym parametr requestTimeout jest określony w godzinach, minutach i sekundach.	Domyślny: 00:02:00 Min: 00:00:00 Max: 360:00:00
shutdownTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na bezproblemowe zamknięcie pliku wykonywalnego po app_offline.htm wykryciu pliku.	Domyślny: 10 Min: 0 Max: 600
startupTimeLimit	Opcjonalny atrybut liczby całkowitej. Czas trwania w sekundach oczekiwania modułu na uruchomienie procesu nasłuchiwania na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zabije proces. Moduł próbuje ponownie uruchomić proces po odebraniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu na kolejnych żądaniach przychodzących, chyba że aplikacja nie może uruchomić funkcji rapidFailsPerMinute kilka razy w ostatniej chwili. Wartość 0 (zero) nie jest uważana za nieskończony limit czasu.	Domyślny: 120 Min: 0 Max: 3600
stdoutLogEnabled	Opcjonalny atrybut logiczny. Jeśli wartość true, stdout i stderr dla procesu określonego w processPath są przekierowywane do pliku określonego w pliku stdoutLogFile.	false
stdoutLogFile	Opcjonalny atrybut ciągu. Określa względną lub bezwzględną ścieżkę pliku, dla której są rejestrowane ścieżki stdout i stderr z procesu określonego w ścieżce processPath . Ścieżki względne są względne względem katalogu głównego witryny. Każda ścieżka rozpoczynająca się od . jest względna względem katalogu głównego witryny, a wszystkie inne ścieżki są traktowane jako ścieżki bezwzględne. Wszystkie foldery podane w ścieżce muszą istnieć, aby moduł utworzył plik dziennika. Przy użyciu ograniczników podkreślenia sygnatura czasowa, identyfikator procesu i rozszerzenie pliku (.log) są dodawane do ostatniego segmentu ścieżki stdoutLogFile . Jeśli .\logs\stdout zostanie podany jako wartość, przykładowy dziennik stdout zostanie zapisany jako stdout_20180205194132_1934.log w folderze logs zapisanym w dniu 2/5/2018 o godzinie 19:41:32 z identyfikatorem procesu 1934.	aspnetcore-stdout

Ustawianie zmiennych środowiskowych

Zmienne środowiskowe można określić dla procesu w atrybucie processPath . Określ zmienną środowiskową z <environmentVariable> elementem podrzędnym <environmentVariables> elementu kolekcji.

Ostrzeżenie

Zmienne środowiskowe ustawione w tej sekcji powodują konflikt ze zmiennymi środowiskowymi systemowymi ustawionymi pod tą samą nazwą. Jeśli zmienna środowiskowa jest ustawiana zarówno w pliku web.config , jak i na poziomie systemu Windows, wartość pliku web.config zostanie dołączona do wartości zmiennej środowiskowej systemu (na przykład ASPNETCORE_ENVIRONMENT: Development;Development), co uniemożliwia uruchamianie aplikacji.

W poniższym przykładzie ustawiono dwie zmienne środowiskowe. ASPNETCORE_ENVIRONMENT konfiguruje środowisko aplikacji na Development. Deweloper może tymczasowo ustawić tę wartość w pliku web.config , aby wymusić załadowanie strony wyjątków dla deweloperów podczas debugowania wyjątku aplikacji. CONFIG_DIR jest przykładem zmiennej środowiskowej zdefiniowanej przez użytkownika, w której deweloper napisał kod, który odczytuje wartość podczas uruchamiania, aby utworzyć ścieżkę ładowania pliku konfiguracji aplikacji.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile="\\?\%home%\LogFiles\stdout">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
    <environmentVariable name="CONFIG_DIR" value="f:\application_config" />
  </environmentVariables>
</aspNetCore>

Ostrzeżenie

Ustaw zmienną ASPNETCORE_ENVIRONMENT środowiskową na Development na serwery przejściowe i testowe, które nie są dostępne dla niezaufanych sieci, takich jak Internet.

app_offline.htm

Jeśli plik o nazwie app_offline.htm zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core próbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie żądań przychodzących. Jeśli aplikacja jest nadal uruchomiona po liczbie sekund zdefiniowanych w programie shutdownTimeLimit, moduł ASP.NET Core zabija uruchomiony proces.

app_offline.htm Gdy plik jest obecny, moduł ASP.NET Core odpowiada na żądania, wysyłając z powrotem zawartość app_offline.htm pliku. Po usunięciu app_offline.htm pliku następne żądanie uruchamia aplikację.

Strona błędu uruchamiania

Jeśli moduł ASP.NET Core nie uruchamia procesu zaplecza lub proces zaplecza rozpoczyna się, ale nie można nasłuchiwać na skonfigurowanym porcie, zostanie wyświetlona strona kodowa stanu błędu procesu 502.5. Aby pominąć tę stronę i przywrócić domyślną stronę kodu stanu usług IIS 502, użyj atrybutu disableStartUpErrorPage . Aby uzyskać więcej informacji na temat konfigurowania niestandardowych komunikatów o błędach, zobacz Http Errors httpErrors> (Błędy <HTTP).

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe stdout i stderr konsoli do dysku, jeśli stdoutLogEnabled ustawiono atrybuty i stdoutLogFile elementuaspNetCore. Wszystkie foldery w ścieżce stdoutLogFile są tworzone przez moduł podczas tworzenia pliku dziennika. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (służy IIS AppPool\<app_pool_name> do udostępniania uprawnień do zapisu).

Dzienniki nie są obracane, chyba że nastąpi ponowne odtwarzanie/ponowne uruchomienie procesu. Jest to odpowiedzialność hosta za ograniczenie miejsca na dysku używanego przez dzienniki.

Korzystanie z dziennika stdout jest zalecane tylko do rozwiązywania problemów z uruchamianiem aplikacji podczas hostowania w usługach IIS lub korzystania z obsługi czasu programowania usług IIS w programie Visual Studio, a nie podczas debugowania lokalnie i uruchamiania aplikacji za pomocą IIS Express.

Nie używaj dziennika stdout do ogólnych celów rejestrowania aplikacji. W przypadku rutynowego rejestrowania w aplikacji ASP.NET Core użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Sygnatura czasowa i rozszerzenie pliku są dodawane automatycznie po utworzeniu pliku dziennika. Nazwa pliku dziennika składa się z dołączania sygnatury czasowej, identyfikatora procesu i rozszerzenia pliku (.log) do ostatniego stdoutLogFile segmentu ścieżki (zazwyczaj stdout) rozdzielanej znakami podkreślenia. stdoutLogFile Jeśli ścieżka kończy się stdout, dziennik aplikacji o identyfikatorze PID z 1934 utworzonym w dniu 2.5.5.2018 o godzinie 19:42:32 ma nazwę pliku stdout_20180205194132_1934.log.

Poniższy przykładowy aspNetCore element konfiguruje rejestrowanie stdout w ścieżce .\log\względnej . Upewnij się, że tożsamość użytkownika puli aplikacji ma uprawnienia do zapisu w podanej ścieżce.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout">
</aspNetCore>

Podczas publikowania aplikacji na potrzeby wdrożenia Azure App Service zestaw Web SDK ustawia stdoutLogFile wartość na \\?\%home%\LogFiles\stdout. Zmienna %home środowiskowa jest wstępnie zdefiniowana dla aplikacji hostowanych przez Azure App Service.

Aby utworzyć reguły filtru rejestrowania, zobacz sekcję Zastosuj reguły filtrowania dzienników w dokumentacji rejestrowania ASP.NET Core.

Aby uzyskać więcej informacji na temat formatów ścieżek, zobacz Formaty ścieżek plików w systemach Windows.

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

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

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

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

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

W przypadku korzystania z konfiguracji udostępnionej usług IIS wykonaj następujące kroki:

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

Dzienniki instalatora wersji modułu i pakietu hostingowego

Aby określić wersję zainstalowanego modułu ASP.NET Core:

1. W systemie hostingu przejdź do folderu %windir%\System32\inetsrv.
2. Znajdź plik aspnetcore.dll .
3. Kliknij prawym przyciskiem myszy plik i wybierz polecenie Właściwości z menu kontekstowego.
4. Wybierz kartę Szczegóły . Wersja pliku i wersja produktu reprezentują zainstalowaną wersję modułu.

Dzienniki instalatora pakietu hostingowego dla modułu znajdują się w folderze C:\Users\%UserName%\AppData\Local\Temp. Plik ma nazwę dd_DotNetCoreWinSvrHosting__<timestamp>_000_AspNetCoreModule_x64.log.

Lokalizacje plików modułu, schematu i konfiguracji

Moduł

IIS (x86/amd64):

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

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

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

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

Schemat

IIS

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

IIS Express

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

Konfigurowanie

IIS

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

IIS Express

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

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

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

Dodatkowe zasoby

• Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
• Wdrażanie aplikacji ASP.NET Core w usłudze Azure App Service
• ASP.NET Core Źródło referencyjne modułu [domyślna gałąź (main)]: Użyj listy rozwijanej Gałąź, aby wybrać określoną wersję (na przykład release/3.1).
• Moduły usług IIS z platformą ASP.NET Core