Qual è la differenza tra la modalità pipeline "classica" e "integrata" in IIS7?

Question

Ieri sera stavo distribuendo un'applicazione ASP.NET MVC 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?

Answer 1

La modalità classica (l'unica modalità in IIS6 e in basso) è una modalità in cui IIS funziona solo con estensioni ISAPI e filtri ISAPI direttamente. Infatti, in questa modalità, ASP.NET è solo un'estensione ISAPI (aspnet_isapi.dll) e un filtro ISAPI (aspnet_filter.dll). IIS tratta semplicemente ASP.NET come un plugin esterno implementato in ISAPI e funziona come una scatola nera (e solo quando è necessario fornire la richiesta a ASP.NET). In questa modalità, ASP.NET non è molto diverso da PHP o altre tecnologie per IIS.

La modalità integrata, d'altra parte, è una nuova modalità in IIS7 in cui la pipeline IIS è strettamente integrata (vale a dire la stessa) della pipeline di richieste ASP.NET. ASP.NET può vedere ogni richiesta che desidera e manipolare le cose lungo la strada. ASP.NET non viene più considerato come un plugin esterno. È completamente integrato e integrato in IIS. In questa modalità, ASP.NET HttpModule s ha praticamente la stessa potenza di un filtro ISAPI e ASP.NET HttpHandler s può avere capacità quasi equivalenti come potrebbe avere un'estensione ISAPI. In questa modalità, ASP.NET è fondamentalmente una parte di IIS.

Answer 2

integrato modalità del pool di applicazioni

Quando un pool di applicazioni è in modalità integrata, è possibile usufruire 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 per generare la risposta.

Esistono numerosi vantaggi per l'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, come l'autenticazione . Inoltre, la modalità integrata consente la disponibilità di funzioni gestite a tutti i tipi di contenuto.

modalità del pool di applicazioni Classic

Quando un pool di applicazioni è in modalità classica, IIS 7.0 gestisce le richieste come in 6.0 modalità di isolamento processo di IIS. richieste ASP.NET prima passare attraverso fasi di lavorazione nativi in ​​IIS e vengono poi indirizzati a Aspnet_isapi.dll per l'elaborazione di codice gestito in gestito runtime. Infine, la richiesta viene instradata indietro attraverso IIS per inviare la risposta .

Questa separazione del IIS e modelli di elaborazione delle richieste ASP.NET risultati in duplicazione di alcune fasi di lavorazione, come autenticazione e l'autorizzazione. Inoltre, gestito caratteristiche codice, come l'autenticazione moduli, sono disponibili solo per ASP.NET applicazioni o applicazioni per le quali si dispone di script mappato tutti richieste per essere gestiti da aspnet_isapi.dll.

Verificare la compatibilità delle applicazioni esistenti nella modalità integrata prima di aggiornare un ambiente di produzione su IIS 7.0 e assegnare le applicazioni ai pool di applicazioni in modalità integrata. È necessario aggiungere un'applicazione a un pool di applicazioni solo nella modalità Classic 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: What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?

Fonte originale: Introduction to IIS Architecture

Answer 3

Nella modalità classica di IIS funziona estensioni ISAPI h e filtri ISAPI direttamente. 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.

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

Answer 4

IIS 6.0 e versioni precedenti:

ASP.NET integrato con IIS tramite un'estensione ISAPI, un'API C (C Linguaggio di programmazione API based) ed esposti la propria applicazione e richiesta di modello di elaborazione .

Questo efficacemente esposto due pipeline server (richiesta/risposta) separati, uno per i filtri ISAPI nativi e componenti di estensione e un altro 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 ASP.NET non: - immagini, file di testo, pagine HTML e pagine ASP senza script, sono state elaborate da IIS o altre estensioni ISAPI e NON erano visibili ad ASP.NET.

La maggiore limitazione di questo modello è che i servizi forniti da ASP.NET codice dell'applicazione moduli e personalizzati ASP.NET non erano disponibili per non ASP.NET chiede

che cosa è uno SCRIPT MAP?

Le mappe di script vengono utilizzate per associare le estensioni di file al gestore ISAPI che viene eseguito quando viene richiesto quel tipo di file. La mappa script ha anche un'impostazione opzionale che verifica che il file fisico associato alla richiesta esiste prima di consentire la richiesta da elaborare

Un buon esempio può essere seen here

IIS 7 e sopra

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 Web Server, che fornisce un unico (single) pipeline di elaborazione della richiesta che è esposto a entrambi i 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 che forniscono l'elaborazione delle richieste in tutte le fasiQuesto è il motivo per cui i tipi di contenuto NON ASP.NET (html, file statici) possono essere gestito da moduli .NET.

• È possibile costruire nuovi moduli gestiti (IHttpModule) che hanno la capacità di eseguire per tutti i contenuti delle applicazioni, e ha fornito una serie dei migliori servizi di elaborazione richiesta per l'applicazione.
• Aggiungere nuovi gestori gestiti (IHttpHandler)

Answer 5

Classic Mode Tipicamente, lo spostamento di un'applicazione Web da IIS 6.0 a IIS 7.0 modalità Classic richiede solo che si mette l'applicazione 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.

modalità di integrazione con applicazioni Web che non includono moduli personalizzati o di gestori di solito è quella corretta, senza cambiamenti nelle 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 nel Migrazione di un file di configurazione Web nella sezione 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 di 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 detti 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 si sposta un'applicazione dalla modalità classica alla modalità integrata, è possibile lasciare i moduli personalizzati e le registrazioni del gestore per la modalità classica o 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.