asp.net - Qual è la differenza tra la modalità pipeline "classica" e "integrata" in IIS7?




asp.net-mvc iis-7 (4)

Stavo distribuendo un'applicazione ASP.NET MVC la notte scorsa, e ho scoperto che è meno lavoro da implementare con IIS7 impostato sulla modalità integrata. La mia domanda è qual è la differenza? E quali sono le implicazioni dell'utilizzo dell'uno o dell'altro?


IIS 6.0 e versioni precedenti:

ASP.NET integrato con IIS tramite un'estensione ISAPI, un'API C (API basata sul linguaggio di programmazione C) ed esposto il proprio modello di elaborazione delle richieste e delle applicazioni.

Ciò ha esposto in modo efficace due pipeline server (richiesta / risposta) separate, una per i filtri ISAPI nativi e componenti di estensione e un'altra per i componenti delle applicazioni gestite. I componenti ASP.NET verrebbero eseguiti interamente all'interno della bolla di estensione ISAPI di ASP.NET E SOLO per le richieste associate a ASP.NET nella configurazione della mappa degli script di IIS.

Le richieste a tipi di contenuto non ASP.NET: - immagini, file di testo, pagine HTML e pagine ASP senza script, sono state elaborate da IIS o da altre estensioni ISAPI e NON erano visibili ad ASP.NET.

La principale limitazione di questo modello è stata che i servizi forniti dai moduli ASP.NET e il codice dell'applicazione ASP.NET personalizzato NON erano disponibili per richieste non ASP.NET

Cos'è una SCRIPT MAP?

Le mappe di script vengono utilizzate per associare le estensioni di file con il gestore ISAPI che viene eseguito quando viene richiesto quel tipo di file. La mappa degli script ha anche un'impostazione facoltativa che verifica che il file fisico associato alla richiesta esista prima di consentire l'elaborazione della richiesta

Un buon esempio può essere seen here

IIS 7 e versioni successive

IIS 7.0 e versioni successive sono state riprogettate da zero per fornire un ISAPI basato su API C ++ completamente nuovo.

IIS 7.0 e versioni successive integra il runtime ASP.NET con le funzionalità di base del server Web, fornendo una pipeline di elaborazione delle richieste unificata (singola) che è esposta a componenti nativi e gestiti noti come moduli (IHttpModules)

Ciò significa che IIS 7 elabora le richieste che arrivano per qualsiasi tipo di contenuto, con NON ASP.NET Modules / native IIS modules e ASP.NET modules forniscono l'elaborazione delle richieste in tutte le fasi Questo è il motivo per cui i tipi di contenuto NON ASP.NET ( .html, file statici) possono essere gestiti da moduli .NET.

  • È possibile creare nuovi moduli gestiti ( IHttpModule ) che possono essere eseguiti per tutti i contenuti dell'applicazione e fornito un set potenziato di servizi di elaborazione delle richieste all'applicazione.
  • Aggiungi nuovi gestori gestiti ( IHttpHandler )

Modalità pool di applicazioni integrate

Quando un pool di applicazioni è in modalità integrata, è possibile sfruttare l'architettura di elaborazione delle richieste integrata di IIS e ASP.NET. Quando un processo di lavoro in un pool di applicazioni riceve una richiesta, la richiesta passa attraverso un elenco ordinato di eventi. Ogni evento chiama i moduli nativi e gestiti necessari per elaborare parti della richiesta e generare la risposta.

Esistono numerosi vantaggi nell'esecuzione di pool di applicazioni in modalità integrata. Innanzitutto i modelli di elaborazione delle richieste di IIS e ASP.NET sono integrati in un modello di processo unificato. Questo modello elimina i passaggi precedentemente duplicati in IIS e ASP.NET, ad esempio l'autenticazione. Inoltre, la modalità integrata consente la disponibilità di funzionalità gestite per tutti i tipi di contenuto.

Modalità pool di applicazioni classiche

Quando un pool di applicazioni è in modalità classica, IIS 7.0 gestisce le richieste come in modalità di isolamento del processo di lavoro di IIS 6.0. Le richieste ASP.NET eseguono prima i passaggi di elaborazione nativi in ​​IIS e vengono quindi indirizzate a Aspnet_isapi.dll per l'elaborazione del codice gestito nel runtime gestito. Infine, la richiesta viene reinstradata tramite IIS per inviare la risposta.

Questa separazione dei modelli di elaborazione delle richieste di IIS e ASP.NET comporta la duplicazione di alcuni passaggi di elaborazione, come l'autenticazione e l'autorizzazione. Inoltre, le funzionalità di codice gestito, come l'autenticazione dei moduli, sono disponibili solo per le applicazioni o le applicazioni ASP.NET per le quali è stato eseguito il mapping di tutte le richieste da parte di aspnet_isapi.dll.

Assicurarsi di verificare le compatibilità delle applicazioni esistenti in modalità integrata prima di aggiornare un ambiente di produzione a IIS 7.0 e assegnare le applicazioni ai pool di applicazioni in modalità integrata. È necessario aggiungere un'applicazione a un pool di applicazioni solo in modalità classica se l'applicazione non riesce a funzionare in modalità integrata. Ad esempio, l'applicazione potrebbe fare affidamento su un token di autenticazione passato da IIS al runtime gestito e, a causa della nuova architettura in IIS 7.0, il processo interrompe l'applicazione.

Tratto da: Qual è la differenza tra DefaultAppPool e Classic .NET AppPool in IIS7?

Fonte originale: Introduzione all'architettura di IIS


Nella modalità classica, IIS funziona direttamente con estensioni ISAPI e filtri ISAPI. E utilizza due linee di tubi, una per il codice nativo e l'altra per il codice gestito. Si può semplicemente dire che in modalità classica IIS 7.x funziona proprio come IIS 6 e non si ottengono benefici extra dalle funzionalità di IIS 7.x.

In modalità integrata, IIS e ASP.Net sono strettamente accoppiati piuttosto che in base a due sole DLL su Asp.net come nel caso della modalità classica.


Modalità classica In genere, lo spostamento di un'applicazione Web da IIS 6.0 a IIS 7.0 richiede solo che l'applicazione venga inserita in un pool di applicazioni in esecuzione in modalità classica. Ad esempio, quando si installa IIS 7.0, per impostazione predefinita il server Web è configurato per funzionare in modalità integrata. È inoltre configurato per l'esecuzione nel pool di applicazioni predefinito, denominato DefaultAppPool. Per eseguire un'applicazione Web in modalità classica, utilizzare l'applicazione Classic.NETAppPool o creare un nuovo pool di applicazioni configurato per l'esecuzione in modalità classica. Per informazioni su come creare un pool di applicazioni, vedere Creare un pool di applicazioni. Qualsiasi modulo personalizzato che implementa l'interfaccia IHttpModule in un'applicazione che viene eseguita in modalità classica viene informato solo sulle richieste di pipeline gestite dal runtime di ASP.NET. Ad esempio, vengono notificati sulle richieste di una pagina .aspx. Il ciclo di vita dell'applicazione per la modalità classica è uguale al ciclo di vita di ASP.NET in IIS 6.0. Per ulteriori informazioni, vedere Panoramica del ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0. Se un'applicazione che viene eseguita in modalità classica contiene un gestore che richiede una mappa di script per gestire un'estensione personalizzata in IIS, è necessario registrare il gestore sia nel gruppo httpHandler che nel gruppo di gestori. Si esegue il mapping dell'estensione del nome file personalizzata all'estensione ISAPI di ASP.NET (Aspnet_isapi.dll) specificando i moduli e gli attributi scriptProcessor nell'elemento gestore. Questi attributi specificano che il modulo che definisce il gestore è un'estensione ISAPI e specificano il percorso di tale estensione. In questo modo IIS 7.0 in modalità classica offre compatibilità con le precedenti versioni di IIS. Tuttavia, se si esegue l'applicazione in modalità integrata, è necessario rimuovere i moduli e gli attributi scriptProcessor. Per ulteriori informazioni, vedere Procedura: configurare un'estensione gestore HTTP in IIS. Quando si sposta un'applicazione Web da IIS 6.0 alla modalità classica, non è garantito il funzionamento in modalità integrata senza modifiche. Se si passa un'applicazione dalla modalità classica alla modalità integrata (e si modifica qualsiasi modulo e gestore personalizzato), potrebbe essere necessario apportare ulteriori modifiche affinché l'applicazione funzioni correttamente in modalità integrata. La prossima sezione di questo argomento spiega come spostare un'applicazione in modalità integrata di IIS 7.0.

Le applicazioni Web in modalità integrata che non includono moduli o gestori personalizzati funzioneranno normalmente senza modifiche in modalità integrata in IIS 7.0. Le applicazioni Web che si basano su moduli o gestori personalizzati richiedono i seguenti passaggi per abilitare l'esecuzione dell'applicazione in modalità integrata: registrare i moduli e i gestori personalizzati nella sezione system.webServer del file Web.config utilizzando uno dei metodi descritti nella Migrazione una sezione Configurazione file Web in modalità integrata più avanti in questo argomento. Definire i gestori di eventi per gli eventi della pipeline della richiesta HttpApplication come BeginRequest e EndRequest solo nel metodo Init del modulo personalizzato. Assicurarsi di aver risolto eventuali problemi discussi nella sezione "Differenze conosciute tra modalità integrata e modalità classica" di Aggiornamento delle applicazioni ASP.NET a IIS 7.0: differenze tra la modalità integrata di IIS 7.0 e la modalità classica. I moduli che implementano l'interfaccia IHttpModule sono indicati come moduli di codice gestito perché sono costruiti utilizzando .NET Framework. I moduli di codice gestito possono essere registrati a livello di server o a livello di applicazione. I moduli di codice nativo sono DLL (codice non gestito) che sono registrati solo a livello di server. Le funzionalità principali di ASP.NET, come lo stato della sessione e l'autenticazione dei moduli, sono implementate come moduli gestiti in modalità integrata. Quando sposti un'applicazione dalla modalità classica alla modalità integrata, puoi lasciare moduli personalizzati e registrazioni di gestori per la modalità classica, oppure puoi rimuoverli. Se non si rimuovono le registrazioni httpModules e httpHandlers utilizzate in modalità classica, è necessario impostare l'attributo validateIntegratedModeConfiguration dell'elemento di convalida su false per evitare errori. L'elemento di convalida è un elemento figlio dell'elemento system.webServer. Per ulteriori informazioni, consultare la sezione "Disabilitazione del messaggio di migrazione" in Integrazione ASP.NET con IIS 7.0.





integrated-pipeline-mode