ASP.NET Integrazione con IIS 7

di Mike Volodarsky

Introduzione

Dal rilascio, ASP.NET è stata la piattaforma di scelta per lo sviluppo di applicazioni Web nella piattaforma Windows/IIS. ASP.NET 2.0 ha portato lo sviluppo di applicazioni Web a un nuovo livello, consentendo agli sviluppatori di creare applicazioni più potenti che mai.

IIS 7 e versioni successive richiede ASP.NET ulteriormente integrando il modello di estendibilità del runtime ASP.NET con il server principale. Ciò consente agli sviluppatori di estendere completamente il server IIS con la ricchezza di ASP.NET 2.0 e .NET Framework, anziché usare le API IIS C++ meno compatibili. Le applicazioni di ASP.NET esistenti possono anche trarre vantaggio dall'integrazione più stretta usando funzionalità di ASP.NET esistenti, ad esempio l'autenticazione, i ruoli e la memorizzazione nella cache di output per tutti i contenuti.

Mentre IIS offre l'integrazione migliorata ASP.NET per impostazione predefinita, è possibile scegliere: IIS supporta sia le nuove che le precedenti modalità di integrazione ASP.NET che possono essere usate side-by-side nello stesso server.

Questo articolo illustra i miglioramenti introdotti dalla modalità di integrazione ASP.NET, l'architettura delle due modalità e descrive come selezionare e configurare le modalità di integrazione per le applicazioni ASP.NET.

ASP.NET miglioramenti in IIS 7 e versioni successive

Una migliore integrazione ASP.NET in IIS migliora le applicazioni esistenti e consente anche alle nuove applicazioni di sfruttare ASP.NET funzionalità nei modi seguenti:

• ASP.NET servizi possono essere usati per tutti i tipi di contenuto. In passato, ASP.NET funzionalità come l'autenticazione dei moduli, i ruoli, l'autorizzazione url e la memorizzazione nella cache degli output erano disponibili solo per ASP.NET tipi di contenuto come pagine ASPX. I file statici, le pagine ASP e altri tipi di contenuto non possono trarre vantaggio da questi servizi.

In IIS tutti i servizi ASP.NET vengono forniti in modo uniforme a tutti i contenuti. Ad esempio, è possibile proteggere tutti i contenuti Web, incluse le immagini e le pagine ASP, con la soluzione di controllo degli accessi esistente ASP.NET 2.0 basata su ASP.NET l'autenticazione, l'appartenenza e i controlli di accesso.

• Estendere completamente IIS con ASP.NET. Le versioni precedenti di IIS richiedono spesso lo sviluppo dell'estendibilità del server usando il filtro ISAPI nativo o la modalità di estendibilità dell'estensione, a causa delle limitazioni di runtime di ASP.NET.

IIS consente ai moduli di ASP.NET di connettersi direttamente alla pipeline del server, con la stessa fedeltà di runtime dei moduli sviluppati con l'API server nativa (C++). ASP.NET moduli possono essere eseguiti in tutte le fasi di runtime della pipeline di elaborazione delle richieste e possono essere eseguiti in qualsiasi ordine rispetto ai moduli nativi. L'API ASP.NET viene espansa anche per consentire un maggiore controllo sull'elaborazione delle richieste rispetto a quanto è stato possibile in precedenza.

• Runtime del server unificato. L'integrazione più stretta ASP.NET unifica anche molte delle funzionalità tra IIS e ASP.NET.

IIS fornisce una configurazione unificata per i moduli e i gestori IIS e ASP.NET. Molte altre funzionalità, tra cui errori personalizzati e traccia, sono state unificate per consentire una migliore progettazione di applicazioni e gestione condivisa.

Architettura di integrazione ASP.NET

Nelle versioni precedenti e 6.0 di IIS ASP.NET è stata implementata come estensione ISAPI IIS.

In queste versioni precedenti IIS ha elaborato una richiesta a un tipo di contenuto ASP.NET e quindi ha inoltrato tale richiesta alla DLL ISAPI ASP.NET, che ha ospitato la pipeline di richieste di ASP.NET e il framework di pagina. Le richieste di non-ASP.NET contenuto, ad esempio pagine ASP o file statici, sono state elaborate da IIS o da altre estensioni ISAPI e non sono state visibili per ASP.NET.

La limitazione principale di questo modello era che i servizi forniti dai moduli ASP.NET e il codice applicazione personalizzato ASP.NET non erano disponibili per le richieste di non-ASP.NET. Inoltre, ASP.NET moduli non erano in grado di influire su determinate parti dell'elaborazione delle richieste IIS che si sono verificate prima e dopo il percorso di esecuzione ASP.NET.

Figura 1: Pipeline di & ASP.NET IIS 6.0

In IIS, la pipeline di elaborazione delle richieste ASP.NET sovrappone direttamente la pipeline IIS, fornendo essenzialmente un wrapper su di esso anziché collegarlo.

IIS elabora le richieste che arrivano per qualsiasi tipo di contenuto, con moduli IIS nativi e moduli ASP.NET che forniscono l'elaborazione delle richieste in tutte le fasi. In questo modo, i servizi forniti da ASP.NET moduli, ad esempio l'autenticazione dei moduli o la cache di output, possono essere usati per le richieste a pagine ASP, pagine PHP, file statici e così via.

La possibilità di connettersi direttamente alla pipeline del server consente ASP.NET moduli da sostituire, eseguire prima o eseguire dopo qualsiasi funzionalità IIS. Ciò consente, ad esempio, un modulo di autenticazione personalizzato ASP.NET Basic scritto per usare il servizio Appartenenza e SQL Server database utente per sostituire la funzionalità di autenticazione di base IIS predefinita che funziona solo con gli account Windows.

Inoltre, le API di ASP.NET espanse usano l'integrazione diretta per abilitare più attività di elaborazione delle richieste. Ad esempio, ASP.NET moduli possono modificare le intestazioni delle richieste prima che altri componenti elaborano la richiesta, inserendo un'intestazione di Accept-Language prima dell'esecuzione delle applicazioni ASP, che forza l'invio del contenuto localizzato al client in base alle preferenze utente.

Figura 2: IIS 7 e versioni successive della modalità integrata

A causa dell'integrazione del runtime, IIS e ASP.NET possono usare la stessa configurazione per abilitare e ordinare i moduli del server e configurare i mapping dei gestori. Altre funzionalità unificate includono la traccia, gli errori personalizzati e la memorizzazione nella cache di output.

Compatibilità

In particolare, l'architettura gestisce l'architettura e le API di runtime ASP.NET, che consente alle applicazioni e ai servizi ASP.NET esistenti di funzionare all'installazione. Con alcune modifiche, le applicazioni e i servizi ASP.NET esistenti possono sfruttare le nuove funzionalità di ASP.NET.

Analogamente, gli sviluppatori possono continuare a scrivere nuove applicazioni per acquisire familiari ASP.NET API mentre sfruttano i vantaggi dell'integrazione del runtime.

IIS continua a fornire la modalità di ASP.NET classica per le applicazioni ASP.NET con requisiti di compatibilità specifici non soddisfatti dalla modalità integrata. Gli amministratori possono selezionare la modalità di integrazione desiderata per ogni pool di applicazioni, che consente alle applicazioni che usano sia le nuove che le modalità di ASP.NET classiche per funzionare side-by-side nello stesso server.

Migrazione di applicazioni ASP.NET in IIS 7 e versioni successive della modalità integrata

In IIS, ASP.NET è configurato per funzionare nella nuova modalità integrata per impostazione predefinita. Ciò consente all'applicazione di sfruttare i miglioramenti della modalità integrata con modifiche minime.

A causa dell'unificazione della configurazione, alcune applicazioni possono richiedere la migrazione per funzionare correttamente in modalità integrata. Per impostazione predefinita, il server fornisce assistenza per la migrazione. Rileva applicazioni che richiedono la migrazione e restituisce un messaggio di errore che richiede la migrazione dell'applicazione.

La configurazione seguente causa l'errore di migrazione:

1. Il file dell'applicazione Web.config definisce <la configurazione httpModules> .
   L'applicazione carica nuovi moduli ASP.NET o rimuove quelli esistenti.
   In modalità integrata, i moduli di ASP.NET vengono specificati con moduli nativi nella sezione configurazione di system.webServer>/<modules> unificata<.
   I moduli ASP.NET specificati nella sezione di configurazione system.web>/httpModules devono essere spostati> nella nuova sezione di configurazione per eseguire l'effetto<<. Successivamente, i nuovi moduli di ASP.NET devono essere aggiunti direttamente alla sezione unificata <modules> .
2. L'applicazione Web.config file definisce <httpHandlers> la configurazione.
   L'applicazione usa mapping di gestori personalizzati per alcuni tipi di contenuto.
   In modalità integrata, è necessario specificare ASP.NET mapping dei gestori nella sezione configurazione unified <system.webServer>/<handlers> per eseguire l'effetto. Successivamente, i nuovi mapping dei gestori di ASP.NET devono essere aggiunti direttamente alla sezione unificata <handlers> .
   Questa sezione sostituisce sia la configurazione ASP.NET <httpHandlers> che la configurazione degli scriptmap IIS, entrambe le quali in precedenza dovevano essere configurate per configurare un mapping del gestore ASP.NET.
3. Il file di Web.config dell'applicazione definisce <la rappresentazione dell'identità="true" /> configurazione.
   L'applicazione rappresenta le credenziali client, che è più comune con le applicazioni Intranet. In modalità integrata la rappresentazione client non è disponibile in alcune fasi iniziali di elaborazione delle richieste. Nella maggior parte dei casi, questo non è un problema e è possibile disattivare l'errore di migrazione. In caso contrario, è necessario configurare questa applicazione da eseguire usando la modalità di ASP.NET classica.

Quando viene generato l'errore di migrazione, può in genere eseguire la migrazione della configurazione dell'applicazione (consigliata nei casi 1 e 2, sopra) o spostare l'applicazione per usare la modalità di ASP.NET classica (nel caso 3).

Migrazione della configurazione dell'applicazione

IIS esegue la migrazione dell'applicazione usando lo strumento della riga di comando AppCmd.exe per eseguire la migrazione. Il messaggio di errore di migrazione contiene il comando eseguito nella finestra della riga di comando, che è necessario eseguire con diritti utente amministratore, per eseguire immediatamente la migrazione dell'applicazione in modalità integrata.

Il formato di base del comando di migrazione è il seguente:

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

> Dove <Percorso applicazione è il percorso virtuale dell'applicazione che contiene il nome del sito, ad esempio "Sito Web predefinito/app1".

Al termine della migrazione, l'applicazione verrà eseguita in modalità integrata e classica senza problemi.

Nota

Se si modifica la configurazione dopo la migrazione, il server non richiede di eseguire di nuovo la migrazione. Dopo la migrazione iniziale, è necessario assicurarsi che la configurazione rimanga sincronizzata tra le due modalità. È possibile eseguire di nuovo la migrazione manuale dell'applicazione usando lo strumento della riga di comando AppCmd.exe.

Tornare alla modalità di integrazione classica ASP.NET

Se si preferisce tornare alla modalità di ASP.NET classica, spostare l'applicazione in un pool di applicazioni configurato per l'esecuzione in modalità classica. Altre applicazioni continuano a essere eseguite nella nuova modalità integrata side-by-side con l'applicazione in modalità classica.

Per altre informazioni su come spostare un'applicazione nella modalità classica ASP.NET, vedere Modifica delle modalità di ASP.NET per un'applicazione.

Disabilitazione del messaggio di errore di migrazione

Se la configurazione è stata eseguita manualmente o si vuole rimanere in modalità integrata senza eseguire la migrazione della configurazione (non consigliata), è possibile disabilitare il messaggio di errore di migrazione aggiungendo quanto segue al file di Web.config dell'applicazione:

<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" />    
</system.webServer>

Nota

Il server disabilita automaticamente il messaggio di errore dopo la migrazione della configurazione con lo strumento della riga di comando AppCmd.exe.

Se si disabilita manualmente il messaggio di errore di migrazione, è necessario assicurarsi che l'applicazione funzioni correttamente in modalità integrata, perché il server non fornisce più avvisi sulla configurazione non supportata.

Modifica delle modalità di ASP.NET per un'applicazione

Se l'applicazione non funziona correttamente in modalità Integrata ASP.NET, è possibile spostarla nella modalità classica ASP.NET spostandola in un altro pool di applicazioni. Ogni pool di applicazioni è configurato singolarmente per usare la modalità di integrazione desiderata ASP.NET. In questo modo è possibile eseguire gruppi di applicazioni che usano diverse modalità di integrazione ASP.NET side-by-side nello stesso server.

Per modificare la modalità di integrazione ASP.NET per un'applicazione:

1. Trovare o creare un pool di applicazioni configurato per usare la modalità desiderata.
   Per impostazione predefinita, tutti i nuovi pool di applicazioni vengono eseguiti in modalità integrata.
   La ASP.NET configurata fornisce un pool di applicazioni denominato "Classico .NET AppPool" eseguito nella modalità di integrazione classica ASP.NET. È possibile usare questo pool di applicazioni per le applicazioni che non devono essere eseguite in modalità integrata.
   È anche possibile modificare la modalità ASP.NET del pool di applicazioni esistente usando lo strumento di amministrazione IIS o lo strumento della riga di comando AppCmd.exe oppure modificando manualmente la configurazione del pool di applicazioni.
2. Impostare l'applicazione per l'uso del pool di applicazioni.
   Ogni applicazione è configurata per l'uso di un determinato pool di applicazioni. Per impostazione predefinita, tutte le applicazioni usano il pool di applicazioni predefinito denominato "DefaultAppPool", che viene eseguito in modalità integrata.
   È possibile modificare il pool di applicazioni di un'applicazione usando lo strumento di amministrazione IIS o lo strumento della riga di comando AppCmd.exe oppure modificando manualmente la configurazione dell'applicazione.

Selezione di una versione ASP.NET per un'applicazione

In precedenza, IIS supporta più versioni di ASP.NET/CLR side-by-side. Ad esempio, IIS consente allo stesso server di eseguire applicazioni ASP.NET usando .NET Framework v1.1 e v2.0. Questo supporto è stato fornito eseguendo il mapping di una versione corrispondente di ASPNET_isapi.dll per gestire le richieste per il contenuto ASP.NET usando la configurazione delle mappe script IIS.

Ad esempio, è possibile usare la configurazione scriptmap seguente per abilitare il supporto side-by-side:

1. ASP.NET applicazione v1.1 in /app1:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET applicazione v2.0 in /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

Quando l'applicazione riceve una richiesta *.aspx, IIS carica il aspnet_isapi.dll specificato, che carica la versione CLR corretta nel processo di lavoro e elabora la richiesta.

ASP.NET fornisce anche i modi seguenti per configurare le mappe script side-by-side:

1. ASP.NET estensione MMC. Quando si seleziona la versione di ASP.NET da usare, l'estensione configura automaticamente le mappe script per l'applicazione per puntare alla versione corretta di aspnet_isapi.dll.
2. ASP.NET aspnet_regiis.exe. Usare le opzioni –i e -r per installare le mappe script che puntano alla versione di ASP.NET corrispondente.

Sfortunatamente, a causa della limitazione della possibilità di caricare una sola versione CLR in un singolo processo di lavoro, è necessario assicurarsi che due applicazioni che usano versioni diverse di ASP.NET non siano mai configurate per esistere all'interno dello stesso pool di applicazioni. Quando viene fatto questo errore comune, la prima richiesta carica il CLR del aspnet_isapi.dll corrispondente e le richieste successive all'altra versione all'interno dello stesso pool di applicazioni avranno esito negativo.

IIS riconosce che il pool di applicazioni è la versione ASP.NET selezionata per eseguire un'applicazione in . Di conseguenza, la versione di CLR/ASP.NET caricata nel pool di applicazioni viene configurata in modo esplicito nella configurazione del pool di applicazioni. Per impostazione predefinita, IIS pre-carica clR specificato da questa impostazione durante il caricamento del processo di lavoro (a meno che la versione non sia configurata per essere vuota).

Poiché i pool di applicazioni sono il limite di controllo delle versioni di .NET Framework, è possibile modificare la versione di un'applicazione ASP.NET eseguendo le operazioni seguenti:

1. Spostare l'applicazione in un pool di applicazioni che usa la versione di ASP.NET desiderata.
   Per impostazione predefinita, le applicazioni usano il pool di applicazioni predefinito denominato "DefaultAppPool", che esegue ASP.NET v2.1 in modalità integrata. Spostare l'applicazione in "Classic .NET AppPool" da eseguire in ASP.NET modalità classica v2.1 o in un altro pool di applicazioni preferito.
2. Configurare il pool di applicazioni in cui l'applicazione è in esecuzione per usare la versione desiderata ASP.NET.
   Per impostazione predefinita, tutti i nuovi pool di applicazioni sono configurati per l'esecuzione ASP.NET v2.1 in modalità integrata.

Nota

Non usare aspnet_regiis /i o /r opzioni per configurare la versione di ASP.NET per una determinata applicazione o a livello globale.

IIS usa i mapping dei gestori precondati per selezionare automaticamente il set corretto di mapping dei gestori (per ASPNET_isapi.dll in modalità classica o direttamente ai tipi di gestore gestiti in modalità integrata) a seconda della versione CLR configurata e della modalità di integrazione gestita del pool di applicazioni. L'installazione di ASP.NET 2.0 installa questi mapping dei gestori a livello di server.

Sfruttare il vantaggio della modalità ASP.NET integrata

In IIS, ASP.NET applicazioni eseguite in modalità integrata per impostazione predefinita. Tuttavia, per sfruttare i vantaggi offerti dall'integrazione più stretta, è necessario apportare alcune modifiche alla configurazione dell'applicazione. È anche possibile sviluppare nuovi componenti ASP.NET che sfruttano la modalità integrata per offrire funzionalità potenti all'applicazione.

Abilitazione di servizi ASP.NET per tutti i tipi di contenuto

In modalità integrata, i servizi forniti dai moduli ASP.NET sono disponibili per le richieste per tutti i tipi di contenuto. Tuttavia, per impostazione predefinita, i moduli ASP.NET sono configurati per l'esecuzione solo per le richieste di ASP.NET contenuto per la compatibilità con le versioni precedenti.

A tale scopo, collegare una precondizione managedHandler a ogni modulo ASP.NET nella sezione di configurazione a livello di server:

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

La precondizione è una regola che il server valuta in ogni richiesta per determinare se verrà eseguito un modulo. La precondizione managedHandler è true solo per le richieste ai tipi di contenuto mappati ai gestori di ASP.NET.

Per applicare le funzionalità fornite da un modulo ASP.NET a tutte le richieste, rimuovere la voce del modulo e quindi aggiungerla nuovamente senza la precondizione nel file radice dell'applicazione Web.config.

Per abilitare l'autenticazione ASP.NET Forms per l'intera applicazione, modificare il file Web.config come segue:

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

Con questa modifica, il modulo FormsAuthentication viene eseguito per tutte le richieste nell'applicazione. In questo modo è possibile proteggere tutto il contenuto dell'applicazione con l'autenticazione di Forms. Per altre informazioni su come sfruttare la modalità integrata per fornire l'autenticazione dei moduli per tutti i contenuti dell'applicazione, vedere Procedura dettagliata sulla modalità pipeline integrata.

È anche possibile usare un collegamento per abilitare tutti i moduli gestiti (ASP.NET) da eseguire per tutte le richieste nell'applicazione, indipendentemente dalla precondizione "managedHandler". Per abilitare l'esecuzione di tutti i moduli gestiti per tutte le richieste senza configurare ogni voce del modulo per rimuovere la precondizione "managedHandler", usare la proprietà runAllManagedModulesForAllRequests nella <modules> sezione:

<modules runAllManagedModulesForAllRequests="true" />

Quando si usa questa operazione, la precondizione "managedHandler" non ha alcun effetto e tutti i moduli gestiti verranno eseguiti per tutte le richieste.

Sperimentare l'abilitazione di altri moduli di ASP.NET da applicare all'intera applicazione. Ad esempio, usare il modulo cache di output ASP.NET per memorizzare nella cache le pagine ASP o usare Autorizzazione URL e Gestione ruoli per configurare le regole di controllo di accesso per le foto. In alternativa, sviluppare il proprio modulo per portare la potenza di ASP.NET all'intero sito Web.

Creazione di servizi di ASP.NET più potenti

In modalità integrata, ASP.NET moduli applicano i propri servizi a tutti i contenuti. Inoltre, poiché ASP.NET moduli vengono eseguiti nella pipeline di elaborazione unificata delle richieste in modalità integrata, sottoscrivono le stesse fasi di elaborazione delle richieste ed eseguono le stesse attività dei moduli del server nativo. Allo stesso tempo, le API ASP.NET rimangono in gran parte uguali, con alcune aggiunte chiave che sbloccano le funzionalità precedentemente non disponibili.

Fedeltà del runtime

In modalità integrata, le fasi di elaborazione delle richieste ASP.NET esposte ai moduli sono connesse direttamente alle fasi corrispondenti della pipeline IIS. La pipeline completa contiene le fasi seguenti, esposte come eventi HttpApplication in ASP.NET:

1. BeginRequest. L'elaborazione della richiesta inizia.
2. AuthenticationRequest. La richiesta viene autenticata. I moduli di autenticazione IIS e ASP.NET sottoscrivono questa fase per eseguire l'autenticazione.
3. PostAuthenticateRequest.
4. AuthorizeRequest. La richiesta è autorizzata. I moduli di autorizzazione IIS e ASP.NET controllano se l'utente autenticato ha accesso alla risorsa richiesta.
5. PostAuthorizeRequest.
6. ResolveRequestCache. I moduli della cache controllano se la risposta a questa richiesta esiste nella cache e la restituisce anziché procedere con il resto del percorso di esecuzione. Entrambe le funzionalità cache di output ASP.NET e cache di output IIS vengono eseguite.
7. PostResolveRequestCache.
8. MapRequestHandler. Questa fase è interna in ASP.NET e viene usata per determinare il gestore della richiesta.
9. PostMapRequestHandler.
10. AcquireRequestState. Lo stato necessario per l'esecuzione della richiesta viene recuperato. ASP.NET moduli Stato sessione e profilo ottengono i dati.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Tutte le attività prima dell'esecuzione del gestore vengono eseguite.
13. ExecuteRequestHandler. Il gestore della richiesta viene eseguito. Vengono gestite pagine ASPX, pagine ASP, programmi CGI e file statici.
14. PostExecuteRequestHandler
15. ReleaseRequestState. Le modifiche dello stato della richiesta vengono salvate e lo stato viene pulito qui. ASP.NET moduli Stato sessione e profilo usano questa fase per la pulizia.
16. PostReleaseRequestState.
17. UpdateRequestCache. La risposta viene archiviata nella cache per un uso futuro. I moduli cache di output ASP.NET e cache di output IIS vengono eseguiti per salvare la risposta nelle cache.
18. PostUpdateRequestCache.
19. LogRequest. Questa fase registra i risultati della richiesta ed è garantita l'esecuzione anche se si verificano errori.
20. PostLogRequest.
21. EndRequest. Questa fase esegue qualsiasi pulizia finale della richiesta ed è garantita l'esecuzione anche se si verificano errori.

Usando le API ASP.NET familiari, la possibilità di eseguire nelle stesse fasi dei moduli IIS rende le attività accessibili solo in precedenza nei filtri e nelle estensioni ISAPI native ora possibili nel codice gestito.

Ad esempio, è ora possibile scrivere moduli che eseguono le operazioni seguenti:

1. Intercettare la richiesta prima che venga eseguita un'elaborazione, ad esempio riscrivendo GLI URL o eseguendo il filtro di sicurezza.
2. Sostituire le modalità di autenticazione predefinite.
3. Modificare il contenuto della richiesta in ingresso, ad esempio le intestazioni della richiesta.
4. Filtrare le risposte in uscita per tutti i tipi di contenuto.

Per un buon esempio di come estendere IIS con un modulo di autenticazione di ASP.NET personalizzato, vedere Sviluppo di un modulo IIS 7 e versioni successive con .NET .

API ASP.NET espanse

Le API ASP.NET rimangono compatibili con le versioni precedenti, che consentono ai moduli esistenti di funzionare in IIS 7 e versioni successive senza modifiche e di applicare a tutto il contenuto dell'applicazione senza modifiche al codice.

Tuttavia, i moduli scritti per la modalità integrata IIS possono sfruttare alcune API aggiuntive per abilitare scenari di elaborazione delle richieste chiave non disponibili in precedenza.

La nuova raccolta HttpResponse.Headers consente ai moduli di controllare e modificare le intestazioni di risposta generate da altri componenti dell'applicazione. Ad esempio, è possibile modificare l'intestazione Content-Type generata da una pagina ASP per richiedere una finestra di dialogo di download nel browser. La raccolta Cookies nella classe HttpResponse è anche migliorata per consentire la modifica dei cookie generati come parte dell'elaborazione della richiesta, anche se sono stati creati al di fuori di ASP.NET.

L'insieme HttpRequest.Headers è abilitato per la scrittura, che consente ai moduli di modificare le intestazioni della richiesta in ingresso. Usare questa opzione per modificare il comportamento di altri componenti server, ad esempio forzare un'applicazione localizzata a rispondere al client in un linguaggio diverso modificando dinamicamente il valore dell'intestazione Accept-Language.

Infine, l'insieme HttpRequest.ServerVariables è ora scrivibile, che consente di impostare le variabili del server IIS. ASP.NET moduli usano questa funzionalità per modificare i valori forniti da IIS e per creare nuove variabili server visibili ad altri framework applicazione, ad esempio PHP.

Integrazione del runtime

Oltre alle nuove API, la modalità integrata consente alle funzionalità di ASP.NET esistenti di fornire maggiore valore all'applicazione.

Le funzionalità di traccia fornite da ASP.NET, tra cui la classe System.Diagnostics.Trace e la funzionalità di traccia della pagina ASP.NET, ora generano informazioni di traccia nel sistema di traccia IIS. In questo modo le informazioni di traccia generate durante l'elaborazione delle richieste da iis e ASP.NET componenti devono essere inserite in un singolo file di log, semplificando una migliore diagnostica dei problemi del server.

La funzionalità di filtro delle risposte ASP.NET, che consente di modificare le risposte usando un'interfaccia stream prima di passare al client, è stata migliorata per consentire il filtro del contenuto non-ASP.NET. Pertanto, è possibile usare ASP.NET filtro su tutto il contenuto del server o installare in modo selettivo il filtro solo per le richieste al contenuto che si desidera elaborare. Con questa funzionalità, è possibile scrivere funzionalità di filtro che inserisce o censurano determinati contenuti nelle risposte del sito, indipendentemente dal fatto che il contenuto provenga da una pagina ASPX o da un file statico.

Riepilogo

ASP.NET Integrazione in IIS 7 e versioni successive ASP.NET consente agli sviluppatori di creare potenti componenti server con la facilità e la ricchezza di ASP.NET e .NET Framework. Per altre informazioni su come sfruttare ASP.NET modalità integrata per le applicazioni esistenti, vedere Utilizzo della modalità pipeline integrata. Per informazioni su come creare nuovi componenti ASP.NET per estendere il server, vedere Sviluppo di un modulo IIS 7 e versioni successive con .NET.