Configurazione avanzata del modulo core di ASP.NET e IIS

Questo articolo illustra le opzioni e gli scenari di configurazione avanzati per ASP.NET Core Module e IIS.

Modificare le dimensioni dello stack

Si applica solo quando si usa il modello di hosting in-process.

Configurare le dimensioni dello stack gestito usando l'impostazione stackSize in byte nel web.config file. Le dimensioni predefinite sono 1.048.576 byte (1 MB). L'esempio seguente modifica le dimensioni dello stack a 2 MB (2.097.152 byte):

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

Non consentire la rotazione nella configurazione

L'impostazione disallowRotationOnConfigChange è destinata agli scenari blu/verde in cui una modifica alla configurazione globale non deve causare il riciclo di tutti i siti. Quando questo flag è true, solo le modifiche rilevanti per il sito stesso causeranno il riciclo. Ad esempio, un sito viene riciclato se il relativo web.config cambia o qualcosa di rilevante per il percorso del sito dal punto di vista di IIS. Tuttavia, una modifica generale a applicationHost.config non provocherebbe il riciclo di un'app. L'esempio seguente imposta questa impostazione su true:

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

Questa impostazione corrisponde all'API ApplicationPoolRecycling.DisallowRotationOnConfigChange

Ridurre la probabilità 503 durante il riciclo dell'app

Per impostazione predefinita, si verifica un secondo ritardo tra quando IIS riceve una notifica di riciclo o arresto e quando ANCM indica al server gestito di avviare l'arresto. Il ritardo è configurabile tramite la ANCM_shutdownDelay variabile di ambiente o impostando l'impostazione del shutdownDelay gestore. Entrambi i valori sono in millisecondi. Il ritardo è principalmente quello di ridurre la probabilità di una gara in cui:

• IIS non ha avviato l'accodamento delle richieste per passare alla nuova app.
• ANCM inizia a rifiutare nuove richieste che vengono inserite nell'app precedente.

Questa impostazione non indica che le richieste in ingresso verranno posticipate da questo importo. L'impostazione indica che l'istanza precedente dell'app inizierà ad arrestarsi dopo che si verifica il timeout. I computer o i computer più lenti con un utilizzo più elevato della CPU potrebbero dover modificare questo valore per ridurre la probabilità di 503.

L'esempio seguente imposta il ritardo su 5 secondi:

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

La configurazione del proxy usa il protocollo HTTP e un token di associazione

Si applica solo all'hosting out-of-process.

Il proxy creato tra il modulo principale di ASP.NET e Kestrel usa il protocollo HTTP. Non esiste alcun rischio di intercettazione del traffico tra il modulo e Kestrel da una posizione al di fuori del server.

Un token di associazione viene usato per garantire che le richieste ricevute da Kestrel siano state inoltrate tramite proxy da IIS e non provengano da un'altra origine. Il token di associazione viene creato e impostato in una variabile di ambiente (ASPNETCORE_TOKEN) dal modulo. Il token di associazione viene impostato anche in un'intestazione (MS-ASPNETCORE-TOKEN) in tutte le richieste trasmesse tramite proxy. Il middleware di IIS controlla ogni richiesta che riceve in modo da confermare che il valore dell'intestazione del token di associazione corrisponda al valore della variabile di ambiente. Se i valori del token non corrispondono, la richiesta viene registrata e rifiutata. La variabile di ambiente del token di associazione e il traffico tra il modulo e Kestrel non sono accessibili da una posizione al di fuori del server. Senza conoscere il valore del token di associazione, un cyberattacker non può inviare richieste che ignorano il controllo nel middleware IIS.

Modulo ASP.NET Core con configurazione condivisa di IIS

Il programma di installazione di ASP.NET Core Module viene eseguito con i privilegi dell'account TrustedInstaller . Poiché l'account di sistema locale non dispone dell'autorizzazione di modifica per il percorso di condivisione usato dalla configurazione condivisa IIS, il programma di installazione genera un errore di accesso negato quando si tenta di configurare le impostazioni del modulo nel file nella applicationHost.config condivisione.

Quando si usa una configurazione condivisa di IIS nello stesso computer dell'installazione di IIS, eseguire il programma di installazione del bundle di hosting ASP.NET Core con il parametro OPT_NO_SHARED_CONFIG_CHECK impostato su 1:

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

Quando il percorso della configurazione condivisa non è nello stesso computer dell'installazione di IIS, seguire questa procedura:

1. Disabilitare la configurazione condivisa di IIS.
2. Eseguire il programma di installazione.
3. Esportare il file aggiornato applicationHost.config nella condivisione file.
4. Abilitare di nuovo la configurazione condivisa di IIS.

Protezione dei dati

Lo stack di protezione dei dati di ASP.NET Core viene usato da diversi middleware di ASP.NET Core, inclusi quelli usati nell'autenticazione. Anche se le DPAPI (Data Protection API) non vengono chiamate dal codice dell'utente, è consigliabile configurare la protezione dati per la creazione di un archivio di chiavi crittografiche permanente con uno script di distribuzione o nel codice dell'utente. Se non si configura la protezione dei dati, le chiavi vengono mantenute in memoria ed eliminate al riavvio dell'app.

Se l'anello di chiave di protezione dati viene archiviato in memoria al riavvio dell'app:

• Tutti i token di autenticazione basati su cookie vengono invalidati.
• Gli utenti devono ripetere l'accesso alla richiesta successiva.
• Tutti i dati protetti con il gruppo di chiavi non possono più essere decrittografati. Possono essere inclusi i token CSRF e i cookie TempData di ASP.NET Core MVC.

Per configurare la protezione dati in IIS in modo da rendere permanente il gruppo di chiavi, usare uno degli approcci seguenti:

• Creare chiavi del Registro di sistema di protezione dati

  Le chiavi di protezione dei dati usate dalle app ASP.NET Core vengono archiviate nel Registro di sistema esterno alle app. Per rendere persistenti le chiavi per una determinata app, creare chiavi del Registro di sistema per il pool di app.

  Per le installazioni IIS autonome non web farm è possibile usare lo script PowerShell Data Protection Provision-AutoGenKeys.ps1 (Provisioning di protezione dati-AutoGenKeys.ps1) per ogni pool di app usato con un'app ASP.NET Core. Questo script crea una chiave del Registro di sistema nel Registro di sistema HKLM accessibile solo all'account del processo di lavoro del pool di app dell'app. Le chiavi vengono crittografate rest tramite DPAPI con una chiave a livello di computer.

  Negli scenari di web farm, un'app può essere configurata per l'uso di un percorso UNC per archiviare il suo anello di chiave di protezione dati. Per impostazione predefinita, le chiavi non vengono crittografate. Assicurarsi che le autorizzazioni per i file per la condivisione di rete siano limitate all'account di Windows in cui viene eseguita l'app. È possibile usare un certificato X509 per proteggere le chiavi in rest. Prendere in considerazione un meccanismo per consentire agli utenti di caricare i certificati. Posizionare i certificati nell'archivio certificati attendibili dell'utente e assicurarsi che siano disponibili in tutti i computer in cui viene eseguita l'app dell'utente. Per altre informazioni, vedere Configurare ASP.NET Protezione dati di base.

• Configurare il pool di applicazioni IIS per caricare il profilo utente

  Questa impostazione si trova nella sezione Modello del processo in Impostazioni avanzate per il pool di app. Impostare Caricamento del profilo utente su True. Con l'impostazione True le chiavi vengono archiviate nella directory del profilo utente e protette tramite DPAPI con una chiave specifica per l'account utente. Le chiavi vengono mantenute nella %LOCALAPPDATA%/ASP.NET/DataProtection-Keys cartella .

  Anche l'attributo del pool di setProfileEnvironment app deve essere abilitato. Il valore predefinito di setProfileEnvironment è true. In alcuni scenari (ad esempio, per il sistema operativo Windows), setProfileEnvironment è impostato su false. Se le chiavi non vengono archiviate nella directory del profilo utente come previsto:

  1. Passa alla cartella %windir%/system32/inetsrv/config.
  2. Apri il file applicationHost.config.
  3. Individuare l'elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Verificare che l'attributo setProfileEnvironment non sia presente, condizione che corrisponde all'impostazione predefinita true, o impostare in modo esplicito il valore dell'attributo su true.

• Usare il file system come archivio del gruppo di chiavi

  Modificare il codice dell'app per usare il file system come archivio del gruppo di chiavi. Usare un certificato X509 per proteggere il gruppo di chiavi e verificare che sia un certificato attendibile. Se il certificato è autofirmato, inserirlo nell'archivio radice attendibile.

  Quando si usa IIS in una web farm:

  • Usare una condivisione di file a cui possono accedere tutti i computer.
  • Distribuire un certificato X509 in ogni computer. Configurare la protezione dei dati nel codice.

• Impostare criteri a livello di computer per la protezione dei dati

  Il sistema di protezione dei dati ha un supporto limitato per l'impostazione di un criterio predefinito a livello di computer per tutte le app che usano le API di protezione dei dati. Per altre informazioni, vedere Panoramica della protezione dei dati di ASP.NET Core.

Configurazione di IIS

Sistemi operativi Windows Server

Abilitare il ruolo del server Server Web (IIS) e stabilire i servizi di ruolo.

1. Usare la procedura guidata Aggiungi ruoli e funzionalità accessibile tramite il menu Gestisci o il collegamento in Server Manager. Nel passaggio Ruoli del server selezionare la casella per Server Web (IIS).

   

2. Dopo il passaggio Funzionalità, viene caricato il passaggioServizi ruolo per Server Web (IIS). Selezionare i servizi ruolo IIS desiderati o accettare i servizi ruolo predefiniti specificati.

   

   Autenticazione di Windows (facoltativa)
   Per abilitare l'autenticazione di Windows, espandere i nodi seguenti: Server Web>Sicurezza. Selezionare la funzionalità Autenticazione di Windows. Per altre informazioni, vedere Autenticazione di Windows<windowsAuthentication> e Configurare l'autenticazione di Windows.

   WebSockets (facoltativo)
   WebSockets è supportato con ASP.NET Core 1.1 o versioni successive. Per abilitare WebSockets, espandere i nodi seguenti: Server Web>Sviluppo di applicazioni. Selezionare la funzionalità Protocollo WebSocket. Per altre informazioni, vedere Oggetti WebSocket.

3. Procedere con il passaggio Conferma per installare il ruolo del server web e i servizi. Dopo l'installazione del ruolo Server Web (IIS) non è necessario riavviare il server o IIS.

Sistemi operativi desktop di Windows

Abilitare Console di gestione IIS e Servizi Web.

1. Passare a Pannello di controllo>Programmi>Programmi e funzionalità>Disattivare o attivare le funzionalità di Windows (a sinistra dello schermo).

2. Aprire il nodo Internet Information Services. Aprire il nodo Strumenti di gestione Web.

3. Selezionare la casella per Console di gestione IIS.

4. Selezionare la casella per Servizi World Wide Web.

5. Accettare le funzionalità predefinite per Servizi World Wide Web o personalizzare le funzionalità IIS.

   Autenticazione di Windows (facoltativa)
   Per abilitare l'autenticazione di Windows, espandere i nodi seguenti: Servizi Web>Sicurezza. Selezionare la funzionalità Autenticazione di Windows. Per altre informazioni, vedere Autenticazione di Windows<windowsAuthentication> e Configurare l'autenticazione di Windows.

   WebSockets (facoltativo)
   WebSockets è supportato con ASP.NET Core 1.1 o versioni successive. Per abilitare WebSockets, espandere i nodi seguenti: Servizi Web>Funzionalità per lo sviluppo di applicazioni. Selezionare la funzionalità Protocollo WebSocket. Per altre informazioni, vedere Oggetti WebSocket.

6. Se l'installazione di IIS richiede un riavvio, riavviare il sistema.

Directory virtuali

Le directory virtuali IIS non sono supportate con le app ASP.NET Core. Un'app può essere ospitata come applicazione secondaria.

Applicazioni secondarie

Un'app ASP.NET Core può essere ospitata come applicazione secondaria di IIS (app secondaria). Il percorso dell'app secondaria diventa parte dell'URL dell'app radice.

I collegamenti di asset statici all'interno dell'app secondaria devono usare la notazione tilde-slash (~/) in MVC e Razor Pages. La notazione con tilde-barra attiva un helper tag per anteporre la base del percorso dell'app secondaria al collegamento relativo sottoposto a rendering. Per un'app secondaria in /subapp_path, il rendering di un'immagine collegata con src="~/image.png" viene eseguito come src="/subapp_path/image.png". Il middleware dei file statici dell'app radice non elabora la richiesta di file statici. La richiesta viene elaborata dal middleware dei file statici dell'app secondaria.

Se l'attributo src di un asset statico viene impostato su un percorso assoluto (ad esempio, src="/image.png"), il rendering del collegamento viene eseguito senza la base del percorso dell'app secondaria. Il middleware dei file statici dell'app radice prova a servire l'asset dalla radice Web dell'app radice con conseguente risposta 404 - Non trovato, a meno che l'asset statico non sia disponibile dal'app radice.

Per ospitare un'app ASP.NET Core come app secondaria in un'altra app ASP.NET Core:

1. Definire un pool di app per l'app secondaria. Impostare Versione .NET CLR su Nessun codice gestito perché Core Common Language Runtime (CoreCLR) for .NET Core viene avviato per ospitare l'app nel processo di lavoro e non CLR desktop (.NET CLR).

2. Aggiungere il sito radice in Gestione IIS con l'applicazione secondaria in una cartella all'interno del sito principale.

3. Fare clic con il pulsante destro del mouse sulla cartella dell'applicazione secondaria in Gestione IIS e scegliere Converti in applicazione.

4. Nella finestra di dialogo Aggiungi applicazione usare il pulsante Seleziona per Pool di applicazioni per assegnare il pool di app creato per l'app secondaria. Seleziona OK.

L'assegnazione di un pool di app separato all'app secondaria è un requisito quando si usa il modello di hosting in-process.

Per altre informazioni sul modello di hosting in-process e sulla configurazione del modulo ASP.NET Core, vedere Modulo ASP.NET Core (ANCM) per IIS.

Pool di applicazioni

L'isolamento dei pool di app è determinato dal modello di hosting:

• Hosting in-process: le app devono essere eseguite in pool di app separati.
• Hosting out-of-process: è consigliabile isolare le app le une dalle altre eseguendo ogni app nel relativo pool di applicazioni.

Nella finestra di dialogo Aggiungi sito Web è selezionato per impostazione predefinita un singolo pool di app per ogni app. Quando si specifica un valore in Nome del sito, il testo viene automaticamente trasferito alla casella di testo Pool di applicazioni. Quando si aggiunge il sito viene creato un nuovo pool di applicazioni con il nome del sito.

Pool di applicazioni Identity

Un account del pool identity di app consente l'esecuzione di un'app con un account univoco senza dover creare e gestire domini o account locali. In IIS 8.0 o versioni successive il processo di lavoro amministrazione IIS (WAS) crea un account virtuale con il nome del nuovo pool di applicazioni ed esegue i processi di lavoro del pool di applicazioni inclusi nell'account per impostazione predefinita. Nella Console di gestione IIS in Impostazioni avanzate per il pool di app verificare che sia impostato per l'uso Identity ApplicationPoolIdentitydi :

Il processo di gestione IIS crea un identificatore sicuro con il nome del pool di app nel sistema di sicurezza di Windows. Le risorse possono essere protette usando questo identityoggetto . Tuttavia, questo identity non è un account utente reale e non viene visualizzato nella Console di gestione utenti di Windows.

Se il processo di lavoro IIS richiede l'accesso con privilegi elevati all'app, modificare l'elenco di controllo di accesso (ACL) della directory contenente l'app:

1. Aprire Esplora risorse, quindi spostarsi nella directory.

2. Fare clic con il pulsante destro del mouse sulla directory e scegliere Proprietà.

3. Nella scheda Sicurezza selezionare il pulsante Modifica e quindi il pulsante Aggiungi.

4. Fare clic sul pulsante Percorsi e verificare che il sistema sia selezionato.

5. Immettere IIS AppPool\{APP POOL NAME} il formato, dove il segnaposto {APP POOL NAME} è il nome del pool di app, in Immettere i nomi degli oggetti per selezionare l'area. Fare clic sul pulsante Controlla nomi. Per DefaultAppPool controllare i nomi usando IIS AppPool\DefaultAppPool. Quando il pulsante Controlla nomi è selezionato, nell'area dei nomi degli oggetti viene indicato il valore DefaultAppPool. Non è possibile immettere il nome del pool di applicazioni direttamente nell'area dei nomi degli oggetti. Usare il formato IIS AppPool\{APP POOL NAME}, dove il segnaposto {APP POOL NAME} è il nome del pool di app, durante il controllo del nome dell'oggetto.

   

6. Seleziona OK.

   

7. Le autorizzazioni di lettura e esecuzione devono essere concesse per impostazione predefinita. Fornire autorizzazioni aggiuntive in base alle necessità.

L'accesso può essere concesso anche dal prompt dei comandi usando lo strumento ICACLS. Usando DefaultAppPool come esempio, viene usato il comando seguente per concedere autorizzazioni di lettura ed esecuzione per la MyWebApp cartella, le sottocartelle e i file:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

Per altre informazioni, vedere l'argomento icacls.

Supporto HTTP/2

HTTP/2 è supportato con ASP.NET Core negli scenari di distribuzione IIS seguenti:

• In-Process
  • Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
  • Connessione TLS 1.2 o successiva
• Out-of-process
  • Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
  • Le connessioni server perimetrali pubbliche usano HTTP/2, mentre la connessione con proxy inverso al server Kestrel usa HTTP/1.1.
  • Connessione TLS 1.2 o successiva

Per una distribuzione in-process, se viene stabilita una connessione HTTP/2, HttpRequest.Protocol corrisponde a HTTP/2. Per una distribuzione out-of-process, se viene stabilita una connessione HTTP/2, HttpRequest.Protocol corrisponde a HTTP/1.1.

Per altre informazioni sui modelli di hosting in-process e out-of-process, vedere l'argomento Modulo ASP.NET Core (ANCM) per IIS.

HTTP/2 è abilitato per impostazione predefinita. Se non viene stabilita una connessione HTTP/2, la connessione esegue il fallback a HTTP/1.1. Per altre informazioni sulla configurazione di HTTP/2 con le distribuzioni IIS, vedere HTTP/2 on IIS (HTTP/2 in IIS).

Richieste preliminari CORS

Questa sezione si applica solo alle app ASP.NET Core destinate a .NET Framework.

Per un'app ASP.NET Core destinata a .NET Framework, le richieste OPTIONS non vengono passate all'app per impostazione predefinita in IIS. Per informazioni su come configurare i gestori IIS dell'app in web.config per passare le richieste OPTIONS, vedere Abilitare le richieste tra origini in API Web ASP.NET 2: Funzionamento di CORS.

Modulo di inizializzazione dell'applicazione e timeout di inattività

Per l'hosting in IIS dal modulo ASP.NET Core versione 2:

• Modulo di inizializzazione dell'applicazione: l'app ospitata in-process oppure out-of-process può essere configurata per l'avvio automatico in un riavvio del processo di lavoro o un riavvio del server.
• Timeout di inattività: l'app ospitata in-process può essere configurata per non scadere durante i periodi di inattività.

Modulo Inizializzazione applicazione

Si applica alle app ospitate in-process e out-of-process.

Inizializzazione applicazione di IIS è una funzionalità di IIS che invia una richiesta HTTP all'app quando il pool di app viene avviato o riciclato. La richiesta attiva l'avvio dell'app. Per impostazione predefinita, IIS invia una richiesta all'URL radice dell'app (/) per inizializzare l'app (vedere le risorse aggiuntive per altri dettagli sulla configurazione).

Verificare che la funzionalità del ruolo Inizializzazione applicazione di IIS sia abilitata:

Nei sistemi desktop Windows 7 o versioni successive quando si usa IIS in locale:

1. Passare a Pannello di controllo>Programmi>Programmi e funzionalità>Disattivare o attivare le funzionalità di Windows (a sinistra dello schermo).
2. Aprire Internet Information Services>Servizi Web>Funzionalità per lo sviluppo di applicazioni.
3. Selezionare la casella di controllo Inizializzazione applicazione.

In Windows Server 2008 R2 o versioni successive:

1. Aprire l'Aggiunta guidata ruoli e funzionalità.
2. Nel pannello Selezione servizi ruolo aprire il nodo Sviluppo applicazioni.
3. Selezionare la casella di controllo Inizializzazione applicazione.

Per abilitare il modulo Inizializzazione applicazione per il sito, usare uno degli approcci seguenti:

• In Gestione IIS:

  1. Selezionare Pool di applicazioni nel pannello Connessioni.
  2. Fare clic con il pulsante destro del mouse sul pool di app dell'app nell'elenco e scegliere Impostazioni avanzate.
  3. La modalità start predefinita è OnDemand. Impostare la modalità di avvio su AlwaysRunning. Seleziona OK.
  4. Aprire il nodo Siti nel pannello Connessioni.
  5. Fare clic con il pulsante destro del mouse sull'app e scegliere Gestisci sito Web>Impostazioni avanzate.
  6. L'impostazione predefinita Preload Enabled è False. Impostare Precaricamento abilitato su True. Seleziona OK.

• Usando web.config, aggiungere l'elemento <applicationInitialization> con doAppInitAfterRestart impostato su true agli <system.webServer> elementi nel file dell'app web.config :

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Timeout di inattività

Si applica solo alle app ospitate in-process.

Per evitare l'inattività dell'app, impostare il timeout di inattività del pool di app tramite Gestione IIS:

1. Selezionare Pool di applicazioni nel pannello Connessioni.
2. Fare clic con il pulsante destro del mouse sul pool di app dell'app nell'elenco e scegliere Impostazioni avanzate.
3. Il timeout di inattività predefinito (minuti) è 20 minuti. Impostare timeout di inattività (minuti) su 0 (zero). Seleziona OK.
4. Riciclare il processo di lavoro.

Per evitare il timeout delle app ospitate out-of-process, usare uno degli approcci seguenti:

• Effettuare il ping dell'app da un servizio esterno per mantenerla in esecuzione.
• Se l'app ospita solo servizi in background, evitare l'hosting IIS e usare un servizio Windows per ospitare l'app ASP.NET Core.

Risorse aggiuntive per il modulo Inizializzazione applicazione e il timeout di inattività

• IIS 8.0 Application Initialization (Inizializzazione delle applicazioni in IIS 8.0)
• Inizializzazione dell'applicazione <applicationInitialization>.
• Elaborare le impostazioni del modello per un pool <processModel>di applicazioni.

Percorsi dei file di modulo, schema e configurazione

Modulo

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

Impostazione

IIS

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

IIS Express

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

• interfaccia della riga di comando iisexpress.exe: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

I file sono disponibili cercando aspnetcore nel applicationHost.config file .

Installare la Distribuzione Web quando si pubblica con Visual Studio

Quando si distribuiscono app ai server con Distribuzione Web, installare la versione più recente di Distribuzione Web nel server. Per installare Distribuzione Web, vedere Download di IIS: Distribuzione Web.

Creare il sito IIS

1. Nel sistema host creare una cartella per contenere le cartelle e i file pubblicati dell'app. In un passaggio successivo, il percorso della cartella viene fornito a IIS come percorso fisico dell'app. Per altre informazioni sulla cartella di distribuzione e il layout dei file di un'app, vedere Struttura delle directory di ASP.NET Core.

2. In Gestione IIS aprire il nodo del server nel pannello Connessioni. Fare clic con il pulsante destro del mouse sulla cartella Siti. Scegliere Aggiungi sito Web dal menu di scelta rapida.

3. Specificare un Nome del sito e impostare il Percorso fisico per la cartella di distribuzione dell'app. Specificare la configurazione in Binding e creare il sito Web scegliendo OK:

   

   Avviso

   Le associazioni con caratteri jolly di livello superiore (http://*:80/ e http://+:80) non devono essere usate, poiché possono introdurre vulnerabilità a livello di sicurezza nell'app. Questo concetto vale sia per i caratteri jolly sicuri che vulnerabili. Usare nomi host espliciti al posto di caratteri jolly. L'associazione con caratteri jolly del sottodominio (ad esempio, *.mysub.com) non costituisce un rischio per la sicurezza se viene controllato l'intero dominio padre (a differenza di *.com, che è vulnerabile). Per altre informazioni, vedere RFC 9110: Semantica HTTP (sezione 7.2: host e :authority).

4. Nel nodo del server selezionare Pool di applicazioni.

5. Fare clic con il pulsante destro del mouse sul pool di applicazioni del sito e scegliere Impostazioni di base dal menu di scelta rapida.

6. Nella finestra Modifica pool di applicazioni impostare Versione .NET CLR su Nessun codice gestito.

   

   ASP.NET Core viene eseguito in un processo separato e gestisce il runtime. ASP.NET Core non si basa sul caricamento di Common Language Runtime (CLR di .NET) desktop. Viene avviato CoreCLR (Core Common Language Runtime) per .NET Core per ospitare l'app nel processo di lavoro. L'impostazione di Versione .NET CLR su Nessun codice gestito è facoltativa ma consigliata.

   • Per una distribuzione autonoma a 32 bit (x86) pubblicata con un SDK a 32 bit che usa il modello di hosting in-process, abilitare il pool di applicazioni per 32 bit. In Gestione IIS passare a Pool di applicazioni nella barra laterale Connessioni. Selezionare il pool di applicazioni dell'app. Nella barra laterale Azioni selezionare Impostazioni avanzate. Impostare Abilita applicazioni a 32 bit su True.

   • Per una distribuzione autonoma a 64 bit (x64) che usa il modello di hosting in-process, disabilitare il pool di app per i processi a 32 bit (x86). In Gestione IIS passare a Pool di applicazioni nella barra laterale Connessioni. Selezionare il pool di applicazioni dell'app. Nella barra laterale Azioni selezionare Impostazioni avanzate. Impostare Abilita applicazioni a 32 bit su False.

7. Verificare che il modello identity di processo disponga delle autorizzazioni appropriate.

   Se il valore predefinito identity del pool di app (modelloIdentity> di elaborazione) viene modificato da ApplicationPoolIdentity a un altro identity, verificare che il nuovo identity abbia le autorizzazioni necessarie per accedere alla cartella, al database e ad altre risorse necessarie dell'app. Ad esempio, il pool di applicazioni richiede l'accesso in lettura e scrittura alle cartelle in cui l'app legge e scrive i file.

Configurazione dell'autenticazione di Windows (facoltativa)
Per altre informazioni, vedere Configurare l'autenticazione Windows.

<?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>