Avancerad konfiguration av ASP.NET Core-modulen och IIS
Obs
Det här är inte den senaste versionen av den här artikeln. Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.
Varning
Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i .NET och .NET Core Support Policy. För den aktuella versionen, se .NET 9-versionen av den här artikeln.
Viktig
Den här informationen gäller en förhandsversionsprodukt som kan ändras avsevärt innan den släpps kommersiellt. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls här.
Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.
Den här artikeln beskriver avancerade konfigurationsalternativ och scenarier för ASP.NET Core Module och IIS.
Ändra stackstorleken
gäller endast när du använder värdmodellen med in-process.
Konfigurera storleken på den hanterade stacken med hjälp av inställningen stackSize
i byte, angivet i hexadecimalt format, i web.config
-filen. Standardstorleken är 1 048 576 byte (1 MB) uttryckt i hexadecimalt. I följande exempel ändras stackstorleken till 2 MB (2 097 152 byte) i hexadecimal 0x200000:
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="stackSize" value="200000" />
</handlerSettings>
</aspNetCore>
Konfigurera den hanterade stackstorleken med inställningen stackSize
i web.config
-filen, angiven i byte. Standardstorleken är 17 825 792 byte (17 MB). I följande exempel ändras stackstorleken till 100 000 hex, (1 MB):
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="stackSize" value="100000" />
</handlerSettings>
</aspNetCore>
Tillåt inte rotation på konfiguration
Inställningen disallowRotationOnConfigChange
är avsedd för blå/gröna scenarier där en ändring av den globala konfigurationen inte får leda till att alla webbplatser återanvänds. När den här flaggan är sann kommer endast ändringar som är relevanta för själva webbplatsen att göra att den återanvänds. En webbplats återanvänds till exempel om dess web.config ändras eller något ändras som är relevant för webbplatsens sökväg ur IIS perspektiv. Men en allmän ändring av applicationHost.config skulle inte leda till att en app återanvänds. I följande exempel anges den här inställningen till true:
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="disallowRotationOnConfigChange" value="true" />
</handlerSettings>
</aspNetCore>
Den här inställningen motsvarar API-ApplicationPoolRecycling.DisallowRotationOnConfigChange
Minska sannolikheten för 503 under återvinning av appen
Som standard är det en sekunds fördröjning mellan när IIS meddelas om en återvinning eller avstängning och när ANCM uppmanar den hanterade servern att starta avstängningen. Fördröjningen kan konfigureras via miljövariabeln ANCM_shutdownDelay
eller genom att ange inställningen för shutdownDelay
-hanteraren. Båda värdena finns i millisekunder. Fördröjningen är främst för att minska sannolikheten för en tävling där:
- IIS har inte börjat köa begäranden om att gå till den nya appen.
- ANCM börjar avvisa nya begäranden som kommer in i den gamla appen.
Den här inställningen innebär inte att inkommande begäranden fördröjs med det här beloppet. Inställningen anger att den gamla appinstansen börjar stängas av när tidsgränsen har inträffat. Långsammare datorer eller datorer med tyngre CPU-användning kan behöva justera det här värdet för att minska sannolikheten för 503.
I följande exempel anges fördröjningen till 5 sekunder:
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="shutdownDelay" value="5000" />
</handlerSettings>
</aspNetCore>
Proxykonfiguration använder HTTP-protokoll och en parkopplingstoken
Gäller endast för out-of-process-hosting.
Proxyn som skapas mellan ASP.NET Core-modulen och Kestrel använder HTTP-protokollet. Det finns ingen risk för att avlyssning av trafiken mellan modulen och Kestrel från en plats utanför servern.
En parkopplingstoken används för att garantera att de begäranden som tagits emot av Kestrel har gått igenom IIS och inte kom från någon annan källa. Parkopplingstoken skapas och anges i en miljövariabel (ASPNETCORE_TOKEN
) av modulen. Parkopplingstoken anges också i en rubrik (MS-ASPNETCORE-TOKEN
) för varje begäran via proxy. IIS Middleware kontrollerar varje begäran som den tar emot för att bekräfta att värdet för parkopplingstoken matchar miljövariabelvärdet. Om tokenvärdena är matchningsfel loggas och avvisas begäran. Miljövariabeln för parkopplingstoken och trafiken mellan modulen och Kestrel är inte tillgängliga från en plats utanför servern. Utan att känna till värdet för parkopplingstoken kan en cyberattacker inte skicka begäranden som kringgår kontrollen i IIS Middleware.
ASP.NET Core-modul med en delad IIS-konfiguration
Installationsprogrammet för ASP.NET Core Module körs med TrustedInstaller
-kontots behörigheter. Eftersom det lokala systemkontot inte har behörighet att ändra den resurssökväg som används av den delade IIS-konfigurationen genererar installationsprogrammet ett felmeddelande om nekad åtkomst när du försöker konfigurera modulinställningarna i den applicationHost.config
filen på resursen.
När du använder en delad IIS-konfiguration på samma dator som IIS-installationen kör du installationsprogrammet ASP.NET Core Hosting Bundle med parametern OPT_NO_SHARED_CONFIG_CHECK
inställd på 1
:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
Följ dessa steg när sökvägen till den delade konfigurationen inte finns på samma dator som IIS-installationen:
- Inaktivera IIS delad konfiguration.
- Kör installationsprogrammet.
- Exportera den uppdaterade
applicationHost.config
-filen till fildelningen. - Återaktivera den delade IIS-konfigurationen.
Dataskydd
ASP.NET Core Data Protection-stacken används av flera ASP.NET Core mellanprogram, inklusive mellanprogram som används i autentisering. Även om dataskydds-API:er inte anropas av användarkod bör dataskydd konfigureras med ett distributionsskript eller i användarkod för att skapa en beständig kryptografisk nyckelarkiv. Om dataskyddet inte har konfigurerats lagras nycklarna i minnet och tas bort när appen startas om.
Om dataskyddsnyckelringen lagras i minnet när appen startas om:
- Alla cookie-baserade autentiseringstoken är ogiltiga.
- Användarna måste logga in igen på nästa begäran.
- Data som skyddas med nyckelringen kan inte längre dekrypteras. Detta kan omfatta CSRF-token och ASP.NET Core MVC TempData-cookies.
Om du vill konfigurera dataskydd under IIS för att bevara nyckelringen använder du en av följande metoder:
Skapa dataskyddsregisternycklar
Dataskyddsnycklar som används av ASP.NET Core-appar lagras i registret utanför apparna. Om du vill spara nycklarna för en viss app skapar du Registernycklar för apppoolen.
För fristående IIS-installationer som inte är webfarm kan Data Protection Provision-AutoGenKeys.ps1 PowerShell-skriptet användas för varje apppool som används med en ASP.NET Core-app. Det här skriptet skapar en registernyckel i HKLM-registret som endast är tillgängligt för arbetsprocesskontot för appens apppool. Nycklar krypteras i vila med DPAPI med en datoromfattande nyckel.
I webbfarmsscenarier kan en app konfigureras för att använda en UNC-sökväg för att lagra sina dataskyddsnycklar. Som standard krypteras inte nycklarna. Kontrollera att filbehörigheterna för nätverksresursen är begränsade till det Windows-konto som appen körs under. Ett X509-certifikat kan användas för att skydda nycklar i vila. Överväg en mekanism som gör det möjligt för användare att ladda upp certifikat. Placera certifikat i användarens betrodda certifikatarkiv och se till att de är tillgängliga på alla datorer där användarens app körs. Mer information finns i Konfigurera ASP.NET Core Data Protection.
Konfigurera IIS-programpoolen för att läsa in användarprofilen
Den här inställningen finns i avsnittet Process Model under Advanced Settings för apppoolen. Ställ in för att ladda användarprofil till
True
. När värdet är inställt påTrue
lagras nycklarna i användarprofilkatalogen och skyddas med DPAPI med en nyckel som är specifik för användarkontot. Nycklar sparas i mappen%LOCALAPPDATA%/ASP.NET/DataProtection-Keys
.Apppoolens
setProfileEnvironment
-attribut måste också vara aktiverat. Standardvärdet försetProfileEnvironment
ärtrue
. I vissa scenarier (till exempel Windows OS) ärsetProfileEnvironment
inställt påfalse
. Om nycklar inte lagras i användarprofilkatalogen som förväntat:- Gå till mappen
%windir%/system32/inetsrv/config
. - Öppna filen
applicationHost.config
. - Leta upp elementet
<system.applicationHost><applicationPools><applicationPoolDefaults><processModel>
. - Bekräfta att attributet
setProfileEnvironment
inte finns, vilket standardvärdet ärtrue
, eller ange attributets värde somtrue
.
- Gå till mappen
Använd filsystemet som ett nyckelringslager
Justera appkoden för att använda filsystemet som ett nyckelringslager. Använd ett X509-certifikat för att skydda nyckelringen och se till att certifikatet är ett betrott certifikat. Om certifikatet är självsignerat placerar du certifikatet i det betrodda rotarkivet.
När du använder IIS i en webbgrupp:
- Använd en fildelning som alla datorer kan komma åt.
- Distribuera ett X509-certifikat till varje dator. Konfigurera Dataskydd i kod.
Ange en datoromfattande princip för Dataskydd
Dataskyddssystemet har begränsat stöd för att ange en standardprincip för datoromfattande för alla appar som använder Dataskydds-API:erna. Mer information finns i ASP.NET Core dataskyddsöversikt.
IIS-konfiguration
Windows Server-operativsystem
Aktivera -webbservern (IIS) serverrollen och konfigurera rolltjänster.
Använd guiden Lägg till roller och funktioner från menyn Hantera eller länken i Serverhanteraren. I steget Serverroller markerar du kryssrutan för Web Server (IIS).
Efter att Funktioner steg har slutförts, laddas Rolltjänster steg för webbserver (IIS). Välj önskade IIS-rolltjänster eller acceptera standardrolltjänsterna som tillhandahålls.
Windows-autentisering (valfritt)
Om du vill aktivera Windows-autentisering expanderar du följande noder: Web Server>Security. Välj funktionen Windows-autentisering. Mer information finns i Windows-autentisering<windowsAuthentication>
och Konfigurera Windows-autentisering.WebSockets (valfritt)
WebSockets stöds med ASP.NET Core 1.1 eller senare. Om du vill aktivera WebSockets expanderar du följande noder: Web Server>Application Development. Välj funktionen WebSocket Protocol. Mer information finns i WebSockets.Fortsätt med steget Bekräftelse för att installera webbserverrollen och -tjänsterna. En server/IIS-omstart krävs inte när du har installerat -webbservern (IIS) roll.
Windows-skrivbordsoperativsystem
Aktivera IIS-hanteringskonsolen och World Wide Web Services.
Gå till Kontrollpanelen>Program>program och funktioner>Aktivera eller inaktivera Windows-funktioner (till vänster på skärmen).
Öppna noden Internet Information Services. Öppna noden Web Management Tools.
Markera kryssrutan för IIS-hanteringskonsolen.
Markera kryssrutan för World Wide Web Services.
Acceptera standardfunktionerna för World Wide Web Services eller anpassa IIS-funktionerna.
Windows-autentisering (valfritt)
Om du vill aktivera Windows-autentisering expanderar du följande noder: World Wide Web Services>Security. Välj funktionen Windows-autentisering. Mer information finns i Windows-autentisering<windowsAuthentication>
och Konfigurera Windows-autentisering.WebSockets (valfritt)
WebSockets stöds med ASP.NET Core 1.1 eller senare. Om du vill aktivera WebSockets expanderar du följande noder: World Wide Web Services>Application Development Features. Välj funktionen WebSocket Protocol. Mer information finns i WebSockets.Om IIS-installationen kräver en omstart startar du om systemet.
Virtuella kataloger
virtuella IIS-kataloger stöds inte med ASP.NET Core-appar. En app kan hanteras som en underprogram.
Underapplikationer
En ASP.NET Core-app kan hanteras som ett IIS-underprogram (underapp). Underappens sökväg blir en del av rotappens URL.
Statiska tillgångslänkar i underappen ska använda tilde-slash (~/
) notation i MVC och Razor Pages. Tilde-slash-notation utlöser en Tag Helper- för att förbereda underappens sökvägsbas till den renderade relativa länken. För en underapp på /subapp_path
återges en bild som är länkad med src="~/image.png"
som src="/subapp_path/image.png"
. Rotappens Static File Middleware bearbetar inte den statiska filbegäran. Begäran bearbetas av underappens mellanprogram för statisk fil.
Not
Razor komponenter (.razor
) bör inte använda tilde-slash-notation. Mer information finns i dokumentationen för Blazor app-bassökväg.
Om en statisk tillgångs src
-attribut är inställt på en absolut sökväg (till exempel src="/image.png"
) återges länken utan underappens sökvägsbas. Rotappens Static File Middleware försöker hantera tillgången från rotappens webbrot, vilket resulterar i ett 404 – Hittades inte svar om inte den statiska tillgången är tillgänglig från rotappen.
För att köra en ASP.NET Core-app som en underapp till en annan ASP.NET Core-app.
Upprätta en apppool för underappen. Ange .NET CLR-version till Ingen hanterad kod eftersom Core Common Language Runtime (CoreCLR) för .NET Core startas för att vara värd för appen i arbetsprocessen, inte clr för skrivbordet (.NET CLR).
Lägg till rotwebbplatsen i IIS Manager med underappen i en mapp under rotwebbplatsen.
Högerklicka på mappen underapp i IIS Manager och välj Konvertera till program.
I dialogrutan Lägg till program använder du knappen Välj för programpool för att tilldela den apppool som du skapade för underappen. Välj OK.
Tilldelningen av en separat app-pool till underappen är ett krav vid användning av in-process-värdmodellen.
Mer information om den processbaserade värdmodellen och hur du konfigurerar ASP.NET Core-modulen finns i ASP.NET Core Module (ANCM) för IIS.
Programpooler
Apppoolisolering bestäms av värdmodellen:
- Värdtjänst under drift: Appar måste köras i separata apppooler.
- ** Värd utanför processen: Vi rekommenderar att du isolerar apparna från varandra genom att köra varje app i sin egen apppool.
Dialogrutan IIS Lägg till webbplats är standardinställningen för att tilldela en enda apppool per app. När ett webbplatsnamn anges överförs texten automatiskt till textrutan Programpool. En ny apppool skapas med webbplatsnamnet när webbplatsen läggs till.
Programpool Identity
Med ett apppoolsidentitetskonto kan en app köras under ett unikt konto utan att behöva skapa och hantera domäner eller lokala konton. I IIS 8.0 eller senare skapar IIS Admin Worker Process (WAS) ett virtuellt konto med namnet på den nya apppoolen och kör apppoolens arbetsprocesser under det här kontot som standard. I IIS-hanteringskonsolen under Avancerade inställningar för apppoolen kontrollerar du att Identity är inställd på att använda ApplicationPoolIdentity
:
dialogrutan avancerade inställningar för
IIS-hanteringsprocessen skapar en säker identifierare med namnet på apppoolen i Windows Säkerhetssystem. Resurser kan skyddas med hjälp av den här identiteten. Den här identiteten är dock inte ett riktigt användarkonto och visas inte i Windows-användarhanteringskonsolen.
Om IIS-arbetsprocessen kräver förhöjd åtkomst till appen ändrar du åtkomstkontrollistan (ACL) för katalogen som innehåller appen:
Öppna Utforskaren och navigera till katalogen.
Högerklicka på katalogen och välj Egenskaper.
Under fliken Security väljer du knappen Redigera och sedan knappen Lägg till.
Välj knappen Platser och kontrollera att systemet är valt.
Ange
IIS AppPool\{APP POOL NAME}
format, där platshållaren{APP POOL NAME}
är namnet på apppoolen i Ange objektnamnen för att välja område. Välj knappen Kontrollera namn. För DefaultAppPool, kontrollera namnen genom att användaIIS AppPool\DefaultAppPool
. När knappen Kontrollera namn är markerad visas värdetDefaultAppPool
i området objektnamn. Det går inte att ange apppoolens namn direkt i området objektnamn. AnvändIIS AppPool\{APP POOL NAME}
format, där platshållaren{APP POOL NAME}
är namnet på apppoolen, när du söker efter objektnamnet.Välj OK.
Läs & körningsbehörigheter ska beviljas som standard. Ange ytterligare behörigheter efter behov.
Åtkomst kan också beviljas i en kommandotolk med hjälp av verktyget ICACLS. Med DefaultAppPool- som exempel används följande kommando för att ge läs- och körbehörigheter åt MyWebApp
mappen, undermappar och filer:
ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"
Mer information finns i ämnet icacls.
HTTP/2-stöd
HTTP/2- stöds med ASP.NET Core i följande IIS-distributionsscenarier:
- Pågående
- Windows Server 2016/Windows 10 eller senare; IIS 10 eller senare
- TLS 1.2 eller senare anslutning
- Out-of-process
- Windows Server 2016/Windows 10 eller senare; IIS 10 eller senare
- Offentliga gränsserveranslutningar använder HTTP/2, men den omvända proxyanslutningen till Kestrel-servern använder HTTP/1.1.
- TLS 1.2 eller senare anslutning
För en pågående distribution när en HTTP/2-anslutning upprättas rapporterar HttpRequest.Protocol
HTTP/2
. För en distribution utanför processen när en HTTP/2-anslutning upprättas rapporterar HttpRequest.Protocol
HTTP/1.1
.
Mer information om in-process- och out-of-process-hostingmodeller finns i ASP.NET Core Module (ANCM) för IIS.
HTTP/2 är aktiverat som standard. Anslutningarna återgår till HTTP/1.1 om en HTTP/2-anslutning inte har upprättats. Mer information om HTTP/2-konfiguration med IIS-distributioner finns i HTTP/2 på IIS.
CORS-förfrågningar före flygningen
Det här avsnittet gäller endast för ASP.NET Core-appar som riktar sig mot .NET Framework.
För en ASP.NET Core-app som riktar sig till .NET Framework skickas inte OPTIONS-begäranden till appen som standard i IIS. Information om hur du konfigurerar appens IIS-hanterare i web.config
för att skicka OPTIONS-begäranden finns i Aktivera begäranden mellan ursprung i ASP.NET Web API 2: Så här fungerar CORS.
Programinitieringsmodul och tidsgräns för inaktivitet
När den hanteras i IIS av ASP.NET Core Module version 2:
- Programinitieringsmodul: Appens värdbaserade pågående eller kan konfigureras för att startas om automatiskt vid omstart av arbetsprocess eller serveromstart.
- tidsgräns för inaktivitet: Appens värdbaserade pågående kan konfigureras att inte överskrida tidsgränsen under perioder av inaktivitet.
Modul för programinitiering
Gäller för appar som hanteras i processen och som inte är processbaserade.
IIS-programinitiering är en IIS-funktion som skickar en HTTP-begäran till appen när apppoolen startar eller återvinns. Begäran utlöser appen att starta. Som standard skickar IIS en begäran till appens rot-URL (/
) för att initiera appen (se ytterligare resurser för mer information om konfiguration).
Bekräfta att funktionen för initiering av IIS-program är aktiverad:
I Windows 7 eller senare skrivbordssystem när du använder IIS lokalt:
- Gå till Kontrollpanelen>Program>program och funktioner>Aktivera eller inaktivera Windows-funktioner (till vänster på skärmen).
- Öppna Internet Information Services>World Wide Web Services>Programutvecklingsfunktioner.
- Markera kryssrutan för programinitiering.
På Windows Server 2008 R2 eller senare:
- Öppna guiden Lägg till roller och funktioner.
- I panelen Välj rolltjänster öppnar du noden Programutveckling.
- Markera kryssrutan för programinitiering.
Använd någon av följande metoder för att aktivera programinitieringsmodulen för platsen:
Använda IIS Manager:
- Välj programpooler i Anslutningar-panelen.
- Högerklicka på appens apppool i listan och välj Avancerade inställningar.
- Standardläget Startläge är
OnDemand
. Ange startläge tillAlwaysRunning
. Välj OK. - Öppna noden Platser i panelen Anslutningar.
- Högerklicka på appen och välj Hantera webbplats>Avancerade inställningar.
- Standardinställningen Förinläsning aktiverat är
False
. Ställ in Förladdning aktiverad tillTrue
. Välj OK.
Använd
web.config
och lägg till elementet<applicationInitialization>
meddoAppInitAfterRestart
inställt påtrue
till de<system.webServer>
elementen i appensweb.config
-fil:<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <applicationInitialization doAppInitAfterRestart="true" /> </system.webServer> </location> </configuration>
Tidsgräns för inaktivitet
gäller endast för appar som hanteras i processen.
Om du vill förhindra att appen går på tomgång anger du tidsgränsen för inaktivitet för apppoolen med IIS Manager:
- Välj programpooler på panelen Anslutningar.
- Högerklicka på appens apppool i listan och välj Avancerade inställningar.
- Standardvärdet tidsgräns för inaktivitet (minuter) är
20
minuter. Ange tidsgränsen för inaktivitet (minuter) till0
(noll). Välj OK. - Återanvända arbetsprocessen.
Om du vill förhindra att appar som finns inte överskrider tidsgränsen använder du någon av följande metoder:
- Pinga appen från en extern tjänst för att hålla den igång.
- Om appen bara är värd för bakgrundstjänster undviker du IIS-värdtjänster och använder en Windows-tjänst som värd för ASP.NET Core-appen.
Ytterligare resurser för programinitieringsmodul och inaktivitetstid.
- IIS 8.0-applikationsinitiering
-
applikationsinitiering
<applicationInitialization>
. -
Process Model Settings for an Application Pool
<processModel>
.
Plats för modul-, schema- och konfigurationsfiler
Modul
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
Konfiguration
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
Filerna kan hittas genom att söka efter aspnetcore
i filen applicationHost.config
.
Installera Web Deploy när du publicerar med Visual Studio
När du distribuerar appar till servrar med Web Deployinstallerar du den senaste versionen av Web Deploy på servern. Information om hur du installerar Web Deploy finns i IIS Downloads: Web Deploy.
Skapa IIS-webbplatsen
I värdsystemet skapar du en mapp som innehåller appens publicerade mappar och filer. I följande steg anges mappens sökväg till IIS som den fysiska sökvägen till appen. Mer information om en apps distributionskatalog och filstruktur finns i ASP.NET Core-katalogstruktur.
Öppna serverns nod i panelen Anslutningar i IIS-hanteraren. Högerklicka på mappen Webbplatser. Välj Lägg till webbplats från kontextmenyn.
Ange ett webbplatsnamn och ställ in den fysiska sökvägen till appens distributionsmapp. Ange konfigurationen Binding och skapa webbplatsen genom att välja OK:
Varning
Jokerbindningar på toppnivå (
http://*:80/
ochhttp://+:80
) bör inte användas. Jokerteckenbindningar på toppnivå kan öppna din app för säkerhetsrisker. Detta gäller både starka och svaga jokertecken. Använd explicita värdnamn i stället för jokertecken. Jokerteckenbindning för underdomäner (till exempel*.mysub.com
) har inte den här säkerhetsrisken om du kontrollerar hela den överordnade domänen (till skillnad från*.com
, som är sårbar). Mer information finns i RFC 9110: HTTP-semantik (avsnitt 7.2: Värd och :auktoritet).Under noden för servern väljer du applikationspooler.
Högerklicka på webbplatsens apppool och välj Grundläggande inställningar från snabbmenyn.
I fönstret Redigera programpool anger du .NET CLR-version till Ingen hanterad kod:
ASP.NET Core körs i en separat process och hanterar körningen. ASP.NET Core förlitar sig inte på att ladda in desktop CLR (.NET CLR). Core Common Language Runtime (CoreCLR) för .NET Core startas för att vara värd för appen i arbetsprocessen. Det är valfritt men rekommenderas att ange .NET CLR-version till Ingen hanterad kod.
För en 32-bitars (x86) fristående distribution publicerad med en 32-bitars SDK som använder den pågående värdmodellen aktiverar du programpoolen för 32-bitars. I IIS-hanteraren går du till programpooler i sidofältet Anslutningar. Välj appens programpool. I sidofältet Åtgärder väljer du Avancerade inställningar. Ställ in Aktivera 32-bitarsapplikationer till
True
.För en 64-bitars (x64) fristående distribution som använder den processbaserade värdmodellen inaktiverar du apppoolen för 32-bitarsprocesser (x86). I IIS-hanteraren går du till programpooler i sidofältet Anslutningar. Välj appens programpool. I sidofältet Åtgärder väljer du Avancerade inställningar. Ange att Aktivera 32-bitarsapplikationer till
False
.
Bekräfta att processmodellidentiteten har rätt behörigheter.
Om standardidentiteten för apppoolen (processmodell>Identity) ändras från ApplicationPoolIdentity till en annan identitet kontrollerar du att den nya identiteten har de behörigheter som krävs för att få åtkomst till appens mapp, databas och andra nödvändiga resurser. Apppoolen kräver till exempel läs- och skrivåtkomst till mappar där appen läser och skriver filer.
Windows-autentiseringskonfiguration (valfritt)
Mer information finns i Konfigurera Windows-autentisering.
Skuggkopia
Skuggkopiering av appsammansättningar till ASP.NET Core Module (ANCM) för IIS kan ge en bättre slutanvändarupplevelse än att stoppa appen genom att distribuera en offlinefil för app.
När en ASP.NET Core-app körs i Windows låses binärfilerna så att de inte kan ändras eller ersättas. Skuggkopiering gör att appsammansättningarna kan uppdateras medan appen körs genom att göra en kopia av sammansättningarna.
Skuggkopiering är inte avsedd att möjliggöra distribueringsprocesser utan driftstopp, så det är förväntat att IIS fortfarande kommer att starta om appen, och vissa förfrågningar kan få ett 503 Service Unavailable svar. Vi rekommenderar att du använder ett mönster som blågröna distributioner eller Azure-distributionsplatser för distributioner utan driftstopp. Skuggkopiering hjälper till att minimera stilleståndstiden för distributioner, men kan inte helt eliminera det.
Skuggkopiering aktiveras genom att anpassa inställningarna för ANCM-hanteraren i web.config
:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="aspNetCore"/>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
<handlerSettings>
<handlerSetting name="enableShadowCopy" value="true" />
<!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
<handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
</handlerSettings>
</aspNetCore>
</system.webServer>
</configuration>
ASP.NET Core