Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Opmerking
Dit is niet de nieuwste versie van dit artikel. Zie de .NET 10-versie van dit artikel voor de huidige release.
Waarschuwing
Deze versie van ASP.NET Core wordt niet meer ondersteund. Zie het .NET- en .NET Core-ondersteuningsbeleid voor meer informatie. Zie de .NET 9-versie van dit artikel voor de huidige release.
De ASP.NET Core Module (ANCM) is een systeemeigen IIS-module die is aangesloten op de IIS-pijplijn, zodat ASP.NET Core-toepassingen kunnen werken met IIS. Voer ASP.NET Core-apps uit met IIS door:
- Het hosten van een ASP.NET Core-app binnen het IIS-werkproces (
w3wp.exe), het in-process hostingmodel genoemd. - Webaanvragen doorsturen naar een back-end-ASP.NET Core-app waarop de Kestrel server wordt uitgevoerd, het out-of-process hostingmodel genoemd.
Er zijn compromissen tussen elk van de hostingmodellen. Standaard wordt het in-process hostingmodel gebruikt vanwege betere prestaties en diagnostische gegevens.
Zie de volgende onderwerpen voor meer informatie en configuratierichtlijnen:
ASP.NET Core Module (ANCM) installeren
De ASP.NET Core Module (ANCM) wordt geïnstalleerd met de .NET Core Runtime van de .NET Core Hosting Bundle. De ASP.NET Core-module is voorwaarts en achterwaarts compatibel met ondersteunde releases van .NET.
Belangrijke wijzigingen en beveiligingsadviezen worden gerapporteerd in de opslagplaats Aankondigingen. Aankondigingen kunnen worden beperkt tot een specifieke versie door een labelfilter te selecteren.
Download het installatieprogramma met behulp van de volgende koppeling:
Huidig installatieprogramma voor hostingbundel van .NET Core (direct downloaden)
Zie Hosting bundle voor meer informatie, waaronder het installeren van een eerdere versie van de module.
Zie Een ASP.NET Core-app publiceren naar IIS voor een zelfstudie over het publiceren van een ASP.NET Core-app naar een IIS-server.
De ASP.NET Core Module (ANCM) is een systeemeigen IIS-module die in de IIS-pijplijn wordt aangesloten op een van de volgende:
- Host een ASP.NET Core-app in het IIS-werkproces (
w3wp.exe), het in-process hostingmodel genoemd. - Stuur webaanvragen door naar een back-end ASP.NET Core-app waarop de Kestrel server wordt uitgevoerd, het out-of-process hostingmodel genoemd.
Ondersteunde Windows-versies:
- Windows 7 of hoger
- Windows Server 2012 R2 of hoger
Bij het hosten van in-proces gebruikt de module een in-process server-implementatie voor IIS, genaamd IIS HTTP-server (IISHttpServer).
Bij het hosten buiten het proces werkt de module alleen met Kestrel. De module werkt niet met HTTP.sys.
Hostingmodellen
In-process hostingmodel
ASP.NET Core-apps zijn standaard ingesteld op het in-process hostingmodel.
De volgende kenmerken zijn van toepassing bij het hosten binnen het proces:
IIS HTTP-server (
IISHttpServer) wordt gebruikt in plaats van Kestrel server. Voor in-process roept CreateDefaultBuilder het volgende aan met UseIIS:- Registreer de
IISHttpServer. - Configureer de poort en het basispad waarop de server moet luisteren wanneer deze draait achter de ASP.NET Core-module.
- Configureer de host om opstartfouten vast te leggen.
- Registreer de
Het kenmerk requestTimeout is niet van toepassing op in-process hosting.
Het delen van een app-pool tussen apps wordt niet ondersteund. Gebruik één app-pool per app.
Wanneer u Web Deploy gebruikt of een
app_offline.htmbestand handmatig in de implementatie plaatst, wordt de app mogelijk niet onmiddellijk afgesloten als er een geopende verbinding is. Een WebSocket-verbinding kan bijvoorbeeld vertragen dat de app wordt afgesloten.De architectuur (bitness) van de app en de geïnstalleerde runtime (x64 of x86) moet overeenkomen met de architectuur van de app-pool.
De verbroken verbindingen met de client worden gedetecteerd. Het
HttpContext.RequestAbortedannuleringstoken wordt geannuleerd wanneer de client de verbinding verbreekt.In ASP.NET Core 2.2.1 of eerder retourneert GetCurrentDirectory de werkmap van het proces dat is gestart door IIS in plaats van de map van de app (bijvoorbeeld
C:\Windows\System32\inetsrvvoorw3wp.exe).Zie de klasse voor voorbeeldcode waarmee de huidige map van de
CurrentDirectoryHelpersapp wordt ingesteld. Roep deSetCurrentDirectorymethode aan. Vervolgoproepen aan GetCurrentDirectory verschaffen de directory van de app.Bij het hosten van in-process wordt AuthenticateAsync niet intern aangeroepen om een gebruiker te initialiseren. Daarom is een IClaimsTransformation implementatie die na elke verificatie wordt gebruikt om claims te transformeren, niet standaard geactiveerd. Bij het transformeren van claims met een IClaimsTransformation implementatie, aanroepen AddAuthentication om authenticatiediensten toe te voegen.
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IClaimsTransformation, ClaimsTransformer>(); services.AddAuthentication(IISServerDefaults.AuthenticationScheme); } public void Configure(IApplicationBuilder app) { app.UseAuthentication(); }- Implementaties van webpakketten (één bestand) worden niet ondersteund.
Buiten-proces hostingmodel
Als u een app wilt configureren voor out-of-process hosting, stelt u de waarde van de <AspNetCoreHostingModel> eigenschap OutOfProcess in op in het projectbestand (.csproj):
<PropertyGroup>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
In-process hosting is ingesteld met InProcess, wat de standaardwaarde is.
De waarde van <AspNetCoreHostingModel> is niet hoofdlettergevoelig, dus inprocess en outofprocess zijn geldige waarden.
Kestrel server wordt gebruikt in plaats van IIS HTTP-server (IISHttpServer).
Voor niet-verwerkte CreateDefaultBuilder aanroepen UseIISIntegration naar:
- Configureer de poort en het basispad waarop de server moet luisteren wanneer deze draait achter de ASP.NET Core-module.
- Configureer de host om opstartfouten vast te leggen.
Wijzigingen in hostingmodellen
Als de hostingModel instelling wordt gewijzigd in het web.config bestand (uitgelegd in de sectie Configuratie met web.config ), wordt het werkproces voor IIS door de module gerecycled.
Voor IIS Express recyclet de module het werkproces niet, maar activeert in plaats daarvan een correct afsluiten van het huidige IIS Express-proces. De volgende aanvraag voor de app zorgt voor een nieuw IIS Express-proces.
Procesnaam
Process.GetCurrentProcess().ProcessName rapporten w3wp/iisexpress (in-proces) of dotnet (niet verwerkt).
Veel systeemeigen modules, zoals Windows-verificatie, blijven actief. Zie IIS-modules met ASP.NET Core-module voor meer informatie over IIS-modules die actief zijn met de ASP.NET Core-module.
De ASP.NET Core-module kan ook:
- Stel omgevingsvariabelen in voor het werkproces.
- Stdout-uitvoer van logboeken naar bestandsopslag voor het oplossen van opstartproblemen.
- Windows-verificatietokens doorsturen.
De ASP.NET Core Module (ANCM) installeren en gebruiken
Zie De .NET Core Hosting Bundle installeren voor instructies over het installeren van de ASP.NET Core-module. De ASP.NET Core-module is voorwaarts en achterwaarts compatibel met ondersteunde releases van .NET.
Belangrijke wijzigingen en beveiligingsadviezen worden gerapporteerd in de opslagplaats Aankondigingen. Aankondigingen kunnen worden beperkt tot een specifieke versie door een labelfilter te selecteren.
Configuratie met web.config
De ASP.NET Core-module is geconfigureerd met de aspNetCore sectie van het system.webServer knooppunt in het web.config-bestand van de site.
Het volgende web.config bestand wordt gepubliceerd voor een frameworkafhankelijke implementatie en configureert de ASP.NET Core-module voor het afhandelen van siteaanvragen:
<?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>
De volgende web.config wordt gepubliceerd voor een zelfstandige implementatie:
<?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>
De InheritInChildApplications eigenschap is zo ingesteld false dat de instellingen die zijn opgegeven in het <location> element, niet worden overgenomen door apps die zich in een submap van de app bevinden.
Wanneer een app wordt geïmplementeerd in Azure App Service, wordt het stdoutLogFile pad ingesteld op \\?\%home%\LogFiles\stdout. Het pad slaat stdout-logboeken op in de LogFiles map, wat een locatie is die automatisch door de dienst wordt aangemaakt.
Zie Host ASP.NET Core in Windows met IIS voor meer informatie over iis-subtoepassingsconfiguratie.
Kenmerken van het aspNetCore-element
| Attribute | Description | Verstek |
|---|---|---|
arguments |
Optioneel tekenreekskenmerk. Argumenten voor het uitvoerbare bestand dat is opgegeven in processPath. |
|
disableStartUpErrorPage |
Optioneel Booleaanse kenmerk. Indien waar, wordt de pagina 502.5 - Procesfout onderdrukt en heeft de 502-statuscodepagina die is geconfigureerd in de web.config voorrang. |
false |
forwardWindowsAuthToken |
Optioneel Booleaanse kenmerk. Indien waar, wordt het token doorgestuurd naar het subproces dat op |
true |
hostingModel |
Optioneel tekenreekskenmerk. Hiermee specificeert u het hostingmodel als in-process ( |
InProcessinprocess |
processesPerApplication |
Optioneel integer-attribuut. Hiermee geeft u het aantal exemplaren op van het proces dat is opgegeven in de processPath-instelling die per app kan worden geïntensioneerd. †Voor in-process hosting is de waarde beperkt tot Instelling |
Standaardwaarde: 1Min: 1Max: 100† |
processPath |
Vereist tekenreekskenmerk. Pad naar het uitvoerbare bestand dat een proces start dat luistert naar HTTP-aanvragen. Relatieve paden worden ondersteund. Als het pad begint met |
|
rapidFailsPerMinute |
Optioneel integer-attribuut. Hiermee geeft u het aantal keren op dat het proces dat is opgegeven in processPath per minuut crasht. Als deze limiet wordt overschreden, stopt de module met het starten van het proces voor de rest van de minuut. Niet ondersteund met in-process hosting. |
Standaardwaarde: 10Min: 0Max: 100 |
requestTimeout |
Optioneel tijdspannekenmerk. Hiermee geeft u de duur op waarvoor de ASP.NET Core Module wacht op een reactie van het proces dat luistert op %ASPNETCORE_PORT%. In versies van de ASP.NET Core-module die is geleverd met de release van ASP.NET Core 2.1 of hoger, wordt de Is niet van toepassing op in-process hosting. Voor in-process hosting wacht de module totdat de app de aanvraag verwerkt. Geldige waarden voor de minuten- en secondensegementen van de tekenreeks bevinden zich in het bereik van 0-59. Gebruik van 60 in de waarde voor minuten of seconden resulteert in een 500 - Interne serverfout. |
Standaardwaarde: 00:02:00Min: 00:00:00Max: 360:00:00 |
shutdownTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht totdat het uitvoerbare bestand netjes wordt afgesloten zodra het |
Standaardwaarde: 10Min: 0Max: 600 |
startupTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht tot het uitvoerbare bestand een proces start dat op de poort luistert. Als deze tijdslimiet wordt overschreden, wordt het proces door de module uitgeschakeld. Bij het hosten in-proces: het proces wordt niet opnieuw gestart en maakt geen gebruik van de instelling rapidFailsPerMinute. Bij het hosten van een extern proces: de module probeert het proces opnieuw te starten wanneer er een nieuw verzoek wordt ontvangen en blijft proberen het proces opnieuw op te starten bij daaropvolgende binnenkomende verzoeken, tenzij de app een bepaald aantal keren niet start binnen de laatste minuut op basis van de limiet voor snelle storingen per minuut. Een waarde van 0 (nul) wordt niet beschouwd als een oneindige time-out. |
Standaardwaarde: 120Min: 0Max: 3600 |
stdoutLogEnabled |
Optioneel Booleaanse kenmerk. Indien waar, worden stdout en stderr voor het proces dat is opgegeven in processPath omgeleid naar het bestand dat is opgegeven in stdoutLogFile. |
false |
stdoutLogFile |
Optioneel tekenreekskenmerk. Hiermee geeft u het relatieve of absolute bestandspad op waarvoor stdout en stderr van het proces dat is opgegeven in processPath worden vastgelegd. Relatieve paden zijn relatief ten opzichte van de hoofdmap van de site. Elk pad dat begint met |
aspnetcore-stdout |
Omgevingsvariabelen instellen
Omgevingsvariabelen kunnen worden opgegeven voor het proces in het processPath kenmerk. Geef een omgevingsvariabele op met het <environmentVariable> onderliggende element van een <environmentVariables> verzamelingselement. Omgevingsvariabelen die in deze sectie zijn ingesteld, hebben voorrang op omgevingsvariabelen van het systeem.
In het volgende voorbeeld worden twee omgevingsvariabelen ingesteld in web.config.
ASPNETCORE_ENVIRONMENT hiermee configureert u de omgeving van de app in Development. Een ontwikkelaar kan deze waarde tijdelijk instellen in het web.config bestand om af te dwingen dat de uitzonderingspagina voor ontwikkelaars wordt geladen bij het opsporen van fouten in een app-uitzondering.
CONFIG_DIR is een voorbeeld van een door de gebruiker gedefinieerde omgevingsvariabele, waarbij de ontwikkelaar code heeft geschreven waarmee de waarde bij het opstarten wordt gelezen om een pad te vormen voor het laden van het configuratiebestand van de app.
<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>
Opmerking
Een alternatief voor het rechtstreeks instellen van de omgeving in web.config is het opnemen van de <EnvironmentName> eigenschap in het publicatieprofiel (.pubxml) of projectbestand. Met deze benadering wordt de omgeving web.config ingesteld wanneer het project wordt gepubliceerd.
<PropertyGroup>
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
Waarschuwing
Stel de ASPNETCORE_ENVIRONMENT omgevingsvariabele Development alleen in op faserings- en testservers die niet toegankelijk zijn voor niet-vertrouwde netwerken, zoals internet.
app_offline.htm
Als een bestand met de naam app_offline.htm wordt gedetecteerd in de hoofdmap van een app, probeert de ASP.NET Core Module de app probleemloos af te sluiten en te stoppen met het verwerken van binnenkomende aanvragen. Als de app nog steeds wordt uitgevoerd na het aantal seconden dat is gedefinieerd, shutdownTimeLimitwordt het actieve proces door de ASP.NET Core-module afgesloten.
Terwijl het app_offline.htm bestand aanwezig is, reageert de ASP.NET Core-module op aanvragen door de inhoud van het app_offline.htm bestand terug te sturen. Wanneer het app_offline.htm bestand wordt verwijderd, wordt de app gestart met de volgende aanvraag.
Wanneer u het out-of-process hostingmodel gebruikt, wordt de app mogelijk niet onmiddellijk afgesloten als er een open verbinding is. Een WebSocket-verbinding kan bijvoorbeeld vertragen dat de app wordt afgesloten.
Opstartfoutpagina
Zowel in-process als out-of-process hosting genereren aangepaste foutpagina's wanneer ze niet in staat zijn de app te starten.
Als de ASP.NET Core-module de in-proces- of out-of-process-aanvraaghandler niet kan vinden, verschijnt er een 500.0 - Fout bij laden van in-proces/out-of-process handler statuscodepagina.
Tijdens in-process hosting geeft een 500.30 - Start Falen statuscodepagina aan als de ASP.NET Core Module de app niet kan starten.
Voor out-of-process hosting, als de ASP.NET Core Module het back-endproces niet kan starten of als het back-endproces start maar niet luistert op de geconfigureerde poort, wordt er een 502.5 - Procesfoutstatuscode pagina weergegeven.
Als u deze pagina wilt onderdrukken en wilt terugkeren naar de standaardstatuscodepagina van IIS 5xx, gebruikt u het disableStartUpErrorPage kenmerk. Zie HTTP-fouten voor meer informatie over het configureren van aangepaste foutberichten <httpErrors>.
Log aanmaken en doorsturen
De ASP.NET Core Module leidt stdout- en stderr-console-uitvoer om naar schijf als de stdoutLogEnabled en stdoutLogFile kenmerken van het aspNetCore element zijn ingesteld. Mappen in het stdoutLogFile pad worden door de module gemaakt wanneer het logboekbestand wordt gemaakt. De app-pool moet schrijftoegang hebben tot de locatie waar de logboeken worden geschreven (gebruik IIS AppPool\<app_pool_name> dit om schrijfmachtigingen te bieden).
Logboeken worden niet geroteerd, tenzij procesrecycling/opnieuw opstarten plaatsvindt. Het is de verantwoordelijkheid van de hoster om de schijfruimte te beperken die de logboeken verbruiken.
Het gebruik van het stdout-logboek wordt alleen aanbevolen voor het oplossen van opstartproblemen bij het opstarten van apps bij het hosten op IIS of bij het gebruik van ontwikkelingstijdondersteuning voor IIS met Visual Studio, niet tijdens het lokaal opsporen van fouten en het uitvoeren van de app met IIS Express.
Gebruik het stdout-logboek niet voor algemene app-logboekregistratie. Voor routinematige logboekregistratie in een ASP.NET Core-app gebruikt u een logboekbibliotheek waarmee de bestandsgrootte van logboekbestanden wordt beperkt en logboeken worden gedraaid. Zie logboekregistratieproviders van derden voor meer informatie.
Er wordt automatisch een tijdstempel en bestandsextensie toegevoegd wanneer het logboekbestand wordt gemaakt. De naam van het logboekbestand bestaat uit het toevoegen van de tijdstempel, proces-id en bestandsextensie (.log) aan het laatste segment van het stdoutLogFile pad (meestal stdout) gescheiden door onderstrepingstekens. Als het stdoutLogFile-pad eindigt met stdout, heeft een logboek voor een app met een PID van 1934, die is gemaakt op 2/5/2018 om 19:42:32, de bestandsnaam stdout_20180205194132_1934.log.
Als stdoutLogEnabled onwaar is, worden fouten die optreden bij het opstarten van de app vastgelegd en naar het gebeurtenislogboek gestuurd tot 30 kB. Na het opstarten worden alle extra logboeken verwijderd.
Met het volgende voorbeeldelement aspNetCore configureert u stdout-logboekregistratie op het relatieve pad .\log\. Controleer of de AppPool-gebruikersidentiteit gemachtigd is om naar het opgegeven pad te schrijven.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess">
</aspNetCore>
Bij het publiceren van een app voor Azure App Service-implementatie stelt de Web SDK de stdoutLogFile waarde in op \\?\%home%\LogFiles\stdout. De %home omgevingsvariabele is vooraf gedefinieerd voor apps die worden gehost door Azure App Service.
Als u logboekregistratiefilterregels wilt maken, raadpleegt u de sectie Logboekfilterregels toepassen in de codesectie van de documentatie voor ASP.NET Core-logboekregistratie.
Zie Bestandspadindelingen op Windows-systemen voor meer informatie over padindelingen.
Uitgebreide diagnostische logboeken
De ASP.NET Core-module kan worden geconfigureerd om uitgebreide diagnostische logboeken te bieden. Voeg het <handlerSettings> element toe aan het <aspNetCore> element in web.config. De debugLevel instellen op TRACE biedt een hogere precisie van diagnostische informatie.
<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>
Mappen in het pad (logs in het voorgaande voorbeeld) worden gemaakt door de module wanneer het logboekbestand wordt gemaakt. De app-pool moet schrijftoegang hebben tot de locatie waar de logboeken worden geschreven (gebruik IIS AppPool\{APP POOL NAME}, waarbij de tijdelijke aanduiding {APP POOL NAME} de naam van de app-pool is, om schrijfmachtigingen te geven).
Waarden op foutopsporingsniveau (debugLevel) kunnen zowel het niveau als de locatie bevatten.
Niveaus (in volgorde van minst tot meest uitgebreid):
- ERROR
- WAARSCHUWING
- INFORMATIE
- SPOOR
Locaties (meerdere locaties zijn toegestaan):
- CONSOLE
- EVENTLOG
- FILE
De handler-instellingen kunnen ook worden opgegeven via omgevingsvariabelen:
-
ASPNETCORE_MODULE_DEBUG_FILE: Pad naar het logboekbestand voor foutopsporing. (Standaard:aspnetcore-debug.log) -
ASPNETCORE_MODULE_DEBUG: Instelling voor foutopsporingsniveau.
Waarschuwing
Laat logboekregistratie voor foutopsporing niet langer ingeschakeld in de implementatie dan nodig is om een probleem op te lossen. De grootte van het logboek is niet beperkt. Als u het ingeschakelde foutopsporingslogboek verlaat, kan de beschikbare schijfruimte worden uitgeput en de server of app-service vastlopen.
Zie Configuratie met web.config voor een voorbeeld van het aspNetCore element in het web.config bestand.
De grootte van de stack wijzigen
Alleen van toepassing bij gebruik van het in-process hostingmodel.
Stel de stackgrootte van de beheerde omgeving in via de stackSize-instelling in bytes in web.config. De standaardgrootte is 1048.576 bytes (1 MB).
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="stackSize" value="2097152" />
</handlerSettings>
</aspNetCore>
Proxyconfiguratie maakt gebruik van het HTTP-protocol en een koppelend token
Alleen van toepassing op out-of-process hosting.
De proxy die is gemaakt tussen de ASP.NET Core-module en Kestrel maakt gebruik van het HTTP-protocol. Er is geen risico op het afluisteren van het verkeer tussen de module en Kestrel vanaf een locatie van de server.
Een koppelend token wordt gebruikt om te garanderen dat de aanvragen die zijn ontvangen Kestrel door IIS zijn geproxied en niet afkomstig zijn van een andere bron. Het koppelende token wordt gemaakt en ingesteld in een omgevingsvariabele (ASPNETCORE_TOKEN) door de module. Het koppelende token wordt ook ingesteld in een header (MS-ASPNETCORE-TOKEN) op elke geproxiede aanvraag. IIS Middleware controleert elke aanvraag die wordt ontvangen om te bevestigen dat de waarde van de koppelingstokenheader overeenkomt met de waarde van de omgevingsvariabele. Als de tokenwaarden niet overeenkomen, wordt de aanvraag geregistreerd en geweigerd. De omgevingsvariabele voor het koppelen van tokens en het verkeer tussen de module en Kestrel zijn niet toegankelijk vanaf een locatie buiten de server. Zonder de waarde van het koppelende token te kennen, kan een cyberaanval geen aanvragen indienen die de controle in de IIS Middleware omzeilen.
ASP.NET Core-module met een gedeelde IIS-configuratie
Het ASP.NET Core Module-installatieprogramma wordt uitgevoerd met de bevoegdheden van het TrustedInstaller-account . Omdat het lokale systeemaccount geen wijzigingsmachtiging heeft voor het gedeelde pad dat wordt gebruikt door de gedeelde IIS-configuratie, genereert het installatieprogramma een foutmelding voor toegang geweigerd bij het configureren van de module-instellingen in het applicationHost.config-bestand op de gedeelde locatie.
Wanneer u een gedeelde IIS-configuratie gebruikt op dezelfde computer als de IIS-installatie, voert u het installatieprogramma ASP.NET Core Hosting Bundle uit met de OPT_NO_SHARED_CONFIG_CHECK parameter ingesteld 1op:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
Wanneer het pad naar de gedeelde configuratie zich niet op dezelfde computer bevindt als de IIS-installatie, voert u de volgende stappen uit:
- Schakel de gedeelde IIS-configuratie uit.
- Voer het installatieprogramma uit.
- Exporteer het bijgewerkte
applicationHost.configbestand naar de share. - Schakel de gedeelde IIS-configuratie opnieuw in.
Installatielogboeken van moduleversie en hostingbundel
De versie van de geïnstalleerde ASP.NET Core-module bepalen:
- Navigeer in het hostingsysteem naar
%windir%\System32\inetsrv. - Zoek het
aspnetcore.dllbestand. - Klik met de rechtermuisknop op het bestand en selecteer Eigenschappen in het contextmenu.
- Selecteer het tabblad Details . De bestandsversie en productversie vertegenwoordigen de geïnstalleerde versie van de module.
De installatielogboeken van hostingbundels voor de module vindt u op C:\Users\%UserName%\AppData\Local\Temp. Het bestand heeft de naam dd_DotNetCoreWinSvrHosting__{TIMESTAMP}_000_AspNetCoreModule_x64.log.
Locaties van module-, schema- en configuratiebestanden
Module
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
Schema
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
Configuratie
IIS
%windir%\System32\inetsrv\config\applicationHost.config
IIS Express
Visual Studio:
{APPLICATION ROOT}\.vs\config\applicationHost.configiisexpress.exe CLI:
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config
De bestanden kunnen gevonden worden door te zoeken naar aspnetcore in het applicationHost.config bestand.
De ASP.NET Core Module (ANCM) is een systeemeigen IIS-module die in de IIS-pijplijn wordt aangesloten op een van de volgende:
- Host een ASP.NET Core-app in het IIS-werkproces (
w3wp.exe), het in-process hostingmodel genoemd. - Stuur webaanvragen door naar een back-end ASP.NET Core-app waarop de Kestrel server wordt uitgevoerd, het out-of-process hostingmodel genoemd.
Ondersteunde Windows-versies:
- Windows 7 of hoger
- Windows Server 2008 R2 of hoger
Bij het hosten van in-proces gebruikt de module een in-process server-implementatie voor IIS, genaamd IIS HTTP-server (IISHttpServer).
Bij het hosten buiten het proces werkt de module alleen met Kestrel. De module werkt niet met HTTP.sys.
Hostingmodellen
In-process hostingmodel
Als u een app wilt configureren voor in-process hosting, voegt u de eigenschap <AspNetCoreHostingModel> toe aan het projectbestand van de app, met als waarde InProcess (voor out-of-process hosting stelt u OutOfProcess in).
<PropertyGroup>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
Het in-process hostingmodel wordt niet ondersteund voor ASP.NET Core-apps die gericht zijn op .NET Framework.
De waarde van <AspNetCoreHostingModel> is niet hoofdlettergevoelig, dus inprocess en outofprocess zijn geldige waarden.
Als de <AspNetCoreHostingModel> eigenschap niet aanwezig is in het bestand, is OutOfProcessde standaardwaarde .
De volgende kenmerken zijn van toepassing bij het hosten binnen het proces:
IIS HTTP-server (
IISHttpServer) wordt gebruikt in plaats van Kestrel server. Voor in-process roept CreateDefaultBuilder het volgende aan met UseIIS:- Registreer de
IISHttpServer. - Configureer de poort en het basispad waarop de server moet luisteren wanneer deze draait achter de ASP.NET Core-module.
- Configureer de host om opstartfouten vast te leggen.
- Registreer de
Het kenmerk requestTimeout is niet van toepassing op in-process hosting.
Het delen van een app-pool tussen apps wordt niet ondersteund. Gebruik één app-pool per app.
Wanneer u Web Deploy gebruikt of een app_offline.htm-bestand handmatig in de implementatie plaatst, wordt de app mogelijk niet onmiddellijk afgesloten als er een open verbinding is. Een websocket-verbinding kan bijvoorbeeld vertragen dat de app wordt afgesloten.
De architectuur (bitness) van de app en de geïnstalleerde runtime (x64 of x86) moet overeenkomen met de architectuur van de app-pool.
De verbroken verbindingen met de client worden gedetecteerd. Het annuleringstoken HttpContext.RequestAborted wordt geannuleerd wanneer de client de verbinding verbreekt.
In ASP.NET Core 2.2.1 of eerder retourneert GetCurrentDirectory u de werkmap van het proces dat is gestart door IIS in plaats van de map van de app (bijvoorbeeld C:\Windows\System32\inetsrv voor w3wp.exe).
Zie de klasse CurrentDirectoryHelpers voor voorbeeldcode waarmee de huidige map van de app wordt ingesteld. Roep de
SetCurrentDirectorymethode aan. Vervolgoproepen aan GetCurrentDirectory verschaffen de directory van de app.Bij het hosten van in-process wordt AuthenticateAsync niet intern aangeroepen om een gebruiker te initialiseren. Daarom is een IClaimsTransformation implementatie die na elke verificatie wordt gebruikt om claims te transformeren, niet standaard geactiveerd. Bij het transformeren van claims met een IClaimsTransformation implementatie, aanroepen AddAuthentication om authenticatiediensten toe te voegen.
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IClaimsTransformation, ClaimsTransformer>(); services.AddAuthentication(IISServerDefaults.AuthenticationScheme); } public void Configure(IApplicationBuilder app) { app.UseAuthentication(); }
Buiten-proces hostingmodel
Als u een app wilt configureren voor out-of-process hosting, gebruikt u een van de volgende benaderingen in het projectbestand:
- Geef de
<AspNetCoreHostingModel>eigenschap niet op. Als de<AspNetCoreHostingModel>eigenschap niet aanwezig is in het bestand, isOutOfProcessde standaardwaarde . - Stel de waarde van de
<AspNetCoreHostingModel>eigenschap in opOutOfProcess(in-process hosting is ingesteld metInProcess):
<PropertyGroup>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
De waarde is niet hoofdlettergevoelig, dus inprocess en outofprocess zijn geldige waarden.
Kestrel server wordt gebruikt in plaats van IIS HTTP-server (IISHttpServer).
Voor out-of-process roept CreateDefaultBuilderUseIISIntegration het volgende aan:
- Configureer de poort en het basispad waarop de server moet luisteren wanneer deze draait achter de ASP.NET Core-module.
- Configureer de host om opstartfouten vast te leggen.
Wijzigingen in hostingmodellen
Als de hostingModel instelling wordt gewijzigd in het web.config bestand (uitgelegd in de sectie Configuratie met web.config ), wordt het werkproces voor IIS door de module gerecycled.
Voor IIS Express recyclet de module het werkproces niet, maar activeert in plaats daarvan een correct afsluiten van het huidige IIS Express-proces. De volgende aanvraag voor de app zorgt voor een nieuw IIS Express-proces.
Procesnaam
Process.GetCurrentProcess().ProcessName rapporten w3wp/iisexpress (in-proces) of dotnet (niet verwerkt).
Veel systeemeigen modules, zoals Windows-verificatie, blijven actief. Zie IIS-modules met ASP.NET Core-module voor meer informatie over IIS-modules die actief zijn met de ASP.NET Core-module.
De ASP.NET Core-module kan ook:
- Stel omgevingsvariabelen in voor het werkproces.
- Stdout-uitvoer van logboeken naar bestandsopslag voor het oplossen van opstartproblemen.
- Windows-verificatietokens doorsturen.
De ASP.NET Core Module (ANCM) installeren en gebruiken
Zie De .NET Core Hosting Bundle installeren voor instructies over het installeren van de ASP.NET Core-module. De ASP.NET Core-module is voorwaarts en achterwaarts compatibel met ondersteunde releases van .NET.
Belangrijke wijzigingen en beveiligingsadviezen worden gerapporteerd in de opslagplaats Aankondigingen. Aankondigingen kunnen worden beperkt tot een specifieke versie door een labelfilter te selecteren.
Configuratie met web.config
De ASP.NET Core-module is geconfigureerd met de aspNetCore sectie van het system.webServer knooppunt in het web.config-bestand van de site.
Het volgende web.config-bestand wordt gepubliceerd voor een frameworkafhankelijke implementatie en configureert de ASP.NET Core-module voor het verwerken van siteaanvragen:
<?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>
De volgende web.config wordt gepubliceerd voor een zelfstandige implementatie:
<?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>
De InheritInChildApplications eigenschap is zo ingesteld false dat de instellingen die zijn opgegeven in het <locatie-element> , niet worden overgenomen door apps die zich in een submap van de app bevinden.
Wanneer een app wordt geïmplementeerd in Azure App Service, wordt het stdoutLogFile pad ingesteld op \\?\%home%\LogFiles\stdout. Het pad slaat stdout-logboeken op in de map LogFiles . Dit is een locatie die automatisch door de service wordt gemaakt.
Zie Host ASP.NET Core in Windows met IIS voor meer informatie over iis-subtoepassingsconfiguratie.
Kenmerken van het aspNetCore-element
| Attribute | Description | Verstek |
|---|---|---|
arguments |
Optioneel tekenreekskenmerk. Argumenten voor het uitvoerbare bestand dat is opgegeven in |
|
disableStartUpErrorPage |
Optioneel Booleaanse kenmerk. Indien waar, wordt de pagina 502.5 - Procesfout onderdrukt en heeft de 502-statuscodepagina die is geconfigureerd in de web.config voorrang. |
false |
forwardWindowsAuthToken |
Optioneel Booleaanse kenmerk. Indien waar, wordt het token doorgestuurd naar het child-proces dat luistert op %ASPNETCORE_PORT% als header 'MS-ASPNETCORE-WINAUTHTOKEN' per verzoek. Het is de verantwoordelijkheid van dat proces om per aanvraag CloseHandle aan te roepen op dit token. |
true |
hostingModel |
Optioneel tekenreekskenmerk. Hiermee specificeert u het hostingmodel als in-process ( |
OutOfProcessoutofprocess |
processesPerApplication |
Optioneel integer-attribuut. Hiermee specificeert u het aantal exemplaren van het proces, zoals gespecificeerd in de †Voor in-process hosting is de waarde beperkt tot Instelling |
Standaardwaarde: 1Min: 1Max: 100† |
processPath |
Vereist tekenreekskenmerk. Pad naar het uitvoerbare bestand dat een proces start dat luistert naar HTTP-aanvragen. Relatieve paden worden ondersteund. Als het pad begint met |
|
rapidFailsPerMinute |
Optioneel integer-attribuut. Hiermee geeft u het aantal keren op dat het opgegeven proces Niet ondersteund met in-process hosting. |
Standaardwaarde: 10Min: 0Max: 100 |
requestTimeout |
Optioneel tijdspannekenmerk. Hiermee geeft u de duur op waarvoor de ASP.NET Core Module wacht op een reactie van het proces dat luistert op %ASPNETCORE_PORT%. In versies van de ASP.NET Core-module die is geleverd met de release van ASP.NET Core 2.1 of hoger, wordt de Is niet van toepassing op in-process hosting. Voor in-process hosting wacht de module totdat de app de aanvraag verwerkt. Geldige waarden voor de minuten- en secondensegementen van de tekenreeks bevinden zich in het bereik van 0-59. Gebruik van 60 in de waarde voor minuten of seconden resulteert in een 500 - Interne serverfout. |
Standaardwaarde: 00:02:00Min: 00:00:00Max: 360:00:00 |
shutdownTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht totdat het uitvoerbare bestand netjes wordt afgesloten zodra het |
Standaardwaarde: 10Min: 0Max: 600 |
startupTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht tot het uitvoerbare bestand een proces start dat op de poort luistert. Als deze tijdslimiet wordt overschreden, wordt het proces door de module uitgeschakeld. Tijdens het hosten in-process: het proces wordt niet opnieuw gestart en gebruikt de instelling Bij het hosten van een out-of-process: de module probeert het proces opnieuw te starten wanneer er een nieuwe aanvraag wordt ontvangen. Het blijft proberen het proces opnieuw te starten voor volgende binnenkomende aanvragen, tenzij de app het aantal keren dat het niet is opgestart in de laatste roterende minuut Een waarde van 0 (nul) wordt niet beschouwd als een oneindige time-out. |
Standaardwaarde: 120Min: 0Max: 3600 |
stdoutLogEnabled |
Optioneel Booleaanse kenmerk. Indien waar, worden stdout en stderr voor het opgegeven proces omgeleid naar het bestand dat is opgegeven |
false |
stdoutLogFile |
Optioneel tekenreekskenmerk. Hiermee geeft u het relatieve of absolute bestandspad waarvoor |
aspnetcore-stdout |
Omgevingsvariabelen instellen
Omgevingsvariabelen kunnen worden opgegeven voor het proces in het processPath kenmerk. Geef een omgevingsvariabele op met het <environmentVariable> onderliggende element van een <environmentVariables> verzamelingselement. Omgevingsvariabelen die in deze sectie zijn ingesteld, hebben voorrang op omgevingsvariabelen van het systeem.
In het volgende voorbeeld worden twee omgevingsvariabelen ingesteld.
ASPNETCORE_ENVIRONMENT hiermee configureert u de omgeving van de app in Development. Een ontwikkelaar kan deze waarde tijdelijk instellen in het web.config bestand om af te dwingen dat de uitzonderingspagina voor ontwikkelaars wordt geladen bij het opsporen van fouten in een app-uitzondering.
CONFIG_DIR is een voorbeeld van een door de gebruiker gedefinieerde omgevingsvariabele, waarbij de ontwikkelaar code heeft geschreven waarmee de waarde bij het opstarten wordt gelezen om een pad te vormen voor het laden van het configuratiebestand van de app.
<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>
Opmerking
Een alternatief voor het rechtstreeks web.config instellen van de omgeving is het opnemen van de <EnvironmentName>-eigenschap in het publicatieprofiel (.pubxml) of projectbestand. Met deze benadering wordt de omgeving web.config ingesteld wanneer het project wordt gepubliceerd.
<PropertyGroup>
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
Waarschuwing
Stel de ASPNETCORE_ENVIRONMENT omgevingsvariabele Development alleen in op faserings- en testservers die niet toegankelijk zijn voor niet-vertrouwde netwerken, zoals internet.
app_offline.htm
Als een bestand met de naam app_offline.htm wordt gedetecteerd in de hoofdmap van een app, probeert de ASP.NET Core Module de app probleemloos af te sluiten en te stoppen met het verwerken van binnenkomende aanvragen. Als de app nog steeds wordt uitgevoerd na het aantal seconden dat is gedefinieerd, shutdownTimeLimitwordt het actieve proces door de ASP.NET Core-module afgesloten.
Terwijl het app_offline.htm bestand aanwezig is, reageert de ASP.NET Core-module op aanvragen door de inhoud van het app_offline.htm bestand terug te sturen. Wanneer het app_offline.htm bestand wordt verwijderd, wordt de app gestart met de volgende aanvraag.
Wanneer u het out-of-process hostingmodel gebruikt, wordt de app mogelijk niet onmiddellijk afgesloten als er een open verbinding is. Een websocket-verbinding kan bijvoorbeeld vertragen dat de app wordt afgesloten.
Opstartfoutpagina
Zowel in-process als out-of-process hosting genereren aangepaste foutpagina's wanneer ze niet in staat zijn de app te starten.
Als de ASP.NET Core-module de in-proces- of out-of-process-aanvraaghandler niet kan vinden, verschijnt er een 500.0 - Fout bij laden van in-proces/out-of-process handler statuscodepagina.
Tijdens in-process hosting geeft een 500.30 - Start Falen statuscodepagina aan als de ASP.NET Core Module de app niet kan starten.
Voor out-of-process hosting, als de ASP.NET Core Module het back-endproces niet kan starten of als het back-endproces start maar niet luistert op de geconfigureerde poort, wordt er een 502.5 - Procesfoutstatuscode pagina weergegeven.
Als u deze pagina wilt onderdrukken en wilt terugkeren naar de standaardstatuscodepagina van IIS 5xx, gebruikt u het disableStartUpErrorPage kenmerk. Zie HTTP-fouten <httpErrors voor meer informatie over het configureren van aangepaste foutberichten>.
Log aanmaken en doorsturen
De ASP.NET Core Module leidt stdout- en stderr-console-uitvoer om naar schijf als de stdoutLogEnabled en stdoutLogFile kenmerken van het aspNetCore element zijn ingesteld. Mappen in het stdoutLogFile pad worden door de module gemaakt wanneer het logboekbestand wordt gemaakt. De app-pool moet schrijftoegang hebben tot de locatie waar de logboeken worden geschreven (gebruik IIS AppPool\{APP POOL NAME} deze om schrijfmachtigingen te bieden, waarbij de tijdelijke aanduiding {APP POOL NAME} de naam van de app-pool is).
Logboeken worden niet geroteerd, tenzij procesrecycling/opnieuw opstarten plaatsvindt. Het is de verantwoordelijkheid van de hoster om de schijfruimte te beperken die de logboeken verbruiken.
Het gebruik van het stdout-logboek wordt alleen aanbevolen voor het oplossen van opstartproblemen bij het opstarten van apps bij het hosten op IIS of bij het gebruik van ontwikkelingstijdondersteuning voor IIS met Visual Studio, niet tijdens het lokaal opsporen van fouten en het uitvoeren van de app met IIS Express.
Gebruik het stdout-logboek niet voor algemene app-logboekregistratie. Voor routinematige logboekregistratie in een ASP.NET Core-app gebruikt u een logboekbibliotheek waarmee de bestandsgrootte van logboekbestanden wordt beperkt en logboeken worden gedraaid. Zie logboekregistratieproviders van derden voor meer informatie.
Er wordt automatisch een tijdstempel en bestandsextensie toegevoegd wanneer het logboekbestand wordt gemaakt. De naam van het logboekbestand bestaat uit het toevoegen van de tijdstempel, proces-id en bestandsextensie (.log) aan het laatste segment van het stdoutLogFile pad (meestal stdout) gescheiden door onderstrepingstekens. Als het stdoutLogFile-pad eindigt met stdout, heeft een logboek voor een app met een PID van 1934, die is gemaakt op 2/5/2018 om 19:42:32, de bestandsnaam stdout_20180205194132_1934.log.
Als stdoutLogEnabled onwaar is, worden fouten die optreden bij het opstarten van de app vastgelegd en naar het gebeurtenislogboek gestuurd tot 30 kB. Na het opstarten worden alle extra logboeken verwijderd.
Met het volgende voorbeeldelement aspNetCore configureert u stdout-logboekregistratie op het relatieve pad .\log\. Controleer of de gebruikersidentiteit van de app-pool gemachtigd is om naar het opgegeven pad te schrijven.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess">
</aspNetCore>
Bij het publiceren van een app voor Azure App Service-implementatie stelt de Web SDK de stdoutLogFile waarde in op \\?\%home%\LogFiles\stdout. De %home omgevingsvariabele is vooraf gedefinieerd voor apps die worden gehost door Azure App Service.
Zie Bestandspadindelingen op Windows-systemen voor meer informatie over padindelingen.
Uitgebreide diagnostische logboeken
De ASP.NET Core-module kan worden geconfigureerd om uitgebreide diagnostische logboeken te bieden. Voeg het <handlerSettings> element toe aan het <aspNetCore> element in web.config. De debugLevel instellen op TRACE biedt een hogere precisie van diagnostische informatie.
<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>
Mappen in het pad dat is opgegeven voor de <handlerSetting> waarde (logs in het vorige voorbeeld) worden niet automatisch door de module gemaakt en moeten vooraf bestaan in de implementatie. De app-pool moet schrijftoegang hebben tot de locatie waar de logboeken worden geschreven (gebruik IIS AppPool\{APP POOL NAME} deze om schrijfmachtigingen te bieden, waarbij de tijdelijke aanduiding {APP POOL NAME} de naam van de app-pool is).
Waarden op foutopsporingsniveau (debugLevel) kunnen zowel het niveau als de locatie bevatten.
Niveaus (in volgorde van minst tot meest uitgebreid):
- ERROR
- WAARSCHUWING
- INFORMATIE
- SPOOR
Locaties (meerdere locaties zijn toegestaan):
- CONSOLE
- EVENTLOG
- FILE
De handler-instellingen kunnen ook worden opgegeven via omgevingsvariabelen:
-
ASPNETCORE_MODULE_DEBUG_FILE: Pad naar het logboekbestand voor foutopsporing. (Standaard:aspnetcore-debug.log) -
ASPNETCORE_MODULE_DEBUG: Instelling voor foutopsporingsniveau.
Waarschuwing
Laat logboekregistratie voor foutopsporing niet langer ingeschakeld in de implementatie dan nodig is om een probleem op te lossen. De grootte van het logboek is niet beperkt. Als u het ingeschakelde foutopsporingslogboek verlaat, kan de beschikbare schijfruimte worden uitgeput en de server of app-service vastlopen.
Zie Configuratie met web.config voor een voorbeeld van het aspNetCore element in het web.config bestand.
Proxyconfiguratie maakt gebruik van het HTTP-protocol en een koppelend token
Alleen van toepassing op out-of-process hosting.
De proxy die is gemaakt tussen de ASP.NET Core-module en Kestrel maakt gebruik van het HTTP-protocol. Er is geen risico op het afluisteren van het verkeer tussen de module en Kestrel vanaf een locatie van de server.
Een koppelend token wordt gebruikt om te garanderen dat de aanvragen die zijn ontvangen Kestrel door IIS zijn geproxied en niet afkomstig zijn van een andere bron. Het koppelende token wordt gemaakt en ingesteld in een omgevingsvariabele (ASPNETCORE_TOKEN) door de module. Het koppelende token wordt ook ingesteld in een header (MS-ASPNETCORE-TOKEN) op elke geproxiede aanvraag. IIS Middleware controleert elke aanvraag die wordt ontvangen om te bevestigen dat de waarde van de koppelingstokenheader overeenkomt met de waarde van de omgevingsvariabele. Als de tokenwaarden niet overeenkomen, wordt de aanvraag geregistreerd en geweigerd. De omgevingsvariabele voor het koppelen van tokens en het verkeer tussen de module en Kestrel zijn niet toegankelijk vanaf een locatie buiten de server. Zonder de waarde van het koppelende token te kennen, kan een cyberaanval geen aanvragen indienen die de controle in de IIS Middleware omzeilen.
ASP.NET Core-module met een gedeelde IIS-configuratie
Het ASP.NET Core Module-installatieprogramma wordt uitgevoerd met de bevoegdheden van het TrustedInstaller account. Omdat het lokale systeemaccount geen wijzigingsmachtiging heeft voor het gedeelde pad dat wordt gebruikt door de gedeelde IIS-configuratie, genereert het installatieprogramma een foutmelding voor toegang geweigerd bij het configureren van de module-instellingen in het applicationHost.config-bestand op de gedeelde locatie.
Wanneer u een gedeelde IIS-configuratie gebruikt op dezelfde computer als de IIS-installatie, voert u het installatieprogramma ASP.NET Core Hosting Bundle uit met de OPT_NO_SHARED_CONFIG_CHECK parameter ingesteld 1op:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
Wanneer het pad naar de gedeelde configuratie zich niet op dezelfde computer bevindt als de IIS-installatie, voert u de volgende stappen uit:
- Schakel de gedeelde IIS-configuratie uit.
- Voer het installatieprogramma uit.
- Exporteer het bijgewerkte
applicationHost.configbestand naar de share. - Schakel de gedeelde IIS-configuratie opnieuw in.
Installatielogboeken van moduleversie en hostingbundel
De versie van de geïnstalleerde ASP.NET Core-module bepalen:
- Navigeer in het hostingsysteem naar
%windir%\System32\inetsrv. - Zoek het
aspnetcore.dllbestand. - Klik met de rechtermuisknop op het bestand en selecteer Eigenschappen in het contextmenu.
- Selecteer het tabblad Details . De bestandsversie en productversie vertegenwoordigen de geïnstalleerde versie van de module.
De installatielogboeken van hostingbundels voor de module vindt u op C:\\Users\\%UserName%\\AppData\\Local\\Temp. Het bestand heeft de naam dd_DotNetCoreWinSvrHosting__\{TIMESTAMP}_000_AspNetCoreModule_x64.log, waarbij de tijdelijke aanduiding {TIMESTAMP} de tijdstempel is.
Locaties van module-, schema- en configuratiebestanden
Module
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
Schema
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
Configuratie
IIS
%windir%\System32\inetsrv\config\applicationHost.config
IIS Express
Visual Studio:
{APPLICATION ROOT}\.vs\config\applicationHost.configiisexpress.exe CLI:
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config
De bestanden kunnen gevonden worden door te zoeken naar aspnetcore in het applicationHost.config bestand.
De ASP.NET Core Module (ANCM) is een systeemeigen IIS-module die is aangesloten op de IIS-pijplijn om webaanvragen door te sturen naar back-end-ASP.NET Core-apps.
Ondersteunde Windows-versies:
- Windows 7 of hoger
- Windows Server 2008 R2 of hoger
De module werkt alleen met Kestrel. De module is niet compatibel met HTTP.sys.
Omdat ASP.NET Core-apps worden uitgevoerd in een proces dat losstaat van het IIS-werkproces, verwerkt de module ook procesbeheer. De module start het proces voor de ASP.NET Core-app wanneer de eerste aanvraag binnenkomt en start de app opnieuw als deze vastloopt. Dit is in wezen hetzelfde gedrag als bij ASP.NET 4.x-apps die in verwerking worden uitgevoerd in IIS die worden beheerd door de Windows Process Activation Service (WAS).
In het volgende diagram ziet u de relatie tussen IIS, de ASP.NET Core Module en een app:
Aanvragen komen van internet naar de kernelmodus HTTP.sys stuurprogramma. Het stuurprogramma stuurt de aanvragen naar IIS op de geconfigureerde poort van de website, meestal 80 (HTTP) of 443 (HTTPS). De module stuurt de aanvragen door naar Kestrel een willekeurige poort voor de app, die geen poort 80 of 443 is.
De module geeft de poort op via een omgevingsvariabele bij het opstarten en de IIS Integration Middleware configureert de server om op http://localhost:{port}te luisteren. Aanvullende controles worden uitgevoerd en aanvragen die niet afkomstig zijn van de module, worden geweigerd. De module biedt geen ondersteuning voor HTTPS-doorsturen, dus aanvragen worden doorgestuurd via HTTP, zelfs niet als deze worden ontvangen door IIS via HTTPS.
Nadat Kestrel de aanvraag uit de module is opgehaald, wordt de aanvraag naar de ASP.NET Core middleware-pijplijn gepusht. De middleware-pijplijn verwerkt de aanvraag en geeft deze als een HttpContext exemplaar door aan de logica van de app. Middleware die door IIS-integratie is toegevoegd, werkt het schema, externe IP en pathbase bij voor het doorsturen van de aanvraag naar Kestrel. Het antwoord van de app wordt teruggegeven aan IIS, waardoor deze terug wordt gepusht naar de HTTP-client die de aanvraag heeft gestart.
Veel systeemeigen modules, zoals Windows-verificatie, blijven actief. Zie IIS-modules met ASP.NET Core-module voor meer informatie over IIS-modules die actief zijn met de ASP.NET Core-module.
De ASP.NET Core-module kan ook:
- Stel omgevingsvariabelen in voor het werkproces.
- Stdout-uitvoer van logboeken naar bestandsopslag voor het oplossen van opstartproblemen.
- Windows-verificatietokens doorsturen.
De ASP.NET Core Module (ANCM) installeren en gebruiken
Zie De .NET Core Hosting Bundle installeren voor instructies over het installeren van de ASP.NET Core-module.
Configuratie met web.config
De ASP.NET Core-module is geconfigureerd met de aspNetCore sectie van het system.webServer knooppunt in het web.config-bestand van de site.
Het volgende web.config-bestand wordt gepubliceerd voor een frameworkafhankelijke implementatie en configureert de ASP.NET Core-module voor het verwerken van siteaanvragen:
<?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>
De volgende web.config wordt gepubliceerd voor een zelfstandige implementatie:
<?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>
Wanneer een app wordt geïmplementeerd in Azure App Service, wordt het stdoutLogFile pad ingesteld op \\?\%home%\LogFiles\stdout. Het pad slaat stdout-logboeken op in de map LogFiles . Dit is een locatie die automatisch door de service wordt gemaakt.
Zie Host ASP.NET Core in Windows met IIS voor meer informatie over iis-subtoepassingsconfiguratie.
Kenmerken van het aspNetCore-element
| Attribute | Description | Verstek |
|---|---|---|
arguments |
Optioneel tekenreekskenmerk. Argumenten voor het uitvoerbare bestand dat is opgegeven in processPath. |
|
disableStartUpErrorPage |
Optioneel Booleaanse kenmerk. Indien waar, wordt de pagina 502.5 - Procesfout onderdrukt en heeft de 502-statuscodepagina die is geconfigureerd in de web.config voorrang. |
false |
forwardWindowsAuthToken |
Optioneel Booleaanse kenmerk. Indien waar, wordt het token doorgestuurd naar het child-proces dat luistert op %ASPNETCORE_PORT% als header 'MS-ASPNETCORE-WINAUTHTOKEN' per verzoek. Het is de verantwoordelijkheid van dat proces om per aanvraag CloseHandle aan te roepen op dit token. |
true |
processesPerApplication |
Optioneel integer-attribuut. Hiermee geeft u het aantal exemplaren op van het proces dat is opgegeven in de processPath-instelling die per app kan worden geïntensioneerd. Instelling |
Standaardwaarde: 1Min: 1Max: 100 |
processPath |
Vereist tekenreekskenmerk. Pad naar het uitvoerbare bestand dat een proces start dat luistert naar HTTP-aanvragen. Relatieve paden worden ondersteund. Als het pad begint met |
|
rapidFailsPerMinute |
Optioneel integer-attribuut. Hiermee geeft u het aantal keren op dat het proces dat is opgegeven in processPath per minuut crasht. Als deze limiet wordt overschreden, stopt de module met het starten van het proces voor de rest van de minuut. |
Standaardwaarde: 10Min: 0Max: 100 |
requestTimeout |
Optioneel tijdspannekenmerk. Hiermee geeft u de duur op waarvoor de ASP.NET Core Module wacht op een reactie van het proces dat luistert op %ASPNETCORE_PORT%. In versies van de ASP.NET Core-module die is geleverd met de release van ASP.NET Core 2.1 of hoger, wordt de |
Standaardwaarde: 00:02:00Min: 00:00:00Max: 360:00:00 |
shutdownTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht totdat het uitvoerbare bestand netjes wordt afgesloten zodra het |
Standaardwaarde: 10Min: 0Max: 600 |
startupTimeLimit |
Optioneel integer-attribuut. De duur in seconden dat de module wacht tot het uitvoerbare bestand een proces start dat op de poort luistert. Als deze tijdslimiet wordt overschreden, wordt het proces door de module uitgeschakeld. De module poogt het proces opnieuw te starten wanneer er een nieuw verzoek wordt ontvangen en blijft proberen het proces opnieuw te starten bij daaropvolgende binnenkomende verzoeken, tenzij de app in de voorgaande minuut rapidFailsPerMinute keer faalt om op te starten. Een waarde van 0 (nul) wordt niet beschouwd als een oneindige time-out. |
Standaardwaarde: 120Min: 0Max: 3600 |
stdoutLogEnabled |
Optioneel Booleaanse kenmerk. Indien waar, worden stdout en stderr voor het proces dat is opgegeven in processPath omgeleid naar het bestand dat is opgegeven in stdoutLogFile. |
false |
stdoutLogFile |
Optioneel tekenreekskenmerk. Hiermee geeft u het relatieve of absolute bestandspad op waarvoor stdout en stderr van het proces dat is opgegeven in processPath worden vastgelegd. Relatieve paden zijn relatief ten opzichte van de hoofdmap van de site. Elk pad dat begint met |
aspnetcore-stdout |
Omgevingsvariabelen instellen
Omgevingsvariabelen kunnen worden opgegeven voor het proces in het processPath kenmerk. Geef een omgevingsvariabele op met het <environmentVariable> onderliggende element van een <environmentVariables> verzamelingselement.
Waarschuwing
Omgevingsvariabelen die in deze sectie zijn ingesteld, conflicteren met systeemomgevingsvariabelen die zijn ingesteld met dezelfde naam. Als een omgevingsvariabele is ingesteld in zowel het web.config-bestand als op systeemniveau in Windows, wordt de waarde uit het web.config bestand toegevoegd aan de waarde van de systeemomgevingsvariabele (bijvoorbeeld ASPNETCORE_ENVIRONMENT: Development;Development), waardoor de app niet kan worden gestart.
In het volgende voorbeeld worden twee omgevingsvariabelen ingesteld.
ASPNETCORE_ENVIRONMENT hiermee configureert u de omgeving van de app in Development. Een ontwikkelaar kan deze waarde tijdelijk instellen in het web.config-bestand om af te dwingen dat de uitzonderingspagina voor ontwikkelaars wordt geladen bij het opsporen van fouten in een app-uitzondering.
CONFIG_DIR is een voorbeeld van een door de gebruiker gedefinieerde omgevingsvariabele, waarbij de ontwikkelaar code heeft geschreven waarmee de waarde bij het opstarten wordt gelezen om een pad te vormen voor het laden van het configuratiebestand van de app.
<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>
Waarschuwing
Stel de ASPNETCORE_ENVIRONMENT omgevingsvariabele Development alleen in op faserings- en testservers die niet toegankelijk zijn voor niet-vertrouwde netwerken, zoals internet.
app_offline.htm
Als een bestand met de naam app_offline.htm wordt gedetecteerd in de hoofdmap van een app, probeert de ASP.NET Core Module de app probleemloos af te sluiten en te stoppen met het verwerken van binnenkomende aanvragen. Als de app nog steeds wordt uitgevoerd na het aantal seconden dat is gedefinieerd, shutdownTimeLimitwordt het actieve proces door de ASP.NET Core-module afgesloten.
Terwijl het app_offline.htm bestand aanwezig is, reageert de ASP.NET Core-module op aanvragen door de inhoud van het app_offline.htm bestand terug te sturen. Wanneer het app_offline.htm bestand wordt verwijderd, wordt de app gestart met de volgende aanvraag.
Opstartfoutpagina
Als de ASP.NET Core-module het back-endproces niet kan starten of als het back-endproces wel wordt gestart maar niet kan luisteren op de geconfigureerde poort, wordt er een statuscodepagina met 502.5 - Proces Fout weergegeven. Gebruik het disableStartUpErrorPage kenmerk om deze pagina te onderdrukken en terug te keren naar de standaardstatuscodepagina van IIS 502. Zie HTTP-fouten <httpErrors voor meer informatie over het configureren van aangepaste foutberichten>.
Log aanmaken en doorsturen
De ASP.NET Core Module leidt stdout- en stderr-console-uitvoer om naar schijf als de stdoutLogEnabled en stdoutLogFile kenmerken van het aspNetCore element zijn ingesteld. Mappen in het stdoutLogFile pad worden door de module gemaakt wanneer het logboekbestand wordt gemaakt. De app-pool moet schrijftoegang hebben tot de locatie waar de logboeken worden geschreven (gebruik IIS AppPool\<app_pool_name> dit om schrijfmachtigingen te bieden).
Logboeken worden niet geroteerd, tenzij procesrecycling/opnieuw opstarten plaatsvindt. Het is de verantwoordelijkheid van de hoster om de schijfruimte te beperken die de logboeken verbruiken.
Het gebruik van het stdout-logboek wordt alleen aanbevolen voor het oplossen van opstartproblemen bij het opstarten van apps bij het hosten op IIS of bij het gebruik van ontwikkelingstijdondersteuning voor IIS met Visual Studio, niet tijdens het lokaal opsporen van fouten en het uitvoeren van de app met IIS Express.
Gebruik het stdout-logboek niet voor algemene app-logboekregistratie. Voor routinematige logboekregistratie in een ASP.NET Core-app gebruikt u een logboekbibliotheek waarmee de bestandsgrootte van logboekbestanden wordt beperkt en logboeken worden gedraaid. Zie logboekregistratieproviders van derden voor meer informatie.
Er wordt automatisch een tijdstempel en bestandsextensie toegevoegd wanneer het logboekbestand wordt gemaakt. De naam van het logboekbestand bestaat uit het toevoegen van de tijdstempel, proces-id en bestandsextensie (.log) aan het laatste segment van het stdoutLogFile pad (meestal stdout) gescheiden door onderstrepingstekens. Als het stdoutLogFile pad eindigt op stdout, heeft een logboek voor een app met een PID van 1934 die is gemaakt op 2-5-2018 om 19:42:32 de bestandsnaam stdout_20180205194132_1934.log.
Met het volgende voorbeeldelement aspNetCore configureert u stdout-logboekregistratie op het relatieve pad .\log\. Controleer of de AppPool-gebruikersidentiteit gemachtigd is om naar het opgegeven pad te schrijven.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout">
</aspNetCore>
Bij het publiceren van een app voor Azure App Service-implementatie stelt de Web SDK de stdoutLogFile waarde in op \\?\%home%\LogFiles\stdout. De %home omgevingsvariabele is vooraf gedefinieerd voor apps die worden gehost door Azure App Service.
Als u logboekregistratiefilterregels wilt maken, raadpleegt u de sectie Logboekfilterregels toepassen in de codesectie van de documentatie voor ASP.NET Core-logboekregistratie.
Zie Bestandspadindelingen op Windows-systemen voor meer informatie over padindelingen.
Proxyconfiguratie maakt gebruik van het HTTP-protocol en een koppelend token
De proxy die is gemaakt tussen de ASP.NET Core-module en Kestrel maakt gebruik van het HTTP-protocol. Er is geen risico op het afluisteren van het verkeer tussen de module en Kestrel vanaf een locatie van de server.
Een koppelend token wordt gebruikt om te garanderen dat de aanvragen die zijn ontvangen Kestrel door IIS zijn geproxied en niet afkomstig zijn van een andere bron. Het koppelende token wordt gemaakt en ingesteld in een omgevingsvariabele (ASPNETCORE_TOKEN) door de module. Het koppelende token wordt ook ingesteld in een header (MS-ASPNETCORE-TOKEN) op elke geproxiede aanvraag. IIS Middleware controleert elke aanvraag die wordt ontvangen om te bevestigen dat de waarde van de koppelingstokenheader overeenkomt met de waarde van de omgevingsvariabele. Als de tokenwaarden niet overeenkomen, wordt de aanvraag geregistreerd en geweigerd. De omgevingsvariabele voor het koppelen van tokens en het verkeer tussen de module en Kestrel zijn niet toegankelijk vanaf een locatie buiten de server. Zonder de waarde van het koppelende token te kennen, kan een cyberaanval geen aanvragen indienen die de controle in de IIS Middleware omzeilen.
ASP.NET Core-module met een gedeelde IIS-configuratie
Het ASP.NET Core Module-installatieprogramma wordt uitgevoerd met de bevoegdheden van het TrustedInstaller-account . Omdat het lokale systeemaccount geen wijzigingsmachtiging heeft voor het sharepad dat wordt gebruikt door de gedeelde IIS-configuratie, genereert het installatieprogramma een fout dat de toegang is geweigerd bij het configureren van de module-instellingen in het applicationHost.config-bestand op de share.
Als u een gedeelde IIS-configuratie gebruikt, voert u de volgende stappen uit:
- Schakel de gedeelde IIS-configuratie uit.
- Voer het installatieprogramma uit.
- Exporteer het bijgewerkte applicationHost.config-bestand naar de share.
- Schakel de gedeelde IIS-configuratie opnieuw in.
Installatielogboeken van moduleversie en hostingbundel
De versie van de geïnstalleerde ASP.NET Core-module bepalen:
- Navigeer in het hostingsysteem naar %windir%\System32\inetsrv.
- Zoek het bestandaspnetcore.dll .
- Klik met de rechtermuisknop op het bestand en selecteer Eigenschappen in het contextmenu.
- Selecteer het tabblad Details . De bestandsversie en productversie vertegenwoordigen de geïnstalleerde versie van de module.
De installatielogboeken voor hostingbundels voor de module vindt u op C:\Users\%UserName%\AppData\Local\Temp. Het bestand heeft de naam dd_DotNetCoreWinSvrHosting__<timestamp>_000_AspNetCoreModule_x64.log.
Locaties van module-, schema- en configuratiebestanden
Module
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
Schema
IIS
- %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml
IIS Express
- %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml
Configuratie
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
De bestanden zijn te vinden door te zoeken naar aspnetcore in het applicationHost.config-bestand .
Aanvullende bronnen
- Host ASP.NET Core op Windows met IIS
- ASP.NET Core-apps implementeren in Azure App Service
-
ASP.NET Core Module reference source [default branch (main)]: gebruik de vervolgkeuzelijst Branch om een specifieke release te selecteren (bijvoorbeeld
release/3.1). - IIS-modules met ASP.NET Core