Condividi tramite

Host ASP.NET Core in Windows con IIS

  • Articolo

Nota

Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Avviso

Questa versione di ASP.NET Core non è più supportata. Per altre informazioni, vedere Criteri di supporto di .NET e .NET Core. Per la versione corrente, vedere la versione .NET 8 di questo articolo.

Importante

Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Internet Information Services (IIS) è un server Web flessibile, sicuro e gestibile per l'hosting di app Web, tra cui ASP.NET Core.

Piattaforme supportate

Sono supportati i sistemi operativi seguenti:

  • Windows 7 o versione successiva
  • Windows Server 2012 R2 o versione successiva

Sono supportate le app pubblicate per la distribuzione a 32 bit (x86) o a 64 bit (x64). Distribuire un'app a 32 bit con .NET Core SDK a 32 bit (x86), a meno che l'app:

  • Non richieda lo spazio indirizzi di memoria virtuale più grande disponibile per un'app a 64 bit.
  • Non richieda le dimensioni maggiori dello stack IIS.
  • Non abbia dipendenze native a 64 bit.

Installare il modulo/bundle di hosting di ASP.NET Core

Scaricare il programma di installazione più recente usando il collegamento seguente:

Programma di installazione del bundle di hosting .NET Core corrente (download diretto)

Per altre istruzioni dettagliate su come installare il modulo ASP.NET Core o sull'installazione di versioni diverse, vedere Installare il bundle di hosting .NET Core.

Per scaricare le versioni precedenti del bundle di hosting, vedere questo problema di GitHub.

Operazioni preliminari

Per informazioni introduttive sull'hosting di un sito Web in IIS, vedere la guida introduttiva.

Per informazioni introduttive sull'hosting di un sito Web in Servizio app di Azure, vedere la guida alla distribuzione in Servizio app di Azure.

Impostazione

Per indicazioni sulla configurazione, vedere Configurazione avanzata.

Risorse di distribuzione per amministratori IIS

Riciclo sovrapposto

In generale, è consigliabile usare un modello come le distribuzioni blu-verde per distribuzioni senza tempi di inattività. Le funzionalità come il riciclo sovrapposto possono essere utili, ma non garantiscono che sia possibile eseguire una distribuzione senza tempi di inattività. Per altre informazioni, vedere questo problema in GitHub.

Certificati client facoltativi

Per informazioni sulle app che devono proteggere un subset dell'app con un certificato, vedere Certificati client facoltativi.

Risorse aggiuntive

Per un'esercitazione sulla pubblicazione di un'app ASP.NET Core in un server IIS, vedere Pubblicare un'app ASP.NET Core in IIS.

Installare il bundle di hosting .NET Core

Sistemi operativi supportati

Sono supportati i sistemi operativi seguenti:

  • Windows 7 o versione successiva
  • Windows Server 2012 R2 o versione successiva

Il server HTTP.sys (chiamato in precedenza WebListener) non funziona in una configurazione proxy inverso con IIS. Usare il server Kestrel.

Per informazioni sull'hosting in Azure, vedere Distribuire app ASP.NET Core in Servizio app di Azure.

Per indicazioni sulla risoluzione dei problemi, vedere Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core.

Piattaforme supportate

Sono supportate le app pubblicate per la distribuzione a 32 bit (x86) o a 64 bit (x64). Distribuire un'app a 32 bit con .NET Core SDK a 32 bit (x86), a meno che l'app:

  • Non richieda lo spazio indirizzi di memoria virtuale più grande disponibile per un'app a 64 bit.
  • Non richieda le dimensioni maggiori dello stack IIS.
  • Non abbia dipendenze native a 64 bit.

Le app pubblicate per 32 bit (x86) devono avere i processi a 32 bit abilitati per i pool di applicazioni IIS. Per altre informazioni, vedere la sezione Creare il sito IIS.

Usare .NET Core SDK a 64 bit (x64) per pubblicare un'app a 64 bit. Un runtime a 64 bit deve essere presente nel sistema host.

Modelli di hosting

Modello di hosting in-process

Se si usa l'hosting in-process, un'app ASP.NET Core esegue lo stesso processo del processo di lavoro IIS. L'hosting in-process offre prestazioni migliori rispetto all'hosting out-of-process perché le richieste non vengono inserite in proxy sulla scheda di loopback, un'interfaccia di rete che restituisce il traffico di rete in uscita allo stesso computer. Per gestire il processo, IIS usa il servizio Attivazione processo Windows (WAS).

Il modulo ASP.NET Core:

  • Esegue l'inizializzazione dell'app.
    • Carica CoreCLR.
    • Chiama Program.Main.
  • Gestisce la durata della richiesta nativa di IIS.

Il diagramma seguente illustra la relazione tra IIS, il modulo ASP.NET Core e un'app ospitata in-process:

Modulo ASP.NET Core nello scenario di hosting in-process

  1. Una richiesta arriva dal Web al driver HTTP.sys in modalità kernel.
  2. Il driver instrada la richiesta nativa IIS sulla porta configurata per il sito Web, in genere 80 (HTTP) o 443 (HTTPS).
  3. Il modulo ASP.NET Core riceve la richiesta nativa e la trasmette al server HTTP di IIS (IISHttpServer). Il server HTTP di IIS è un'implementazione di server in-process per IIS che converte la richiesta da nativa a gestita.

Dopo l'elaborazione della richiesta dal server HTTP IIS:

  1. La richiesta viene inviata alla pipeline middleware di ASP.NET Core.
  2. La pipeline middleware gestisce la richiesta e la passa come istanza di HttpContext alla logica dell'app.
  3. La risposta dell'app viene restituita a IIS tramite il server HTTP di IIS.
  4. IIS invia la risposta al client che ha avviato la richiesta.

L'hosting in-process richiede il consenso esplicito per le app esistenti. I modelli Web ASP.NET Core usano il modello di hosting in-process.

CreateDefaultBuilder aggiunge un'istanza di IServer chiamando il metodo UseIIS per avviare CoreCLR e ospitare l'app all'interno del processo di lavoro IIS (w3wp.exe o iisexpress.exe). I test delle prestazioni indicano che l'hosting di un'app .NET Core in-process offre una velocità effettiva delle richieste significativamente superiore rispetto all'hosting dell'app out-of-process o all'inoltro delle richieste a Kestrel.

Le app pubblicate come un singolo file eseguibile non possono essere caricate dal modello di hosting in-process.

Modello di hosting out-of-process

Poiché le app ASP.NET Core vengono eseguite in un processo distinto dal processo di lavoro IIS, il modulo ASP.NET Core esegue la gestione dei processi. Il modulo avvia il processo per l'app ASP.NET Core quando arriva la prima richiesta e riavvia l'app se viene arrestata o si arresta in modo anomalo. Si tratta essenzialmente dello stesso comportamento delle app eseguite in-process e gestite dal servizio Attivazione processo Windows.

Il diagramma seguente illustra la relazione tra IIS, il modulo ASP.NET Core e un'app ospitata out-of-process:

Modulo ASP.NET Core nello scenario di hosting out-of-process

  1. Le richieste arrivano dal Web al driver HTTP.sys in modalità kernel.
  2. Il driver instrada le richieste a IIS sulla porta configurata per il sito Web. La porta configurata è in genere 80 (HTTP) o 443 (HTTPS).
  3. Il modulo inoltra le richieste a Kestrel su una porta casuale per l'app. La porta casuale non è 80 o 443.

Il modulo ASP.NET Core specifica la porta tramite una variabile di ambiente all'avvio. L'estensione UseIISIntegration configura il server per l'ascolto su http://localhost:{PORT}. Vengono eseguiti controlli aggiuntivi e le richieste che non provengono dal modulo vengono rifiutate. Il modulo non supporta l'inoltro HTTPS. Le richieste vengono inoltrate tramite HTTP anche se ricevute da IIS tramite HTTPS.

Dopo che Kestrel ha prelevato la richiesta dal modulo, la richiesta viene inoltrata alla pipeline middleware di ASP.NET Core. La pipeline middleware gestisce la richiesta e la passa come istanza di HttpContext alla logica dell'app. Il middleware aggiunto dall'integrazione di IIS aggiorna lo schema, l'IP remoto e la base del percorso per l'account per l'inoltro della richiesta a Kestrel. La risposta dell'app viene quindi passata a IIS, che la inoltra di nuovo al client HTTP che ha avviato la richiesta.

Per indicazioni sulla configurazione del modulo ASP.NET Core, vedere Modulo ASP.NET Core (ANCM) per IIS.

Per altre informazioni sull'hosting, vedere Hosting in ASP.NET Core.

Configurazione dell'applicazione

Abilitare i componenti IISIntegration

Quando si crea un host in CreateHostBuilder (Program.cs), chiamare CreateDefaultBuilder per abilitare l'integrazione IIS:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

Per altre informazioni su CreateDefaultBuilder, vedere Host generico .NET in ASP.NET Core.

Opzioni IIS

Modello di hosting in-process

Per configurare le opzioni del server IIS includere una configurazione del servizio per IISServerOptions in ConfigureServices. L'esempio seguente disabilita AutomaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
Opzione Predefiniti Impostazione
AutomaticAuthentication true Se true, IIS Server imposta l'utente HttpContext.User autenticato tramite l'autenticazione di Windows. Se false, il server fornisce solo un oggetto identity for HttpContext.User e risponde a problemi quando richiesto in modo esplicito da AuthenticationScheme. Per il funzionamento di AutomaticAuthentication l’autenticazione di Windows deve essere abilitata in IIS. Per altre informazioni, vedere Autenticazione di Windows.
AuthenticationDisplayName null Imposta il nome visualizzato dagli utenti nelle pagine di accesso.
AllowSynchronousIO false Indica se l'I/O sincrono è consentito per HttpContext.Request e HttpContext.Response.
MaxRequestBodySize 30000000 Ottiene o imposta la dimensione massima del corpo della richiesta per HttpRequest. Notare che IIS stesso include il limite maxAllowedContentLength, che verrà elaborato prima del set MaxRequestBodySize in IISServerOptions. La modifica di MaxRequestBodySize non influisce su maxAllowedContentLength. Per aumentare maxAllowedContentLength, aggiungere una voce in web.config per impostare maxAllowedContentLength su un valore superiore. Per ulteriori informazioni, vedere Configurazione.

Modello di hosting out-of-process

Per configurare le opzioni di IIS includere una configurazione del servizio per IISOptions in ConfigureServices. Nell'esempio seguente si impedisce all'app di popolare HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opzione Predefiniti Impostazione
AutomaticAuthentication true Se true, il middleware di integrazione IIS imposta HttpContext.User autenticato tramite l'autenticazione di Windows. Se false, il middleware fornisce solo un oggetto identity per HttpContext.User e risponde alle sfide quando richiesto in modo esplicito da AuthenticationScheme. Per il funzionamento di AutomaticAuthentication l’autenticazione di Windows deve essere abilitata in IIS. Per altre informazioni, vedere l'argomento Autenticazione di Windows.
AuthenticationDisplayName null Imposta il nome visualizzato dagli utenti nelle pagine di accesso.
ForwardClientCertificate true Se è true ed è presente l’intestazione della richiesta MS-ASPNETCORE-CLIENTCERT, HttpContext.Connection.ClientCertificate viene popolato.

Scenari con server proxy e servizi di bilanciamento del carico

Il middleware di integrazione IIS e il modulo ASP.NET Core sono configurati per inoltrare:

  • Lo schema (HTTP/HTTPS).
  • L'indirizzo IP remoto di origine della richiesta.

Il middleware di integrazione IIS configura il middleware delle intestazioni inoltrate.

Potrebbero essere necessari interventi di configurazione aggiuntivi per le app ospitate dietro ulteriori server proxy e servizi di bilanciamento del carico. Per altre informazioni, vedere Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico.

File web.config

Il file web.config configura il modulo ASP.NET Core. La creazione, la trasformazione e la pubblicazione del file web.config sono operazioni gestite da una destinazione MSBuild (_TransformWebConfig) quando viene pubblicato il progetto. Questa destinazione si trova tra le destinazioni Web SDK (Microsoft.NET.Sdk.Web). L'SDK è impostato all'inizio del file di progetto:

<Project Sdk="Microsoft.NET.Sdk.Web">

Se nel progetto non è presente un file web.config, il file viene creato con processPath e arguments corretti per la configurazione del modulo ASP.NET Core. Il file viene quindi spostato nell'output pubblicato.

Se nel progetto è presente un file web.config, il file viene trasformato con processPath e arguments corretti per la configurazione del modulo ASP.NET Core e spostato nell'output pubblicato. La trasformazione non modifica le impostazioni di configurazione di IIS incluse nel file.

Il file web.config può fornire ulteriori impostazioni di configurazione di IIS che controllano i moduli IIS attivi. Per informazioni sui moduli IIS in grado di elaborare le richieste con le app di ASP.NET Core, vedere l'argomento Moduli IIS.

Per impedire che Web SDK trasformi il file web.config, usare la proprietà <IsTransformWebConfigDisabled> nel file di progetto:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Quando si disabilita la trasformazione del file in Web SDK, processPath e arguments devono essere impostati manualmente dallo sviluppatore. Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

Posizione del file web.config

Per configurare correttamente il modulo ASP.NET Core, il file web.config deve essere presente nel percorso radice del contenuto (in genere il percorso base dell'app) dell'app distribuita. Corrisponde al percorso fisico del sito Web fornito a IIS. Il file web.config deve essere presente nella radice dell'app per abilitare la pubblicazione di più app mediante Distribuzione Web.

I file sensibili si trovano nel percorso fisico dell'app, ad esempio {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (commenti della documentazione XML) e {ASSEMBLY}.deps.json dove il segnaposto {ASSEMBLY} è il nome dell'assembly. Quando il file web.config è presente e il sito viene avviato normalmente, IIS non rende disponibili questi file sensibili se vengono richiesti. Se il file web.config non è presente, ha un nome non corretto o non è in grado di configurare il sito per l'avvio normale, IIS potrebbe rendere disponibili pubblicamente i file sensibili.

Il file web.config deve essere sempre presente nella distribuzione, deve essere denominato correttamente ed essere in grado di configurare il sito per l'avvio normale. Non rimuovere mai il file web.config da una distribuzione in produzione.

Trasformare web.config

Se è necessario trasformare web.config in fase di pubblicazione, vedere Trasformare web.config. Potrebbe essere necessario trasformare web.config durante la pubblicazione per impostare le variabili di ambiente in base alla configurazione, al profilo o all'ambiente.

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

    Il ruolo Server Web IIS viene selezionato nel passaggio dei ruoli del server Selezionare.

  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.

    I servizi ruolo predefiniti vengono selezionati nel passaggio Selezionare i servizi ruolo.

    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.

La console di gestione IIS e servizi World Wide Web sono selezionati nelle funzionalità di Windows.

Installare il bundle di hosting .NET Core

Installare il bundle di hosting .NET Core nel sistema di hosting. L'aggregazione installa il runtime di .NET Core, la libreria di .NET Core e il modulo ASP.NET Core. Il modulo consente l'esecuzione delle app ASP.NET Core dietro IIS.

Importante

Se il bundle di hosting viene installato prima di IIS, è necessario riparare l'installazione del bundle. Eseguire di nuovo il programma di installazione del bundle di hosting dopo l'installazione di IIS.

Se il bundle di hosting viene installato dopo l'installazione della versione a 64 bit (x64) di .NET Core, uno o più SDK potrebbero risultare mancanti (Non sono stati rilevati .NET Core SDK). Per risolvere il problema, vedere Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core.

Download diretto (versione corrente)

Scaricare il programma di installazione mediante il collegamento seguente:

Programma di installazione del bundle di hosting .NET Core corrente (download diretto)

Versioni precedenti del programma di installazione

Per ottenere una versione precedente del programma di installazione:

  1. Passare alla pagina dei download di .NET Core.
  2. Selezionare la versione di .NET Core desiderata.
  3. Nella colonna Run apps - Runtime (App di esecuzione - Runtime), trovare la riga della versione di runtime di .NET Core desiderata.
  4. Scaricare il programma di installazione tramite il collegamento Runtime & Hosting Bundle (Runtime e bundle di hosting).

Avviso

Alcuni programmi di installazione contengono versioni che hanno terminato il loro ciclo di vita e non sono più supportate da Microsoft. Per altre informazioni, vedere i criteri di supporto.

Installare il bundle di hosting

  1. Eseguire il programma di installazione nel server. Quando si esegue il programma di installazione da una shell dei comandi di amministratore sono disponibili i parametri seguenti:

    • OPT_NO_ANCM=1: ignora l'installazione del modulo ASP.NET Core.
    • OPT_NO_RUNTIME=1: ignora l'installazione del runtime .NET Core. Usato quando il server ospita solo distribuzioni autonome (SCD).
    • OPT_NO_SHAREDFX=1: ignora l'installazione del framework condiviso di ASP.NET (runtime ASP.NET). Usato quando il server ospita solo distribuzioni autonome (SCD).
    • OPT_NO_X86=1: ignora l'installazione dei runtime x86. Usare questo parametro se si è certi che non verrà eseguito l'hosting di app a 32 bit. Se non esiste alcuna possibilità che in futuro venga eseguito l'hosting di app sia a 32 che a 64 bit, non usare questo parametro e installare entrambi i runtime.
    • OPT_NO_SHARED_CONFIG_CHECK=1: disabilitare il controllo dell'uso di una configurazione condivisa di IIS quando la configurazione condivisa (applicationHost.config) è nello stesso computer dell'installazione di IIS. Disponibile solo per i programmi di installazione di bundler di hosting ASP.NET Core 2.2 o versioni successive. Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

  2. Il riavvio di IIS rileva una modifica alla variabile di ambiente di sistema PATH apportata dal programma di installazione. Per riavviare il server Web, arrestare il Servizio di attivazione dei processi di Windows (WAS) e quindi riavviare il Servizio di pubblicazione sul Web (W3SVC). Riavviare il sistema o eseguire i comandi seguenti in una shell dei comandi con privilegi elevati:

    net stop was /y
net start w3svc

ASP.NET Core non adotta il comportamento di roll forward per le versioni patch di pacchetti del framework condiviso. Dopo aver aggiornato il framework condiviso installando un nuovo bundle di hosting, riavviare il sistema o eseguire i comandi seguenti in una shell dei comandi con privilegi elevati:

net stop was /y
net start w3svc

Nota

Per informazioni sulla configurazione condivisa di IIS, vedere Modulo di ASP.NET Core con configurazione condivisa di IIS.

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, usare Il programma di installazione della piattaforma Web (WebPI) o vedere Download di IIS: Distribuzione Web. Il metodo preferito consiste nell'usare WebPI. WebPI offre un'installazione autonoma e una configurazione per i provider di hosting.

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:

    Specificare il nome del sito, il percorso fisico e il nome Host nel passaggio Aggiungi sito Web.

    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.

    Impostare Nessun codice gestito per la versione .NET CLR.

    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.

  7. ASP.NET Core 2.2 o versione successiva:

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

  8. 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.

Distribuire l'app

Distribuire l'app nella cartella Percorso fisico di IIS specificata nella sezione Creare il sito IIS. Distribuzione Web è il meccanismo consigliato per la distribuzione, ma esistono diverse opzioni per spostare l'app dalla cartella publish del progetto alla cartella di distribuzione del sistema di hosting.

Distribuzione web con Visual Studio

Vedere l'argomento Visual Studio publish profiles for ASP.NET Core app deployment (Profili di pubblicazione Visual Studio per la distribuzione di app ASP.NET Core) per informazioni su come creare un profilo di pubblicazione da usare con Distribuzione Web. Se il provider di hosting fornisce un profilo di pubblicazione o il supporto per crearne uno, scaricare il profilo e importarlo usando la finestra di dialogo Pubblica di Visual Studio:

Pagina della finestra di dialogo Pubblica

Distribuzione Web all'esterno di Visual Studio

È anche possibile usare Distribuzione Web all'esterno di Visual Studio dalla riga di comando. Per altre informazioni sulla distribuzione, vedere Strumento Distribuzione Web.

Alternative a Distribuzione web

Usare uno dei metodi disponibili, ad esempio la copia manuale, Xcopy, Robocopy o PowerShell, per spostare l'app nel sistema di hosting.

Per altre informazioni sulla distribuzione di ASP.NET Core in IIS, vedere la sezione Risorse di distribuzione per amministratori IIS.

Esplorazione del sito Web

Dopo aver distribuito l'app nel sistema di hosting, effettuare una richiesta a uno degli endpoint pubblici dell'app.

Nell'esempio seguente il sito viene associato a un nome host IIS di www.mysite.com in Porta 80. Viene effettuata una richiesta a http://www.mysite.com:

Il browser Microsoft Edge ha caricato la pagina di avvio IIS.

File di distribuzione bloccati

I file nella cartella di distribuzione sono bloccati durante l'esecuzione dell'app. I file bloccati non possono essere sovrascritti durante la distribuzione. Per rilasciare i file bloccati in una distribuzione, arrestare il pool di applicazioni usando uno dei metodi seguenti:

  • Usare Distribuzione Web e fare riferimento a Microsoft.NET.Sdk.Web nel file di progetto. Nella radice della directory dell'app Web viene posizionato un file app_offline.htm. Quando il file è presente, il modulo ASP.NET Core arresta normalmente l'app e rende disponibile il file app_offline.htm durante la distribuzione. Per altre informazioni, vedere la Guida di riferimento per la configurazione del modulo ASP.NET Core.

  • Arrestare manualmente il pool di applicazioni in Gestione IIS sul server.

  • Usare PowerShell per eliminare app_offline.htm (è richiesto PowerShell 5 o versione successiva):

    $pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

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 il gruppo di chiavi viene archiviato in memoria quando l'app viene riavviata:

  • 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 dati usate dalle app ASP.NET Core vengono archiviate nel Registro di sistema esterno alle app. Per mantenere le chiavi per una determinata app, creare chiavi del Registro di sistema per il pool di applicazioni.

    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 HKLM accessibile solo all'account del processo di lavoro del pool di applicazioni dell'app. Le chiavi vengono crittografate rest tramite DPAPI con una chiave a livello di computer.

    In scenari di web farm un'app può essere configurata in modo da usare un percorso UNC in cui archiviare il proprio gruppo di chiavi di protezione dati. Per impostazione predefinita, le chiavi di protezione dati non vengono crittografate. Assicurarsi che le autorizzazioni 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. Considerare l'implementazione di un meccanismo per consentire agli utenti di caricare i certificati: inserire 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. Vedere Configurare la protezione dati di ASP.NET Core per altri dettagli.

  • 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 salvate in modo permanente nella cartella %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

    Deve essere abilitato anche l'attributo setProfileEnvironment del pool di app. 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. Passare alla cartella %windir%/system32/inetsrv/config.
    2. Aprire 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 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 criteri a livello di computer predefiniti 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.

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 ad asset statici all'interno dell'app secondaria devono usare la notazione con tilde-barra (~/). 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.

Configurazione di IIS con web.config

La configurazione di IIS è influenzata dalla sezione <system.webServer> di web.config per gli scenari IIS funzionali per le app ASP.NET Core con il modulo ASP.NET Core. Ad esempio, la configurazione di IIS è funzionale per la compressione dinamica. Se IIS è configurato a livello di server per l'uso della compressione dinamica, l'elemento <urlCompression> nel file web.config dell'app può disabilitare questa impostazione per un'app ASP.NET Core.

Per ulteriori informazioni, vedi gli argomenti seguenti:

Per impostare variabili di ambiente per singole app in esecuzione in pool di applicazioni isolate (supportati per IIS 10.0 o versioni successive), vedere la sezione Comando AppCmd.exe dell'argomento Variabili di ambiente <environmentVariables> nella documentazione di riferimento di IIS.

Sezioni non usate da ASP.NET Core

Le sezioni di configurazione di app ASP.NET in web.config non vengono usate dalle app ASP.NET Core per la configurazione:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

Le applicazioni ASP.NET Core vengono configurate tramite altri provider di configurazione. Per altre informazioni, vedere Configurazione e Impostazioni di configurazione di runtime di .NET Core

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 Identity sia impostato per usare ApplicationPoolIdentity:

Finestra di dialogo Impostazioni avanzate del pool di applicazione

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}, dove il segnaposto {APP POOL NAME} è il nome del pool di app, nell'area Immettere i nomi degli oggetti da selezionare. 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.

    Finestra di dialogo Seleziona utenti o gruppi per la cartella dell'app: il nome del pool di applicazioni

  6. Seleziona OK.

    Finestra di dialogo Seleziona utenti o gruppi per la cartella dell'app: dopo aver selezionato

  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:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

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 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. L'impostazione predefinita per Modalità avvio è OnDemand. Impostare Modalità 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 di Precaricamento abilitato è False. Impostare Precaricamento abilitato su True. Seleziona OK.

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

    <?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. L'impostazione predefinita di Timeout di inattività (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:

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

Risorse di distribuzione per amministratori IIS

Risorse aggiuntive

Per un'esercitazione sulla pubblicazione di un'app ASP.NET Core in un server IIS, vedere Pubblicare un'app ASP.NET Core in IIS.

Installare il bundle di hosting .NET Core

Sistemi operativi supportati

Sono supportati i sistemi operativi seguenti:

  • Windows 7 o versione successiva
  • Windows Server 2008 R2 o versione successiva

Il server HTTP.sys (chiamato in precedenza WebListener) non funziona in una configurazione proxy inverso con IIS. Usare il server Kestrel.

Per informazioni sull'hosting in Azure, vedere Distribuire app ASP.NET Core in Servizio app di Azure.

Per indicazioni sulla risoluzione dei problemi, vedere Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core.

Piattaforme supportate

Sono supportate le app pubblicate per la distribuzione a 32 bit (x86) o a 64 bit (x64). Distribuire un'app a 32 bit con .NET Core SDK a 32 bit (x86), a meno che l'app:

  • Non richieda lo spazio indirizzi di memoria virtuale più grande disponibile per un'app a 64 bit.
  • Non richieda le dimensioni maggiori dello stack IIS.
  • Non abbia dipendenze native a 64 bit.

Usare .NET Core SDK a 64 bit (x64) per pubblicare un'app a 64 bit. Un runtime a 64 bit deve essere presente nel sistema host.

ASP.NET Core viene fornito con il server Kestrel, ovvero un server HTTP multipiattaforma predefinito.

Quando si usa IIS o IIS Express, l'app viene eseguita in un processo separato dal processo di lavoro IIS (out-of-process) con il server Kestrel.

Poiché le app ASP.NET Core vengono eseguite in un processo distinto dal processo di lavoro IIS, il modulo esegue la gestione dei processi. Il modulo avvia il processo per l'app ASP.NET Core quando arriva la prima richiesta e riavvia l'app se viene arrestata o si arresta in modo anomalo. Si tratta essenzialmente dello stesso comportamento delle app eseguite in-process e gestite dal servizio Attivazione processo Windows.

Il diagramma seguente illustra la relazione tra IIS, il modulo ASP.NET Core e un'app ospitata out-of-process:

Modulo ASP.NET Core

Le richieste arrivano dal Web al driver HTTP.sys in modalità kernel. Il driver instrada le richieste a IIS sulla porta configurata per il sito Web, in genere 80 (HTTP) o 443 (HTTPS). Il modulo inoltra le richieste a Kestrel su una porta casuale per l'app non corrispondente alla porta 80 o 443.

Il modulo specifica la porta tramite una variabile di ambiente all'avvio e il middleware di integrazione IIS configura il server per l'ascolto su http://localhost:{port}. Vengono eseguiti controlli aggiuntivi e le richieste che non provengono dal modulo vengono rifiutate. Il modulo non supporta l'inoltro HTTPS, pertanto le richieste vengono inoltrate tramite HTTP anche se sono state ricevute da IIS tramite HTTPS.

Dopo che Kestrel ha prelevato la richiesta dal modulo, viene eseguito il push della richiesta nella pipeline middleware di ASP.NET Core. La pipeline middleware gestisce la richiesta e la passa come istanza di HttpContext alla logica dell'app. Il middleware aggiunto dall'integrazione di IIS aggiorna lo schema, l'IP remoto e la base del percorso per l'account per l'inoltro della richiesta a Kestrel. La risposta dell'app viene quindi passata a IIS, che ne esegue di nuovo il push al client HTTP che ha avviato la richiesta.

CreateDefaultBuilder configura il server Kestrel come server Web e abilita l'integrazione di IIS configurando il percorso base e la porta per il modulo ASP.NET Core.

Il modulo ASP.NET Core genera una porta dinamica da assegnare al processo back-end. CreateDefaultBuilder chiama il metodo UseIISIntegration. UseIISIntegration configura Kestrel per l'ascolto sulla porta dinamica all'indirizzo IP localhost (127.0.0.1). Se la porta dinamica è 1234, Kestrel è in ascolto su 127.0.0.1:1234. Questa configurazione sostituisce le altre configurazioni URL fornite da:

Le chiamate a UseUrls o all'API Listen di Kestrel non sono necessarie quando si usa il modulo. In caso di chiamata di UseUrls o Listen, Kestrel resta in ascolto sulla porta specificata solo quando si esegue l'app senza IIS.

Per indicazioni sulla configurazione del modulo ASP.NET Core, vedere Modulo ASP.NET Core (ANCM) per IIS.

Per altre informazioni sull'hosting, vedere Hosting in ASP.NET Core.

Configurazione dell'applicazione

Abilitare i componenti IISIntegration

Quando si crea un host in CreateWebHostBuilder (Program.cs), chiamare CreateDefaultBuilder per abilitare l'integrazione IIS:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

Per altre informazioni su CreateDefaultBuilder, vedere Host Web ASP.NET Core.

Opzioni IIS

Opzione Predefiniti Impostazione
AutomaticAuthentication true Se true, IIS Server imposta l'utente HttpContext.User autenticato tramite l'autenticazione di Windows. Se false, il server fornisce solo un oggetto identity for HttpContext.User e risponde a problemi quando richiesto in modo esplicito da AuthenticationScheme. Per il funzionamento di AutomaticAuthentication l’autenticazione di Windows deve essere abilitata in IIS. Per altre informazioni, vedere Autenticazione di Windows.
AuthenticationDisplayName null Imposta il nome visualizzato dagli utenti nelle pagine di accesso.

Per configurare le opzioni di IIS includere una configurazione del servizio per IISOptions in ConfigureServices. Nell'esempio seguente si impedisce all'app di popolare HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opzione Predefiniti Impostazione
AutomaticAuthentication true Se true, il middleware di integrazione IIS imposta HttpContext.User autenticato tramite l'autenticazione di Windows. Se false, il middleware fornisce solo un oggetto identity per HttpContext.User e risponde alle sfide quando richiesto in modo esplicito da AuthenticationScheme. Per il funzionamento di AutomaticAuthentication l’autenticazione di Windows deve essere abilitata in IIS. Per altre informazioni, vedere l'argomento Autenticazione di Windows.
AuthenticationDisplayName null Imposta il nome visualizzato dagli utenti nelle pagine di accesso.
ForwardClientCertificate true Se è true ed è presente l’intestazione della richiesta MS-ASPNETCORE-CLIENTCERT, HttpContext.Connection.ClientCertificate viene popolato.

Scenari con server proxy e servizi di bilanciamento del carico

Il middleware di integrazione IIS, che consente di configurare il middleware delle intestazioni inoltrate, e il modulo ASP.NET Core sono configurati per inoltrare lo schema (HTTP/HTTPS) e l'indirizzo IP remoto di origine della richiesta. Potrebbero essere necessari interventi di configurazione aggiuntivi per le app ospitate dietro ulteriori server proxy e servizi di bilanciamento del carico. Per altre informazioni, vedere Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico.

file web.config

Il file web.config configura il modulo ASP.NET Core. La creazione, la trasformazione e la pubblicazione del file web.config sono operazioni gestite da una destinazione MSBuild (_TransformWebConfig) quando viene pubblicato il progetto. Questa destinazione si trova tra le destinazioni Web SDK (Microsoft.NET.Sdk.Web). L'SDK è impostato all'inizio del file di progetto:

<Project Sdk="Microsoft.NET.Sdk.Web">

Se un file web.config non è presente nel progetto, il file viene creato con l'argomento processPath e gli argomenti corretti per configurare il modulo core di ASP.NET e spostato nell'output pubblicato.

Se nel progetto è presente un file web.config, il file viene trasformato con il valore di processPath e gli argomenti corretti per la configurazione del modulo ASP.NET Core, quindi viene spostato nell'output pubblicato. La trasformazione non modifica le impostazioni di configurazione di IIS incluse nel file.

Il file web.config può fornire ulteriori impostazioni di configurazione di IIS che controllano i moduli IIS attivi. Per informazioni sui moduli IIS in grado di elaborare le richieste con le app di ASP.NET Core, vedere l'argomento Moduli IIS.

Per impedire che Web SDK trasformi il file web.config, usare la proprietà <IsTransformWebConfigDisabled> nel file di progetto:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Quando si disabilita la trasformazione del file in Web SDK, il valore di processPath e gli argomenti devono essere impostati manualmente dallo sviluppatore. Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

Posizione del file web.config

Per configurare correttamente il modulo ASP.NET Core, il file web.config deve essere presente nel percorso radice del contenuto (in genere il percorso base dell'app) dell'app distribuita. Corrisponde al percorso fisico del sito Web fornito a IIS. Il file web.config deve essere presente nella radice dell'app per abilitare la pubblicazione di più app mediante Distribuzione Web.

Nel percorso fisico dell'app sono presenti file sensibili, come <assembly>.runtimeconfig.json, <assembly>.xml (commenti documentazione XML) e <assembly>.deps.json. Quando il file web.config è presente e il sito viene avviato normalmente, IIS non rende disponibili questi file riservati se vengono richiesti. Se il file web.config non è presente, ha un nome non corretto o non è in grado di configurare il sito per l'avvio normale, IIS potrebbe rendere disponibili pubblicamente i file riservati.

Il file web.config deve essere sempre presente nella distribuzione, denominato correttamente e in grado di configurare il sito per l'avvio normale. Non rimuovere mai il file web.config da una distribuzione di produzione.

Trasformare web.config

Se è necessario trasformare web.config in fase di pubblicazione (ad esempio, impostare variabili di ambiente in base a configurazione, profilo o ambiente), vedere Trasformare web.config.

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

    Il ruolo Server Web IIS viene selezionato nel passaggio dei ruoli del server Selezionare.

  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.

    I servizi ruolo predefiniti vengono selezionati nel passaggio Selezionare i servizi ruolo.

    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.

La console di gestione IIS e servizi World Wide Web sono selezionati nelle funzionalità di Windows.

Installare il bundle di hosting .NET Core

Installare il bundle di hosting .NET Core nel sistema di hosting. L'aggregazione installa il runtime di .NET Core, la libreria di .NET Core e il modulo ASP.NET Core. Il modulo consente l'esecuzione delle app ASP.NET Core dietro IIS.

Importante

Se il bundle di hosting viene installato prima di IIS, è necessario riparare l'installazione del bundle. Eseguire di nuovo il programma di installazione del bundle di hosting dopo l'installazione di IIS.

Se il bundle di hosting viene installato dopo l'installazione della versione a 64 bit (x64) di .NET Core, uno o più SDK potrebbero risultare mancanti (Non sono stati rilevati .NET Core SDK). Per risolvere il problema, vedere Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core.

Scarica

  1. Passare alla pagina dei download di .NET Core.
  2. Selezionare la versione di .NET Core desiderata.
  3. Nella colonna Run apps - Runtime (App di esecuzione - Runtime), trovare la riga della versione di runtime di .NET Core desiderata.
  4. Scaricare il programma di installazione tramite il collegamento Runtime & Hosting Bundle (Runtime e bundle di hosting).

Avviso

Alcuni programmi di installazione contengono versioni che hanno terminato il loro ciclo di vita e non sono più supportate da Microsoft. Per altre informazioni, vedere i criteri di supporto.

Installare il bundle di hosting

  1. Eseguire il programma di installazione nel server. Quando si esegue il programma di installazione da una shell dei comandi di amministratore sono disponibili i parametri seguenti:

    • OPT_NO_ANCM=1: ignora l'installazione del modulo ASP.NET Core.
    • OPT_NO_RUNTIME=1: ignora l'installazione del runtime .NET Core. Usato quando il server ospita solo distribuzioni autonome (SCD).
    • OPT_NO_SHAREDFX=1: ignora l'installazione del framework condiviso di ASP.NET (runtime ASP.NET). Usato quando il server ospita solo distribuzioni autonome (SCD).
    • OPT_NO_X86=1: ignora l'installazione dei runtime x86. Usare questo parametro se si è certi che non verrà eseguito l'hosting di app a 32 bit. Se non esiste alcuna possibilità che in futuro venga eseguito l'hosting di app sia a 32 che a 64 bit, non usare questo parametro e installare entrambi i runtime.
    • OPT_NO_SHARED_CONFIG_CHECK=1: disabilitare il controllo dell'uso di una configurazione condivisa di IIS quando la configurazione condivisa (applicationHost.config) è nello stesso computer dell'installazione di IIS. Disponibile solo per i programmi di installazione di bundler di hosting ASP.NET Core 2.2 o versioni successive. Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

  2. Riavviare il sistema o eseguire i comandi seguenti in una shell dei comandi:

    net stop was /y
net start w3svc

    Il riavvio di IIS rileva una modifica alla variabile di ambiente di sistema PATH apportata dal programma di installazione.

Non è necessario arrestare manualmente singoli siti in IIS durante l'installazione del bundle di hosting. Le app ospitate (siti IIS) vengono riavviate al riavvio di IIS. Le app vengono avviate di nuovo quando ricevono la prima richiesta, incluse richiese dal modulo di inizializzazione dell'applicazione.

ASP.NET Core adotta il comportamento di roll forward per le versioni patch di pacchetti del framework condiviso. Quando le app ospitate da IIS vengono riavviate con IIS, le app vengono caricate con le versioni patch più recenti dei pacchetti a cui si fa riferimento quando ricevono la prima richiesta. Se IIS non viene riavviato, le app vengono riavviate e presentano un comportamento di roll forward quando i processi di lavoro vengono riciclati e ricevono la prima richiesta.

Nota

Per informazioni sulla configurazione condivisa di IIS, vedere Modulo di ASP.NET Core con configurazione condivisa di IIS.

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, usare Web Platform Installer (WebPI) o Download IIS: Distribuzione Web. Il metodo preferito consiste nell'usare WebPI. WebPI offre un'installazione autonoma e una configurazione per i provider di hosting.

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:

    Specificare il nome del sito, il percorso fisico e il nome Host nel passaggio Aggiungi sito Web.

    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.

    Impostare Nessun codice gestito per la versione .NET CLR.

    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. CoreCLR (Core Common Language Runtime) per .NET Core viene avviato per ospitare l'app nel processo di lavoro. L'impostazione di Versione .NET CLR su Nessun codice gestito è facoltativa ma consigliata.

  7. ASP.NET Core 2.2 o versioni successive: 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).

    Nella barra laterale Azioni in Gestione IIS >Pool di applicazioni selezionare Impostazioni predefinite pool di applicazioni o Impostazioni avanzate. Individuare Attiva applicazioni a 32 bit e impostare il valore su False. Questa impostazione non viene applicata alle app distribuite per l'hosting out-of-process.

  8. 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.

Distribuire l'app

Distribuire l'app nella cartella Percorso fisico di IIS specificata nella sezione Creare il sito IIS. Distribuzione Web è il meccanismo consigliato per la distribuzione, ma esistono diverse opzioni per spostare l'app dalla cartella di pubblicazione del progetto alla cartella di distribuzione del sistema di hosting.

Distribuzione web con Visual Studio

Vedere l'argomento Visual Studio publish profiles for ASP.NET Core app deployment (Profili di pubblicazione Visual Studio per la distribuzione di app ASP.NET Core) per informazioni su come creare un profilo di pubblicazione da usare con Distribuzione Web. Se il provider di hosting fornisce un profilo di pubblicazione o il supporto per crearne uno, scaricare il profilo e importarlo usando la finestra di dialogo Pubblica di Visual Studio:

Pagina della finestra di dialogo Pubblica

Distribuzione Web all'esterno di Visual Studio

È anche possibile usare Distribuzione Web all'esterno di Visual Studio dalla riga di comando. Per altre informazioni sulla distribuzione, vedere Strumento Distribuzione Web.

Alternative a Distribuzione web

Usare uno dei metodi disponibili, ad esempio la copia manuale, Xcopy, Robocopy o PowerShell, per spostare l'app nel sistema di hosting.

Per altre informazioni sulla distribuzione di ASP.NET Core in IIS, vedere la sezione Risorse di distribuzione per amministratori IIS.

Esplorazione del sito Web

Dopo aver distribuito l'app nel sistema di hosting, effettuare una richiesta a uno degli endpoint pubblici dell'app.

Nell'esempio seguente il sito viene associato a un nome host IIS di www.mysite.com in Porta 80. Viene effettuata una richiesta a http://www.mysite.com:

Il browser Microsoft Edge ha caricato la pagina di avvio IIS.

File di distribuzione bloccati

I file nella cartella di distribuzione sono bloccati durante l'esecuzione dell'app. I file bloccati non possono essere sovrascritti durante la distribuzione. Per rilasciare i file bloccati in una distribuzione, arrestare il pool di applicazioni usando uno dei metodi seguenti:

  • Usare Distribuzione Web e fare riferimento a Microsoft.NET.Sdk.Web nel file di progetto. Nella radice della directory dell'app Web viene posizionato un file app_offline.htm. Quando il file è presente, il modulo ASP.NET Core arresta normalmente l'app e rende disponibile il file app_offline.htm durante la distribuzione. Per altre informazioni, vedere la Guida di riferimento per la configurazione del modulo ASP.NET Core.

  • Arrestare manualmente il pool di applicazioni in Gestione IIS sul server.

  • Usare PowerShell per eliminare app_offline.htm (è richiesto PowerShell 5 o versione successiva):

    $pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

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 il gruppo di chiavi viene archiviato in memoria quando l'app viene riavviata:

  • 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 dati usate dalle app ASP.NET Core vengono archiviate nel Registro di sistema esterno alle app. Per mantenere le chiavi per una determinata app, creare chiavi del Registro di sistema per il pool di applicazioni.

    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 HKLM accessibile solo all'account del processo di lavoro del pool di applicazioni dell'app. Le chiavi vengono crittografate rest tramite DPAPI con una chiave a livello di computer.

    In scenari di web farm un'app può essere configurata in modo da usare un percorso UNC in cui archiviare il proprio gruppo di chiavi di protezione dati. Per impostazione predefinita, le chiavi di protezione dati non vengono crittografate. Assicurarsi che le autorizzazioni 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. Considerare l'implementazione di un meccanismo per consentire agli utenti di caricare i certificati: inserire 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. Vedere Configurare la protezione dati di ASP.NET Core per altri dettagli.

  • 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 salvate in modo permanente nella cartella %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

    Deve essere abilitato anche l'attributo setProfileEnvironment del pool di app. 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. Passare alla cartella %windir%/system32/inetsrv/config.
    2. Aprire 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 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 criteri a livello di computer predefiniti 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.

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.

Un'app secondaria non deve includere il modulo ASP.NET Core come gestore. Se il modulo viene aggiunto come gestore nel file web.config di un'app secondaria, quando si prova a esplorare l'app secondaria si riceve un messaggio 500.19 (errore interno del server) che segnala errori nel file di configurazione.

L'esempio seguente illustra un file web.config pubblicato per un'app secondaria di ASP.NET Core:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Quando si ospita un'app secondaria non ASP.NET Core in un'app ASP.NET Core, è necessario rimuovere in modo esplicito il gestore ereditato nel file web.config dell'app secondaria:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

I collegamenti ad asset statici all'interno dell'app secondaria devono usare la notazione con tilde-barra (~/). 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.

Configurazione di IIS con web.config

La configurazione di IIS è influenzata dalla sezione <system.webServer> di web.config per gli scenari IIS funzionali per le app ASP.NET Core con il modulo ASP.NET Core. Ad esempio, la configurazione di IIS è funzionale per la compressione dinamica. Se IIS è configurato a livello di server per l'uso della compressione dinamica, l'elemento <urlCompression> nel file web.config dell'app può disabilitare questa impostazione per un'app ASP.NET Core.

Per ulteriori informazioni, vedi gli argomenti seguenti:

Per impostare variabili di ambiente per singole app in esecuzione in pool di applicazioni isolate (supportati per IIS 10.0 o versioni successive), vedere la sezione Comando AppCmd.exe dell'argomento Variabili di ambiente <environmentVariables> nella documentazione di riferimento di IIS.

Sezioni non usate da ASP.NET Core

Le sezioni di configurazione di app ASP.NET 4.x in web.config non vengono usate dalle app ASP.NET Core per la configurazione:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

Le applicazioni ASP.NET Core vengono configurate tramite altri provider di configurazione. Per altre informazioni, vedere Configurazione.

Pool di applicazioni

Quando si ospitano più siti Web in un server, è consigliabile isolare le app le une dalle altre eseguendo ogni app nel relativo pool di applicazioni. La finestra di dialogo Aggiungi sito Web di IIS ha questa configurazione come impostazione predefinita. 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 Identity sia impostato per usare ApplicationPoolIdentity:

Finestra di dialogo Impostazioni avanzate del pool di applicazione

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\<nome_pool_applicazioni> nell'area Immettere i nomi degli oggetti da selezionare. 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 un valore di DefaultAppPool. Non è possibile immettere il nome del pool di applicazioni direttamente nell'area dei nomi degli oggetti. Usare il formato IIS AppPool\<nome_pool_applicazioni> durante il controllo dei nomi degli oggetti.

    Finestra di dialogo Seleziona utenti o gruppi per la cartella dell'app: il nome del pool di applicazioni

  6. Seleziona OK.

    Finestra di dialogo Seleziona utenti o gruppi per la cartella dell'app: dopo aver selezionato

  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 eseguito il comando seguente:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Per altre informazioni, vedere l'argomento icacls.

Supporto HTTP/2

HTTP/2 è supportato per le distribuzioni out-of-process che soddisfano i requisiti seguenti:

  • 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.
  • Frame di destinazione: non applicabile alle distribuzioni out-of-process, in quanto la connessione HTTP/2 è gestita interamente da IIS.
  • Connessione TLS 1.2 o successiva

Se viene stabilita una connessione HTTP/2, HttpRequest.Protocol corrisponde a HTTP/1.1.

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.

Risorse di distribuzione per amministratori IIS

Risorse aggiuntive