Moduł ASP.NET Core

A więc: Tom Dykstra, Rick Strahl, Chris Dostęp, Rick Anderson, Sourabh Shirhabhi Justin Kotalik

Moduł ASP.NET Core to natywny moduł usług IIS, który podłącza się do potoku usług IIS, umożliwiając ASP.NET Core aplikacjom pracę z usługami IIS. Uruchom ASP.NET Core aplikacji za pomocą usług IIS przez:

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

Każdy z modeli hostingu ma związek z różnicami. Domyślnie model hostingu w procesie jest używany ze względu na lepszą wydajność i diagnostykę.

Instalowanie ASP.NET Core modułu

Moduł ASP.NET Core jest instalowany ze środowiskiem uruchomieniowym .NET Core Runtime z pakietu hostingu .NET Core. Moduł ASP.NET Core jest zgodny do przodu i z poprzednimi wersjami lts programu .NET.

Istotne zmiany i biuletyny zabezpieczeń są zgłaszane w repo anonsach. Anonse można ograniczyć do określonej wersji, wybierając filtr Etykieta.

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

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

Aby uzyskać więcej informacji, w tym na temat instalowania starszej wersji modułu, zobacz Pakiet hostingu .

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 .

Moduł ASP.NET Core to natywny moduł usług IIS, który podłącza potok usług IIS do jednego z tych modułów:

Obsługiwane Windows wersji:

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

W przypadku hostowania poza procesem moduł działa tylko z usługą Kestrel . Moduł nie działa zHTTP.sys.

Modele hostingu

Model hostingu w procesie

ASP.NET Core domyślne dla modelu hostowania w procesie.

Podczas hostowania w procesie mają zastosowanie następujące charakterystyki:

  • Zamiast serwera jest używany serwer HTTP usług IIS IISHttpServer Kestrel (). W przypadku procesu CreateDefaultBuilder UseIIS wywołuje:

    • Zarejestruj IISHttpServer .
    • Skonfiguruj port i ścieżkę podstawową, na których powinien nasłuchiwać serwer podczas uruchamiania za modułem ASP.NET Core danych.
    • 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 Web Deploy lub ręcznego app_offline.htm umieszczenia pliku we wdrożeniu aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie webSocket może opóźnić zamknięcie aplikacji.

  • Architektura (bitowość) aplikacji i zainstalowanego środowiska uruchomieniowego (x64 lub x86) muszą być zgodne z architekturą puli aplikacji.

  • Wykryto rozłączenie klienta. Token HttpContext.RequestAborted anulowania jest anulowany, gdy klient rozłączy się.

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

    Przykładowy kod, który ustawia bieżący katalog aplikacji, można znaleźć w CurrentDirectoryHelpers klasie. Wywołaj SetCurrentDirectory metodę . Kolejne wywołania GetCurrentDirectory w celu podania katalogu aplikacji.

  • Podczas hostowania w procesie program nie jest wywoływany wewnętrznie w celu AuthenticateAsync zainicjowania użytkownika. W związku z tym IClaimsTransformation implementacja używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie aktywowana. Podczas przekształcania oświadczeń za pomocą IClaimsTransformation implementacji wywołaj metodę AddAuthentication , 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ę do hostowania poza procesem, ustaw wartość właściwości na <AspNetCoreHostingModel> w pliku projektu ( OutOfProcess .csproj ):

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

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

Wartość jest bez <AspNetCoreHostingModel> uwzględniania liter, więc i inprocessoutofprocess prawidłowymi wartościami.

Kestrel zamiast serwera HTTP usług IIS ( IISHttpServer ).

W przypadku poza procesem CreateDefaultBuilder wywołania: UseIISIntegration

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

Zmiany modelu hostingu

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

Na IIS Express moduł nie odtwarza procesu roboczego, ale zamiast tego wyzwala graceful shutdown bieżącego IIS Express procesu. Następne żądanie do aplikacji duplikuje nowy proces IIS Express aplikacji.

Nazwa procesu

Process.GetCurrentProcess().ProcessNameraporty w3wp / iisexpress (w trakcie przetwarzania) dotnet lub (poza procesem).

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

Moduł ASP.NET Core może również:

  • Ustaw zmienne środowiskowe dla procesu roboczego.
  • Wyloguj dane wyjściowe stdout do magazynu plików, aby rozwiązać problemy z uruchamianiem.
  • Przekazywanie Windows tokenów uwierzytelniania.

Jak zainstalować moduł ASP.NET Core i korzystać z tego modułu

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

Istotne zmiany i biuletyny zabezpieczeń są zgłaszane w repo anonsach. Anonse można ograniczyć do określonej wersji, wybierając filtr Etykieta.

Konfiguracja za pomocą web.config

Moduł ASP.NET Core jest skonfigurowany za pomocą sekcji węzła w plikuweb.configaspNetCore system.webServer lokacji.

Poniższy plik jest publikowany dla wdrożenia zależnego od struktury i konfiguruje moduł web.config 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 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 na wartość , aby wskazać, że ustawienia określone w elemencie nie są dziedziczone przez aplikacje, które znajdują się w InheritInChildApplications false <location> podkatalogu aplikacji.

Gdy aplikacja jest wdrażana w Azure App Service, stdoutLogFile ścieżka jest ustawiana 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 aplikacji podrzędnej usług IIS, zobacz Hostowanie ASP.NET Core na Windows za pomocą usług IIS .

Atrybuty elementu aspNetCore

Atrybut Opis Domyślne
arguments

Opcjonalny atrybut ciągu.

Argumenty pliku wykonywalnego określonego w processPath.

disableStartUpErrorPage

Opcjonalny atrybut logiczny.

W przypadku wartości true strona 502.5 — niepowodzenie procesu jest pomijana, a pierwszeństwo ma strona kodowa stanu 502 skonfigurowana wweb.configawarii.

false
forwardWindowsAuthToken

Opcjonalny atrybut logiczny.

W przypadku wartości true token jest przesyłany dalej do procesu podrzędnego, który nasłuchuje w %ASPNETCORE_PORT% nagłówku 'MS-ASPNETCORE-WINAUTHTOKEN' na każde żądanie. Ten proces odpowiada za wywołanie closehandle dla tego tokenu dla każdego żądania.

true
hostingModel

Opcjonalny atrybut ciągu.

Określa model hostingu jako model w procesie InProcess / inprocess () lub poza procesem OutOfProcess / outofprocess ().

InProcess
inprocess
processesPerApplication

Opcjonalny atrybut liczby całkowitej.

Określa liczbę wystąpień procesu określoną w ustawieniu processPath, które można skonfigurować dla określonej aplikacji.

†W przypadku hostingu w procesie wartość jest ograniczona do 1 .

Ustawienie processesPerApplication nie jest zalecane. 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łuchujący żądań HTTP. Obsługiwane są ścieżki względne. Jeśli ścieżka rozpoczyna się od , ścieżka jest uważana za . względną względem katalogu głównego lokacji.

rapidFailsPerMinute

Opcjonalny atrybut liczby całkowitej.

Określa, ile razy proces określony w processPath może ulegać awarii na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces przez pozostałą część minuty.

Nie jest obsługiwana w przypadku hostingu w procesie.

Domyślny: 10
Min: 0
Max: 100
requestTimeout

Opcjonalny atrybut czasu.

Określa czas, przez który moduł ASP.NET Core oczekuje na odpowiedź z procesu nasłuchujący %ASPNETCORE_PORT%.

W wersjach modułu ASP.NET Core, który został dostarczony w wersji ASP.NET Core 2.1 lub nowszej, wartość jest określana w requestTimeout godzinach, minutach i sekundach.

Nie dotyczy hostingu w procesie. W przypadku hostowania w procesie moduł czeka na przetworzyć żądanie 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 wartości 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), przez który moduł czeka, aż plik wykonywalny zostanie bezpiecznie zamknięty po wykryciuapp_offline.htm pliku wykonywalnego.

Domyślny: 10
Min: 0
Max: 600
startupTimeLimit

Opcjonalny atrybut liczby całkowitej.

Czas trwania (w sekundach), przez który moduł czeka, aż plik wykonywalny rozpocznie proces nasłuchujący na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zakańczy proces.

W przypadku hostowania w procesie: proces nie jest uruchamiany ponownie i nie używa ustawienia rapidFailsPerMinute.

Podczas hostowania poza procesem: moduł próbuje ponownie uruchomić proces po otrzymaniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu dla kolejnych żądań przychodzących, chyba że aplikacja nie uruchomi liczby razy rapidFailsPerMinute w ostatniej kroczącej minucie.

Wartość 0 (zero) nie jest uznawana 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ą przekierowywany do pliku określonego w stdoutLogFile.

false
stdoutLogFile

Opcjonalny atrybut ciągu.

Określa względną lub bezwzględną ścieżkę pliku, dla którego są rejestrowane stdout i stderr z procesu określonego w ścieżce processPath. Ścieżki względne są względne względem katalogu głównego lokacji. Wszystkie ścieżki rozpoczynające się od są względne względem katalogu głównego lokacji, 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 rozszerzenie pliku ( ) są dodawane do ostatniego .log segmentu ścieżki stdoutLogFile. Jeśli element jest podany jako wartość, przykładowy dziennik stdout jest zapisywany jako w folderze po zapisaniu w dniu .\logs\stdout stdout_20180205194132_1934.log logs 5.02.2018 o godzinie 19:41:32 z identyfikatorem procesu 1934.

aspnetcore-stdout

Ustawianie zmiennych środowiskowych

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

W poniższym przykładzie ustawiane są dwie zmienne środowiskowe w web.config . ASPNETCORE_ENVIRONMENT Konfiguruje środowisko aplikacji na Development . Deweloper może tymczasowo ustawić tę wartość w pliku, aby wymusić załadowanie strony wyjątku dewelopera podczas web.config 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, tworząc ścieżkę do ł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 jest dołączenie właściwości do profilu web.config <EnvironmentName> publikowania .pubxml () lub pliku projektu. Takie podejście ustawia środowisko w web.config programie podczas publikacji projektu:

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

Ostrzeżenie

Zmienną środowiskową należy ustawić tylko na serwerach przejściowych i testowych, które nie są dostępne dla niezaufanych sieci, takich ASPNETCORE_ENVIRONMENT Development jak Internet.

app_offline.htm

Jeśli plik o nazwie zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core spróbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie żądań app_offline.htm przychodzących. Jeśli aplikacja jest nadal uruchomiona po upływie liczby sekund zdefiniowanej w , moduł ASP.NET Core moduł kills the running process (Moduł aplikacji ASP.NET Core shutdownTimeLimit działanie).

Gdy plik jest obecny, moduł ASP.NET Core odpowiada na żądania, wysyłając z powrotem app_offline.htm zawartość app_offline.htm pliku. Po app_offline.htm usunięciu 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 webSocket może opóźnić zamknięcie aplikacji.

Strona błędu uruchamiania

Hostowanie zarówno w procesie, jak i poza procesem umożliwia tworzenie niestandardowych stron błędów, gdy uruchomienie aplikacji nie powiedzie się.

Jeśli moduł ASP.NET Core nie może odnaleźć procedury obsługi żądań w procesie lub poza procesem, zostanie wyświetlona strona kodowa stanu 500.0 — błąd ładowania procedury obsługi w procesie/poza procesem.

W przypadku hostowania w procesie, ASP.NET Core nie można uruchomić aplikacji, zostanie wyświetlona strona kodowa stanu 500.30 — Niepowodzenie uruchomienia.

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

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

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe konsoli stdout i stderr na dysk, jeśli ustawiono atrybuty stdoutLogEnabled stdoutLogFile i elementu aspNetCore . Wszystkie foldery w stdoutLogFile ścieżce 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 funkcji w celu IIS AppPool\<app_pool_name> zapewnienia uprawnień do zapisu).

Dzienniki nie są obracane, chyba że nastąpi ponowne uruchomienie/ponowne uruchomienie procesu. To hoster odpowiada za 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 usług IIS w czasie projektowania w programie Visual Studio, anie podczas lokalnego debugowania i uruchamiania aplikacji za pomocą programu IIS Express.

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

Znacznik czasu i rozszerzenie pliku są dodawane automatycznie podczas tworzenia pliku dziennika. Nazwa pliku dziennika składa się z dołączania znacznika czasu, identyfikatora procesu i rozszerzenia pliku ( ) do ostatniego segmentu ścieżki (zwykle ) rozdzielonych znakami .log stdoutLogFile stdout podkreślenia. Jeśli ścieżka kończy się na , dziennik aplikacji z identyfikatorem stdoutLogFile stdout PID 1934 utworzonym 5.02.2018 o godzinie 19:42:32 ma nazwę pliku stdout_20180205194132_1934.log .

W przypadku fałszu błędy występujące podczas uruchamiania aplikacji są przechwytywane i emitowane do dziennika zdarzeń o prędkości stdoutLogEnabled do 30 KB. Po uruchomieniu wszystkie dodatkowe dzienniki są odrzucane.

Poniższy aspNetCore przykładowy element konfiguruje rejestrowanie stdout w ścieżce względnej .\log\ . Upewnij się, że tożsamość użytkownika puli AppPool 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 Azure App Service zestaw SDK sieci Web ustawia stdoutLogFile wartość \\?\%home%\LogFiles\stdout na . Zmienna %home środowiskowa jest wstępnie zdefiniowana dla aplikacji hostowanych przez Azure App Service.

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

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

Ulepszone dzienniki diagnostyczne

Moduł ASP.NET Core można skonfigurować w celu zapewnienia rozszerzonych dzienników diagnostycznych. Dodaj <handlerSettings> element do <aspNetCore> elementu w elemencie web.config . Ustawienie wartości debugLevel na TRACE wartość uwidacznia wyższą wierność 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 (w poprzednim przykładzie) są tworzone przez logs moduł podczas tworzenia pliku dziennika. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (użyj elementu , gdzie symbol zastępczy jest nazwą puli aplikacji, aby IIS AppPool\{APP POOL NAME} zapewnić uprawnienia do {APP POOL NAME} zapisu).

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

Poziomy (w kolejności od najmniejszych do najbardziej pełnych):

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

Lokalizacje (dozwolone jest wiele lokalizacji):

  • KONSOLI
  • EVENTLOG
  • PLIK

Ustawienia programu obsługi można również określić za pośrednictwem 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 awarię serwera lub usługi aplikacji.

Zobacz configuration with web.config for example of the element in the file aspNetCore (Konfiguracja za pomocą web.config, aby uzyskać przykład elementu w web.config pliku .

Modyfikowanie rozmiaru stosu

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

Skonfiguruj rozmiar zarządzanego stosu przy użyciu stackSize 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 korzysta z protokołu HTTP. Nie istnieje ryzyko podsłuchiwać ruchu między modułem i z lokalizacji Kestrel poza serwerem.

Token parowania służy do zagwarantowania, że żądania odebrane przez usługę IIS zostały sytuowane i nie pochodzą Kestrel z innego źródła. Token parowania jest tworzony i ustawiany w zmiennej środowiskowej ( ASPNETCORE_TOKEN ) przez moduł. Token parowania jest również ustawiany na nagłówek ( MS-ASPNETCORE-TOKEN ) dla każdego żądania proxy. Oprogramowanie pośredniczące usług IIS sprawdza każde odbierane żądanie, aby potwierdzić, że wartość nagłówka tokenu parowania jest taka sama jak wartość 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 nie są dostępne z lokalizacji Kestrel poza serwerem. Bez znajomości wartości tokenu parowania osoba atakująca nie może przesłać żądań pomijających sprawdzanie oprogramowania pośredniczącego usług IIS.

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

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

W przypadku korzystania z konfiguracji udostępnionej usług IIS na tej samej maszynie co instalacja usług IIS uruchom instalator pakietu hostingu ASP.NET Core z parametrem OPT_NO_SHARED_CONFIG_CHECK ustawionym 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 udostępnioną konfigurację usług IIS.
  2. Uruchom instalatora.
  3. applicationHost.configWyeksportuj zaktualizowany plik do udziału.
  4. Włącz ponownie udostępnioną konfigurację usług IIS.

Dzienniki instalatora wersji modułu i pakietu hostingu

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

  1. W systemie hostingu przejdź %windir%\System32\inetsrv do .
  2. Znajdź aspnetcore.dll plik.
  3. Kliknij prawym przyciskiem myszy plik i wybierz polecenie Właściwości z menu kontekstowego.
  4. Wybierz kartę Szczegóły. Wersje File (Plik) i Product (Produkt) reprezentują zainstalowaną wersję modułu.

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

Lokalizacje modułów, schematów i plików 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źć, aspnetcore wyszukując je w pliku applicationHost.config .

Moduł ASP.NET Core to natywny moduł usług IIS, który podłącza się do potoku usług IIS w jeden z tych modułów:

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

Obsługiwane Windows wersji:

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

W przypadku hostowania poza procesem moduł działa tylko z usługą Kestrel . Moduł nie działa zHTTP.sys.

Modele hostingu

Model hostingu w procesie

Aby skonfigurować aplikację do hostowania w procesie, dodaj właściwość do pliku projektu aplikacji o wartości (hosting poza procesem jest <AspNetCoreHostingModel> InProcess ustawiany za pomocą właściwości OutOfProcess ):

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

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

W wartości jest <AspNetCoreHostingModel> bez uwzględniania liter, więc wartości i są inprocess outofprocess prawidłowymi wartościami.

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

Podczas hostowania w procesie mają zastosowanie następujące cechy:

  • Zamiast serwera jest używany serwer HTTP usług IIS IISHttpServer Kestrel (). W przypadku procesu CreateDefaultBuilder UseIIS wywołuje:

    • Zarejestruj IISHttpServer .
    • Skonfiguruj port i ścieżkę podstawową, na których serwer powinien nasłuchiwać podczas uruchamiania za modułem ASP.NET Core module.
    • Skonfiguruj hosta w celu przechwycenia 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 Web Deploy lub ręcznego umieszczenia plikuapp_offline.htmwe wdrożeniu aplikacja może nie zostać natychmiast zamknięta, jeśli istnieje otwarte połączenie. Na przykład połączenie websocket może opóźnić zamknięcie aplikacji.

  • Architektura (bitowość) aplikacji i zainstalowanego środowiska uruchomieniowego (x64 lub x86) muszą być zgodne z architekturą puli aplikacji.

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

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

    Przykładowy kod, który ustawia bieżący katalog aplikacji, można znaleźć w klasie CurrentDirectoryHelpers. Wywołaj SetCurrentDirectory metodę . Kolejne wywołania GetCurrentDirectory w celu podania katalogu aplikacji.

  • Podczas hostowania w procesie program AuthenticateAsync nie jest wywoływany wewnętrznie w celu zainicjowania użytkownika. W związku z tym implementacja używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie IClaimsTransformation aktywowana. Podczas przekształcania oświadczeń za pomocą IClaimsTransformation implementacji wywołaj metodę AddAuthentication , 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ę do hostowania poza procesem, użyj jednej z następujących metod w pliku projektu:

  • Nie określaj <AspNetCoreHostingModel> właściwości . Jeśli właściwość <AspNetCoreHostingModel> nie jest obecna w pliku, wartość domyślna to OutOfProcess .
  • Ustaw wartość właściwości na (hosting w procesie <AspNetCoreHostingModel> OutOfProcess jest ustawiany za pomocą wartości InProcess ):
<PropertyGroup>
  <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

W wartości nie jest uwzględniania liter, więc wartości inprocess i outofprocess są prawidłowymi wartościami.

Kestrel zamiast serwera HTTP usług IIS ( IISHttpServer ).

W przypadku poza procesem createDefaultBuilder UseIISIntegration wywołuje:

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

Zmiany modelu hostingu

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

Na IIS Express moduł nie odtwarza procesu roboczego, ale zamiast tego wyzwala graceful shutdown bieżącego IIS Express procesu. Następne żądanie do aplikacji duplikuje nowy proces IIS Express aplikacji.

Nazwa procesu

Process.GetCurrentProcess().ProcessNameraporty w3wp / iisexpress (w procesie) dotnet lub (poza procesem).

Wiele modułów natywnych, takich jak Windows Authentication, pozostaje aktywnych. Aby dowiedzieć się więcej o modułach 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ż:

  • Ustaw zmienne środowiskowe dla procesu roboczego.
  • Wyloguj dane wyjściowe stdout do magazynu plików w celu rozwiązywania problemów z uruchamianiem.
  • Przekazywanie Windows tokenów uwierzytelniania.

Jak zainstalować moduł ASP.NET Core i korzystać z tego modułu

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

Istotne zmiany i biuletyny zabezpieczeń są zgłaszane w repo anonsach. Anonse można ograniczyć do określonej wersji, wybierając filtr Etykieta.

Konfiguracja za pomocą web.config

Moduł ASP.NET Core jest konfigurowany przy użyciu sekcji węzła w plikuweb.configaspNetCore system.webServer lokacji.

Następujący plik web.config jest publikowany dla wdrożenia zależnego od struktury 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 na wartość , aby wskazać, że ustawienia określone w elemencie nie są dziedziczone przez aplikacje, które znajdują się w InheritInChildApplications false <location> podkatalogu aplikacji.

Gdy aplikacja jest wdrażana w Azure App Service, stdoutLogFile ścieżka jest ustawiana na \\?\%home%\LogFiles\stdout . Ścieżka zapisuje dzienniki stdout w folderze LogFiles, który jest lokalizacją automatycznie utworzoną przez usługę.

Aby uzyskać informacje na temat konfiguracji aplikacji podrzędnej usług IIS, zobacz Hostowanie ASP.NET Core na Windows za pomocą usług IIS .

Atrybuty elementu aspNetCore

Atrybut Opis Domyślne
arguments

Opcjonalny atrybut ciągu.

Argumenty pliku wykonywalnego określonego w pliku processPath .

disableStartUpErrorPage

Opcjonalny atrybut logiczny.

W przypadku wartości true strona 502.5 — niepowodzenie procesu jest pomijana, a pierwszeństwo ma strona kodowa stanu 502 skonfigurowana wweb.configawarii.

false
forwardWindowsAuthToken

Opcjonalny atrybut logiczny.

W przypadku wartości true token jest przesyłany dalej do procesu podrzędnego, który nasłuchuje w %ASPNETCORE_PORT% jako nagłówek "MS-ASPNETCORE-WINAUTHTOKEN" na żądanie. Ten proces odpowiada za wywołanie closehandle dla tego tokenu dla każdego żądania.

true
hostingModel

Opcjonalny atrybut ciągu.

Określa model hostingu jako model w procesie InProcess / inprocess () lub poza procesem OutOfProcess / outofprocess ().

OutOfProcess
outofprocess
processesPerApplication

Opcjonalny atrybut liczby całkowitej.

Określa liczbę wystąpień procesu określoną w processPath ustawieniu, które można skonfigurować dla określonej aplikacji.

†W przypadku hostingu w procesie wartość jest ograniczona do 1 .

Ustawienie processesPerApplication nie jest zalecane. 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łuchujący żądań HTTP. Obsługiwane są ścieżki względne. Jeśli ścieżka rozpoczyna się od , ścieżka jest uważana za . względną względem katalogu głównego lokacji.

rapidFailsPerMinute

Opcjonalny atrybut liczby całkowitej.

Określa, ile razy proces określony w pliku może ulegać awarii processPath na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces przez pozostałą część minuty.

Nie jest obsługiwane w przypadku hostowania w procesie.

Domyślny: 10
Min: 0
Max: 100
requestTimeout

Opcjonalny atrybut czasu.

Określa czas, przez który moduł ASP.NET Core oczekuje na odpowiedź z procesu nasłuchujący %ASPNETCORE_PORT%.

W wersjach modułu ASP.NET Core, który został dostarczony w wersji ASP.NET Core 2.1 lub nowszej, wartość jest określana w requestTimeout godzinach, minutach i sekundach.

Nie dotyczy hostingu w procesie. W przypadku hostingu w procesie moduł czeka na przetworzyć żądanie 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 wartości 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), przez który moduł czeka, aż plik wykonywalny zostanie bezpiecznie zamknięty po app_offline.htm wykryciu pliku.

Domyślny: 10
Min: 0
Max: 600
startupTimeLimit

Opcjonalny atrybut liczby całkowitej.

Czas trwania (w sekundach), przez który moduł czeka, aż plik wykonywalny rozpocznie proces nasłuchujący na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zakańczy proces.

W przypadku hostowania w procesie: proces nie jest uruchamiany ponownie i nie używa rapidFailsPerMinute ustawienia.

Podczas hostowania poza procesem: moduł próbuje ponownie uruchomić proces po otrzymaniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu dla kolejnych żądań przychodzących, chyba że aplikacja nie uruchomi się kilka razy w ciągu ostatniej minuty rapidFailsPerMinute stopniowej.

Wartość 0 (zero) nie jest uznawana za nieskończony limit czasu.

Domyślny: 120
Min: 0
Max: 3600
stdoutLogEnabled

Opcjonalny atrybut logiczny.

W przypadku wartości true wartości stdout i stderr dla procesu określonego w pliku są przekierowywani do pliku określonego w processPath pliku stdoutLogFile.

false
stdoutLogFile

Opcjonalny atrybut ciągu.

Określa względną lub bezwzględną ścieżkę pliku, dla którego i stdout z procesu określonego w są stderr processPath rejestrowane. Ścieżki względne są względne względem katalogu głównego lokacji. Wszystkie ścieżki rozpoczynające się od są względne względem katalogu głównego lokacji, 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 rozszerzenie pliku () są dodawane do ostatniego .log segmentu stdoutLogFile ścieżki. Jeśli element jest podany jako wartość, przykładowy dziennik stdout jest zapisywany jako w folderze po zapisaniu w dniu .\logs\stdout stdout_20180205194132_1934.log logs 5.02.2018 o godzinie 19:41:32 z identyfikatorem procesu 1934.

aspnetcore-stdout

Ustawianie zmiennych środowiskowych

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

W poniższym przykładzie ustawiane są dwie zmienne środowiskowe. ASPNETCORE_ENVIRONMENT Konfiguruje środowisko aplikacji na Development . Deweloper może tymczasowo ustawić tę wartość w pliku, aby wymusić załadowanie strony wyjątku dewelopera podczas web.config 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, tworząc ścieżkę do ł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 jest dołączenie właściwości w profilu web.config <EnvironmentName> publikowania (pubxml) lub pliku projektu. Takie podejście ustawia środowisko w web.config programie podczas publikacji projektu:

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

Ostrzeżenie

Zmienną środowiskową należy ustawić tylko na serwerach przejściowych i testowych, które nie są dostępne dla niezaufanych sieci, takich ASPNETCORE_ENVIRONMENT Development jak Internet.

app_offline.htm

Jeśli plik o nazwie zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core spróbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie żądań app_offline.htm przychodzących. Jeśli aplikacja jest nadal uruchomiona po upływie liczby sekund zdefiniowanej w , moduł ASP.NET Core moduł kills the running process (Moduł aplikacji ASP.NET Core shutdownTimeLimit działanie).

Gdy plik jest obecny, moduł ASP.NET Core odpowiada na żądania, wysyłając z powrotem app_offline.htm zawartość app_offline.htm pliku. Po app_offline.htm usunięciu 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 websocket może opóźnić zamknięcie aplikacji.

Strona błędu uruchamiania

Hostowanie zarówno w procesie, jak i poza procesem umożliwia tworzenie niestandardowych stron błędów, gdy uruchomienie aplikacji nie powiedzie się.

Jeśli moduł ASP.NET Core nie może odnaleźć procedury obsługi żądań w procesie lub poza procesem, zostanie wyświetlona strona kodowa stanu 500.0 — błąd ładowania procedury obsługi w procesie/poza procesem.

W przypadku hostowania w procesie, ASP.NET Core nie można uruchomić aplikacji, zostanie wyświetlona strona kodowa stanu 500.30 — Niepowodzenie uruchomienia.

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

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

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe konsoli stdout i stderr na dysk, jeśli ustawiono atrybuty stdoutLogEnabled stdoutLogFile i elementu aspNetCore . Wszystkie foldery w stdoutLogFile ścieżce 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 elementu w celu zapewnienia uprawnienia do zapisu, gdzie symbol zastępczy jest IIS AppPool\{APP POOL NAME} {APP POOL NAME} nazwą puli aplikacji).

Dzienniki nie są obracane, chyba że nastąpi ponowne uruchomienie/ponowne uruchomienie procesu. To hoster odpowiada za 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 usług IIS w czasie projektowania z programem Visual Studio, anie podczas lokalnego debugowania i uruchamiania aplikacji za pomocą programu IIS Express.

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

Znacznik czasu i rozszerzenie pliku są dodawane automatycznie podczas tworzenia pliku dziennika. Nazwa pliku dziennika składa się z dołączania znacznika czasu, identyfikatora procesu i rozszerzenia pliku ( ) do ostatniego segmentu ścieżki (zwykle ) rozdzielonych znakami .log stdoutLogFile stdout podkreślenia. Jeśli ścieżka kończy się na , dziennik aplikacji z identyfikatorem stdoutLogFile stdout PID 1934 utworzonym 5.02.2018 o godzinie 19:42:32 ma nazwę pliku stdout_20180205194132_1934.log .

W przypadku fałszu błędy występujące podczas uruchamiania aplikacji są przechwytywane i emitowane do dziennika zdarzeń o prędkości stdoutLogEnabled do 30 KB. Po uruchomieniu wszystkie dodatkowe dzienniki są odrzucane.

Poniższy aspNetCore przykładowy element konfiguruje rejestrowanie stdout w ścieżce względnej .\log\ . 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 Azure App Service zestaw SDK sieci Web ustawia stdoutLogFile wartość \\?\%home%\LogFiles\stdout na . 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 Windows systemach.

Ulepszone dzienniki diagnostyczne

Moduł ASP.NET Core można skonfigurować w celu zapewnienia rozszerzonych dzienników diagnostycznych. Dodaj <handlerSettings> element do <aspNetCore> elementu w elemencie web.config . Ustawienie wartości debugLevel na TRACE wartość uwidacznia wyższą wierność 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 do wartości (w poprzednim przykładzie) nie są tworzone automatycznie przez moduł i powinny wcześniej istnieć <handlerSetting> logs we wdrożeniu. Pula aplikacji musi mieć dostęp do zapisu w lokalizacji, w której są zapisywane dzienniki (użyj elementu w celu zapewnienia uprawnienia do zapisu, gdzie symbol zastępczy jest IIS AppPool\{APP POOL NAME} {APP POOL NAME} nazwą puli aplikacji).

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

Poziomy (w kolejności od najmniejszych do najbardziej pełnych):

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

Lokalizacje (dozwolone jest wiele lokalizacji):

  • KONSOLI
  • EVENTLOG
  • PLIK

Ustawienia programu obsługi można również określić za pośrednictwem 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 awarię serwera lub usługi aplikacji.

Zobacz configuration with web.config for example of the element in the file aspNetCore (Konfiguracja za pomocą web.config, aby uzyskać przykład 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 korzysta z protokołu HTTP. Nie istnieje ryzyko podsłuchiwać ruchu między modułem i z lokalizacji Kestrel poza serwerem.

Token parowania służy do zagwarantowania, że żądania odebrane przez usługę IIS zostały sytuowane i nie pochodzą Kestrel z innego źródła. Token parowania jest tworzony i ustawiany w zmiennej środowiskowej ( ASPNETCORE_TOKEN ) przez moduł. Token parowania jest również ustawiany na nagłówek ( MS-ASPNETCORE-TOKEN ) dla każdego żądania proxy. Oprogramowanie pośredniczące usług IIS sprawdza każde odbierane żądanie, aby potwierdzić, że wartość nagłówka tokenu parowania jest taka sama jak wartość 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 nie są dostępne z lokalizacji Kestrel poza serwerem. Bez znajomości wartości tokenu parowania osoba atakująca nie może przesłać żądań pomijających sprawdzanie oprogramowania pośredniczącego usług IIS.

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

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

W przypadku korzystania z konfiguracji udostępnionej usług IIS na tej samej maszynie co instalacja usług IIS uruchom instalator pakietu hostingu ASP.NET Core z parametrem OPT_NO_SHARED_CONFIG_CHECK ustawionym 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 udostępnioną konfigurację usług IIS.
  2. Uruchom instalatora.
  3. applicationHost.configWyeksportuj zaktualizowany plik do udziału.
  4. Włącz ponownie udostępnioną konfigurację usług IIS.

Dzienniki instalatora wersji modułu i pakietu hostingu

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

  1. W systemie hostingu przejdź %windir%\System32\inetsrv do .
  2. Znajdź aspnetcore.dll plik.
  3. Kliknij prawym przyciskiem myszy plik i wybierz polecenie Właściwości z menu kontekstowego.
  4. Wybierz kartę Szczegóły. Wersje File (Plik) i Product (Produkt) reprezentują zainstalowaną wersję modułu.

Dzienniki instalatora pakietu hostingu dla modułu znajdują się na stronie C:\\Users\\%UserName%\\AppData\\Local\\Temp . Plik ma nazwę dd_DotNetCoreWinSvrHosting__\{TIMESTAMP}_000_AspNetCoreModule_x64.log , gdzie symbol zastępczy jest {TIMESTAMP} sygnaturą czasową.

Lokalizacje modułów, schematów i plików 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

Konfiguracja

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źć, aspnetcore wyszukując je w pliku applicationHost.config .

Moduł ASP.NET Core to natywny moduł usług IIS, który podłącza się do potoku usług IIS w celu przekazywania żądań internetowych do zaplecza ASP.NET Core aplikacji.

Obsługiwane Windows wersji:

  • 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 są uruchamiane w procesie oddzielnym od procesu roboczego usług IIS, moduł obsługuje również zarządzanie procesami. Moduł uruchamia proces dla aplikacji ASP.NET Core po przyjechiniu pierwszego żądania i uruchamia ponownie aplikację w przypadku awarii. Jest to zasadniczo takie samo zachowanie jak w przypadku aplikacji programu ASP.NET 4.x uruchamianych w procesie w usługach IIS zarządzanych przez usługę aktywacji procesów Windows (WAS).

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

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, więc żą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, co wypycha ją z powrotem do klienta HTTP, który zainicjował żądanie.

Wiele modułów natywnych, takich jak Windows Authentication, pozostaje aktywnych. Aby dowiedzieć się więcej o modułach usług IIS aktywnych w ASP.NET Core module, zobacz Moduły usług IIS z ASP.NET Core .

Moduł ASP.NET Core może również:

  • Ustaw zmienne środowiskowe dla procesu roboczego.
  • Wyloguj dane wyjściowe stdout do magazynu plików w celu rozwiązywania problemów z uruchamianiem.
  • Przekazywanie Windows tokenów uwierzytelniania.

Jak zainstalować moduł ASP.NET Core i używać go

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

Konfiguracja za pomocą web.config

Moduł ASP.NET Core jest konfigurowany przy użyciu sekcji węzła w plikuweb.configaspNetCore system.webServer lokacji.

Następujący plik web.config jest publikowany dla wdrożenia zależnego od struktury 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>

Gdy aplikacja jest wdrażana w Azure App Service, stdoutLogFile ścieżka jest ustawiana 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 aplikacji podrzędnej usług IIS, zobacz Hostowanie ASP.NET Core na Windows za pomocą usług IIS .

Atrybuty elementu aspNetCore

Atrybut Opis Domyślne
arguments

Opcjonalny atrybut ciągu.

Argumenty pliku wykonywalnego określonego w processPath.

disableStartUpErrorPage

Opcjonalny atrybut logiczny.

W przypadku wartości true strona 502.5 — niepowodzenie procesu jest pomijana, a pierwszeństwo ma strona kodowa stanu 502 skonfigurowana wweb.configawarii.

false
forwardWindowsAuthToken

Opcjonalny atrybut logiczny.

W przypadku wartości true token jest przesyłany dalej do procesu podrzędnego, który nasłuchuje w %ASPNETCORE_PORT% jako nagłówek "MS-ASPNETCORE-WINAUTHTOKEN" na żądanie. Ten proces odpowiada za wywołanie closehandle dla tego tokenu dla każdego żądania.

true
processesPerApplication

Opcjonalny atrybut liczby całkowitej.

Określa liczbę wystąpień procesu określoną w ustawieniu processPath, które można skonfigurować dla określonej aplikacji.

Ustawienie processesPerApplication nie jest zalecane. 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łuchujący żądań HTTP. Obsługiwane są ścieżki względne. Jeśli ścieżka rozpoczyna się od , ścieżka jest uważana za . względną względem katalogu głównego lokacji.

rapidFailsPerMinute

Opcjonalny atrybut liczby całkowitej.

Określa, ile razy proces określony w processPath może ulegać awarii na minutę. Jeśli ten limit zostanie przekroczony, moduł przestanie uruchamiać proces przez pozostałą część minuty.

Domyślny: 10
Min: 0
Max: 100
requestTimeout

Opcjonalny atrybut czasu.

Określa czas, przez który moduł ASP.NET Core oczekuje na odpowiedź z procesu nasłuchujący %ASPNETCORE_PORT%.

W wersjach modułu ASP.NET Core, który został dostarczony w wersji ASP.NET Core 2.1 lub nowszej, wartość jest określana w requestTimeout 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), przez który moduł czeka, aż plik wykonywalny zostanie bezpiecznie zamknięty po wykryciuapp_offline.htm pliku wykonywalnego.

Domyślny: 10
Min: 0
Max: 600
startupTimeLimit

Opcjonalny atrybut liczby całkowitej.

Czas trwania (w sekundach), przez który moduł czeka, aż plik wykonywalny rozpocznie proces nasłuchujący na porcie. Jeśli ten limit czasu zostanie przekroczony, moduł zakańczy proces. Moduł próbuje ponownie uruchomić proces po otrzymaniu nowego żądania i kontynuuje próbę ponownego uruchomienia procesu dla kolejnych żądań przychodzących, chyba że aplikacja nie uruchomi liczby razy rapidFailsPerMinute w ostatniej kroczącej minucie.

Wartość 0 (zero) nie jest uznawana 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ą przekierowywany do pliku określonego w stdoutLogFile.

false
stdoutLogFile

Opcjonalny atrybut ciągu.

Określa względną lub bezwzględną ścieżkę pliku, dla którego są rejestrowane stdout i stderr z procesu określonego w ścieżce processPath. Ścieżki względne są względne względem katalogu głównego lokacji. Wszystkie ścieżki rozpoczynające się od są względne względem katalogu głównego lokacji, a wszystkie . inne ścieżki są traktowane jako ścieżki bezwzględne. Wszystkie foldery podane w ścieżce muszą istnieć, aby moduł tworzył plik dziennika. Przy użyciu ograniczników podkreślenia znacznik czasu, identyfikator procesu i rozszerzenie pliku (log) są dodawane do ostatniego segmentu ścieżki stdoutLogFile. Jeśli zostanie podany jako wartość, przykładowy dziennik stdout jest zapisywany jako plik stdout_20180205194132_1934.log w folderze logs po zapisaniu w dniu .\logs\stdout 5.02.2018 o godzinie 19:41:32 o identyfikatorze procesu 1934.

aspnetcore-stdout

Ustawianie zmiennych środowiskowych

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

Ostrzeżenie

Zmienne środowiskowe ustawione w tej sekcji są w konflikcie z systemową zmienną środowiskową ustawioną na taką samą nazwę. Jeśli zmienna środowiskowa zostanie ustawiona zarówno w pliku web.config, jak i na poziomie systemu w programie Windows, wartość z pliku web.config zostanie dołączona do wartości systemowej zmiennej środowiskowej (na przykład ), co uniemożliwia uruchomienie ASPNETCORE_ENVIRONMENT: Development;Development aplikacji.

W poniższym przykładzie ustawiane są 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ą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, tworząc ścieżkę do ł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

Zmienną środowiskową należy ustawić tylko na serwerach przejściowych i testowych, które nie są dostępne dla niezaufanych sieci, takich ASPNETCORE_ENVIRONMENT Development jak Internet.

app_offline.htm

Jeśli plik o nazwie app_offline.htm zostanie wykryty w katalogu głównym aplikacji, moduł ASP.NET Core spróbuje bezpiecznie zamknąć aplikację i zatrzymać przetwarzanie przychodzących żądań. Jeśli aplikacja jest nadal uruchomiona po upływie liczby sekund zdefiniowanej w , moduł shutdownTimeLimit ASP.NET Core moduł kills the running process (Moduł aplikacji ASP.NET Core, który uśmierca uruchomiony proces.

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

Strona błędu uruchamiania

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

Tworzenie i przekierowywanie dzienników

Moduł ASP.NET Core przekierowuje dane wyjściowe konsoli stdout i stderr na dysk, jeśli ustawiono atrybuty stdoutLogEnabled stdoutLogFile i elementu aspNetCore . Wszystkie foldery w stdoutLogFile ścieżce 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 funkcji w celu IIS AppPool\<app_pool_name> zapewnienia uprawnień do zapisu).

Dzienniki nie są obracane, chyba że nastąpi ponowne uruchomienie/ponowne uruchomienie procesu. To hoster odpowiada za 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 usług IIS w czasie projektowania z programem Visual Studio, anie podczas lokalnego debugowania i uruchamiania aplikacji za pomocą programu IIS Express.

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

Znacznik czasu i rozszerzenie pliku są dodawane automatycznie podczas tworzenia pliku dziennika. Nazwa pliku dziennika składa się z dołączania znacznika czasu, identyfikatora procesu i rozszerzenia pliku (log) do ostatniego segmentu ścieżki stdoutLogFile (zwykle stdout) rozdzielonych znakami podkreślenia. Jeśli ścieżka kończy się na stdout , dziennik aplikacji z identyfikatorem stdoutLogFile PID 1934 utworzonym 5.02.2018 o godzinie 19:42:32 ma nazwę pliku stdout_20180205194132_1934.log.

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

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

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

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

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

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 istnieje ryzyko podsłuchiwać ruchu między modułem i z Kestrel lokalizacji poza serwerem.

Token parowania służy do zagwarantowania, że żądania odebrane przez usługę IIS zostały sytuowane i nie pochodzą Kestrel z innego źródła. Token parowania jest tworzony i ustawiany w zmiennej środowiskowej ( ASPNETCORE_TOKEN ) przez moduł. Token parowania jest również ustawiany na nagłówek ( MS-ASPNETCORE-TOKEN ) dla każdego żądania proxy. Oprogramowanie pośredniczące usług IIS sprawdza każde odbierane żądanie, aby potwierdzić, że wartość nagłówka tokenu parowania jest taka sama jak wartość 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 nie są dostępne z lokalizacji Kestrel poza serwerem. Bez znajomości wartości tokenu parowania osoba atakująca nie może przesłać żądań pomijających sprawdzanie oprogramowania pośredniczącego usług IIS.

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

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

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

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

Dzienniki instalatora wersji modułu i pakietu hostingu

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

  1. W systemie hostingu przejdź do folderu %windir%\System32\inetsrv.
  2. Znajdź plikaspnetcore.dll.
  3. Kliknij prawym przyciskiem myszy plik i wybierz polecenie Właściwości z menu kontekstowego.
  4. Wybierz kartę Szczegóły. Wersje File (Plik) i Product (Produkt) reprezentują zainstalowaną wersję modułu.

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

Lokalizacje modułów, schematów i plików 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

Konfiguracja

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 pozycję aspnetcore wapplicationHost.config pliku.

Dodatkowe zasoby