Condividi tramite

Aggiornamento ASP.NET 1.1 a IIS 7.0 in Windows Vista e Windows Server 2008

  • Articolo

di IIS Team

Introduzione

Per gli sviluppatori di applicazioni ASP.NET che si spostano nel sistema operativo Windows Vista™ o versioni successive di Windows, IIS 7.0 e versioni successive rappresentano un progresso significativo rispetto alle versioni precedenti di IIS. La modalità integrata IIS offre una maggiore sicurezza e nuove possibilità di applicazione, tra gli altri miglioramenti.

La maggior parte degli sviluppatori che passano all'aggiornamento di Windows Vista dal sistema operativo Microsoft Windows® XP a Windows Vista e aggiorna le applicazioni ASP.NET nel processo. Oppure installano in Windows Vista le applicazioni ASP.NET sviluppate in altri sistemi operativi Windows.

Questo documento illustra importanti passaggi di configurazione post-installazione e post-aggiornamento che devono essere eseguiti per consentire alle applicazioni di lavorare sul nuovo sistema operativo. Descrive le modifiche tra la modalità classica e la modalità integrata IIS che influiscono sulle applicazioni ASP.NET e su come risolvere questi problemi noti.

Uno dei miglioramenti significativi di IIS 7.0 e versioni successive è una funzionalità della pipeline integrata che consente alle applicazioni Web di usare una singola pipeline di elaborazione delle richieste da applicazioni di codice gestite o non gestite. Inoltre, il nuovo modello di pipeline riduce il comportamento ridondante risultante da due implementazioni separate della stessa funzionalità.

Ad esempio, nelle versioni precedenti, IIS e ASP.NET implementate pipeline di richieste separate che non condividevano l'accesso ai moduli eventi e gestore. L'autenticazione è stata eseguita in modo indipendente all'interno di ogni pipeline. Nel nuovo modello l'autenticazione può essere eseguita una sola volta per IIS e ASP.NET.

Altri vantaggi di questa integrazione includono:

  • ASP.NET servizi, ad esempio l'autenticazione dei moduli e i ruoli che funzionano con i tipi di contenuto IIS, ad esempio pagine ASP statiche e classiche.
  • Funzionalità IIS che si estende con codice gestito e con moduli di pipeline ASP.NET anziché solo con estensioni ISAPI o CGI.
  • Risoluzione dei problemi semplificata risultante dall'integrazione della traccia degli eventi e della registrazione degli errori.
  • Condivisione della configurazione dell'applicazione tra ASP.NET e IIS.

Questo articolo esamina i problemi di compatibilità per ASP.NET applicazioni che eseguono la migrazione da versioni precedenti di IIS a IIS 7.0 e versioni successive e si concentra in particolare sulle differenze correlate alla transizione dalla modalità classica all'uso della pipeline integrata in modalità integrata.

Per una panoramica completa delle funzionalità e dei vantaggi dell'integrazione di ASP.NET e IIS, vedere l'articolo ASP.NET Integrazione con IIS 7.0 e Versioni successive.

Aggiornamento da versioni precedenti di IIS a Windows Vista

Il grafico che segue mostra la disponibilità di IIS 7.0 nelle versioni disponibili di Windows Vista:

Versione di Windows Vista Disponibilità di IIS 7.0
Home Basic N
Home Premium S
Business S
Ultimate S

ASP.NET scenari di aggiornamento in Windows Vista

La tabella seguente fornisce una breve struttura dei percorsi di aggiornamento supportati per ASP.NET nelle versioni precedenti dei sistemi operativi Windows per ASP.NET in Windows Vista. In caso di problemi, vedere le sezioni che seguono per altre informazioni sulle restrizioni di aggiornamento e sulle limitazioni.

La tabella mostra anche che gli aggiornamenti dalle versioni del sistema operativo server alle versioni del sistema operativo client non sono disponibili. È invece necessario eseguire un'installazione pulita di Vista in un computer con un sistema operativo server attualmente installato.

Sistema operativo Versione IIS Versione di .NET Framework Considerazioni sull'aggiornamento a Windows Vista/IIS 7.0
Windows 2000 Server IIS 5.0 1.0, 1.1, 2.0 L'aggiornamento a Windows Vista non è disponibile.
Windows 2000 Professional IIS 5.0 1.0, 1.1, 2.0 È necessaria l'installazione pulita del sistema operativo.
Windows Server 2003 IIS 6.0 1.0, 1.1, 2.0 L'aggiornamento a Windows Vista non è disponibile.
Windows XP Home Edition N/D 1.0, 1.1, 2.0 Windows XP Home non include IIS. Gli utenti possono decidere di installare IIS 7.0 o versioni successive in Windows Vista.
Windows XP Professional IIS 5,1 1.0 .NET Framework 1.0 non è supportato in Windows Vista. ASP.NET applicazioni 1.0 devono essere aggiornate a almeno ASP.NET 1.1 (ASP.NET 2.0 consigliato).
1,1 La configurazione manuale è necessaria dopo l'aggiornamento (vedere più avanti in questo articolo).
2,0 ASP.NET deve essere selezionato nelle opzioni di configurazione iis seguendo un aggiornamento per consentire la configurazione di ASP.NET 2.0 in modalità integrata.
Windows XP Tablet PC IIS 5,1 1,0 .NET Framework 1.0 non è supportato in Windows Vista. ASP.NET applicazioni 1.0 devono essere aggiornate a almeno ASP.NET 1.1 (ASP.NET 2.0 consigliato).
1,1 La configurazione manuale è necessaria dopo l'aggiornamento (vedere più avanti in questo articolo).
2,0 ASP.NET deve essere selezionato nelle opzioni di configurazione iis seguendo un aggiornamento per consentire la configurazione di ASP.NET 2.0 in modalità integrata.
Windows XP Professional x64 IIS 5,1 1.1, 2.0 È necessaria l'installazione pulita del sistema operativo.

Configurazione dell'applicazione post-installazione

Subito dopo un'installazione o un aggiornamento a Windows Vista, gli utenti devono eseguire passaggi di configurazione aggiuntivi per consentire il funzionamento delle applicazioni. La configurazione post-installazione dipende dalla versione ASP.NET usata da ogni applicazione.

Configurazione di applicazioni ASP.NET 1.1

Prima di installare .NET Framework 1.1 (necessario se si esegue ASP.NET applicazioni 1.1), gli utenti devono eseguire i due passaggi seguenti per abilitare le applicazioni di ASP.NET:

Procedura

Ogni pool di applicazioni IIS che esegue un'applicazione ASP.NET deve essere configurata in modo esplicito usando la versione di .NET Framework corrispondente alla versione di ASP.NET usata per l'applicazione. È possibile eseguire una sola versione di ASP.NET per pool di applicazioni, quindi è necessario usare pool di applicazioni separati per ogni versione ASP.NET.

Nella console di Gestione IIS aprire Pool di applicazioni, quindi fare clic con il pulsante destro del mouse su un pool di applicazioni e selezionare Impostazioni di base. Nella finestra di dialogo Modifica pool di applicazioni visualizzata nella figura 1 selezionare la versione di .NET Framework corrispondente alle applicazioni configurate nel pool di applicazioni, quindi fare clic su OK.

Screenshot della finestra di dialogo Modifica pool di applicazioni con punto N E T Framework selezionato.

Figura 1: Modificare le impostazioni del pool di applicazioni

Uso di ASP.NET 1.1 in modalità classica

ASP.NET 1.1 usa un'estensione ISAPI IIS durante l'esecuzione in modalità classica, ovvero l'impostazione predefinita per ASP.NET seguente installazione o aggiornamento (si noti che ASP.NET 2.0 può essere eseguita anche in modalità integrata in Windows Vista, che non richiede un'estensione ISAPI).

È necessario consentire esplicitamente la versione di ASP.NET usata dalle applicazioni per l'esecuzione usando la configurazione delle restrizioni ISAPI e CGI nella Console di gestione IIS. Aprire Gestione IIS e selezionare Restrizioni ISAPI e CGI. Nella pagina Restrizioni ISAPI e CGI selezionare ogni versione di ASP.NET impostata su Non consentito nella colonna Restrizione e fare clic sul collegamento Consentito sul lato destro della pagina per modificare l'impostazione su Consentito.

La figura 2 mostra un esempio della pagina Restrizioni ISAPI e CGI con la versione dell'assembly Aspnet_isapi.dll usata per ASP.NET 1.1 selezionata. Nella figura l'impostazione per questa estensione ISAPI deve essere modificata da Non consentito a Consentito.

Screenshot della pagina Restrizioni I A P E C G.

Figura 2: Elenco restrizioni ISAPI e CGI

Configurazione delle applicazioni ASP.NET 2.0

.NET Framework 2.0 viene installato durante l'installazione di Windows Vista e pertanto ASP.NET 2.0 è già presente nel server dopo l'installazione. Tuttavia, per completare la configurazione di ASP.NET in Vista per ASP.NET applicazioni 2.0, gli utenti devono eseguire i due passaggi seguenti:

Passaggio 1

Da Gestione pacchetti di Windows Vista (Pannello di controllo\Programmi e funzionalità\Attiva o Disattiva funzionalità di Windows), selezionare ASP.NET come illustrato nella figura 3 e fare clic su OK.

Nota

Quando ASP.NET è già installato nel computer prima di questo passaggio, selezionando ASP.NET in questo modo si garantisce che vengano completati passaggi di configurazione aggiuntivi.

Screenshot del riquadro Funzionalità di Windows con la funzionalità di sviluppo A S P dot Net selezionata nel menu espanso.

Figura 3: Installazione di Windows Vista - Funzionalità di Windows

Passaggio 2

Ogni pool di applicazioni IIS che esegue un'applicazione ASP.NET deve essere configurato in modo esplicito usando la versione di .NET Framework corrispondente alla versione di ASP.NET usata per l'applicazione. È possibile eseguire una sola versione di ASP.NET per ogni pool di applicazioni, pertanto è necessario usare pool di applicazioni separati per ogni versione ASP.NET.

In Gestione IIS aprire Pool di applicazioni, quindi fare clic con il pulsante destro del mouse su un pool di applicazioni e scegliere Impostazioni di base. Nella finestra di dialogo Modifica pool di applicazioni illustrata nella figura 4 selezionare la versione di .NET Framework corrispondente alle applicazioni configurate nel pool di applicazioni e quindi fare clic su OK.

Screenshot della finestra di dialogo Modifica pool di applicazioni con il punto N E T Framework selezionato evidenziato.

Figura 4: Pool di applicazioni & modalità integrata

Impostazioni pool di applicazioni

Quando si aggiornano le applicazioni ASP.NET nelle versioni precedenti dei sistemi operativi Windows a Windows Vista, le applicazioni vengono configurate nei pool di applicazioni in base alle impostazioni di isolamento dell'applicazione IIS come indicato di seguito:

Configurazione dell'isolamento IIS prima dell'aggiornamento Pool di applicazioni IIS Identità del pool di applicazioni IIS
Basso AppPool Low NT AUTHORITY\NETWORK SERVICE
Medio AppPool Medium <nome IWAM_machine>
Alto Le applicazioni vengono configurate in un pool di applicazioni corrispondente al nome dell'applicazione <nome IWAM_machine>

ASP.NET v1.0 non è supportato in Windows Vista

.NET Framework 1.0 non è supportato in Windows Vista e pertanto ASP.NET applicazioni 1.0 devono essere aggiornate ad almeno ASP.NET 1.1. È consigliabile aggiornare le applicazioni ASP.NET 1.0 a ASP.NET 2.0 per sfruttare le migliori prestazioni e le funzionalità di gestibilità disponibili nelle versioni successive di ASP.NET.

Gestori HTTP

In un aggiornamento a IIS 7.0 e versioni successive in Windows Vista, vengono aggiornati solo i gestori HTTP precondizione configurati a livello globale. I gestori configurati a livello di sito non vengono aggiornati.

Supporto side-by-side

È possibile eseguire applicazioni sviluppate in versioni diverse di ASP.NET (ad esempio, 1.1 e 2.0) affiancate in IIS. È necessario configurare le applicazioni in un pool di applicazioni IIS. Questo pool deve essere configurato per la versione di ASP.NET per cui è stata sviluppata l'applicazione. È possibile configurare una sola versione ASP.NET per ogni pool di applicazioni.

.NET Framework 1.1 richiede la configurazione WoW 64 in Windows Vista a 64 bit

ASP.NET non è configurato correttamente se .NET Framework 1.1 è installato nelle versioni a 64 bit di Windows Vista. Dopo aver installato .NET Framework 1.1 nelle versioni a 64 bit di Windows Vista, è necessario configurare manualmente le applicazioni per l'esecuzione con WOW 64 a livello globale usando lo strumento di amministrazione IIS.

Configurazione della modalità pipeline usata da un'applicazione

IIS è configurato per l'uso della nuova modalità integrata per le nuove applicazioni. Questo è il comportamento predefinito. La modalità pipeline viene configurata usando le impostazioni del pool di applicazioni. Modificare queste impostazioni usando una delle opzioni seguenti:

  • Strumento di amministrazione IIS
  • Strumento da riga di comando APPCMD.EXE
  • Modificando il file di configurazione dell'applicazione con un editor di testo

Se si aggiorna un computer esistente a IIS 7.0 o versione successiva, le applicazioni vengono configurate per l'esecuzione in modalità classica per impostazione predefinita. La modalità classica offre compatibilità per le applicazioni con dipendenze specifiche sull'implementazione della pipeline HTTP nelle versioni precedenti di IIS.

Tuttavia, se si importa un'applicazione esistente in un computer che esegue IIS 7.0 e versioni successive e si copia il sito Web, la modalità pipeline usata è determinata dalle impostazioni del pool di applicazioni in cui l'applicazione è configurata per l'esecuzione.

Ad esempio, se si copia l'applicazione nel computer e la si configura per l'esecuzione nel pool di applicazioni predefinito, viene eseguita usando le impostazioni del pool di applicazioni che, per impostazione predefinita, sono configurate in modalità integrata. Per modificare la modalità pipeline per l'applicazione, modificare le impostazioni del pool di applicazioni predefinite o creare un nuovo pool di applicazioni con le impostazioni desiderate.

Per altre informazioni su come configurare un'applicazione esistente per l'uso della modalità integrata, vedere l'articolo integrazione ASP.NET con IIS 7.0 e versioni successive, nella sezione intitolata "Migrazione di applicazioni ASP.NET a IIS 7.0 e versione successiva alla modalità integrata". Vengono fornite istruzioni per modificare le impostazioni di configurazione dell'applicazione.

Compatibilità

ASP.NET moduli pipeline sviluppati in versioni precedenti di IIS e versioni successive configurate per l'uso della modalità integrata con IIS 7.0 e versioni successive possono riscontrare differenze nel comportamento o in altri problemi di compatibilità. Tali problemi sono causati dalle differenze architetturali tra la pipeline nelle versioni precedenti di IIS e la progettazione modulare di IIS 7.0 e versioni successive e dalla pipeline HTTP integrata.

Le sezioni rimanenti di questo articolo descrivono i potenziali problemi di compatibilità che le applicazioni possono riscontrare e includono soluzioni alternative suggerite. Se una soluzione alternativa suggerita non è pratica da implementare, configurare l'applicazione per l'esecuzione in modalità classica per evitare il problema di compatibilità.

Differenze note tra la modalità integrata e la modalità classica

Di seguito è riportato un elenco dei problemi noti tra le due modalità. Leggere attentamente questo elenco.

In modalità integrata, Application_OnError non viene chiamato per le eccezioni che si verificano in HttpApplication::Init

In modalità integrata, le eccezioni che si verificano durante l'inizializzazione di un'applicazione o di un modulo non possono essere intercettate usando l'evento Application.Error.

Inoltre, le applicazioni che usano Server.ClearError per il ripristino da errori non possono cancellare gli errori durante l'inizializzazione dell'applicazione. Ciò impedisce a un'applicazione di ignorare un errore durante l'inizializzazione. Le applicazioni che registrano le informazioni sugli errori per ogni eccezione che si verifica non saranno in grado di registrare gli errori che si verificano durante l'inizializzazione dell'applicazione, anche se questi errori vengono segnalati usando eventi Web e risposte HTTP.

Se un'applicazione richiede l'implementazione di tale gestione delle eccezioni durante l'inizializzazione, deve essere eseguita in modalità classica anziché in modalità integrata.

Server.ClearError in EndRequest non cancella il messaggio di eccezione in modalità integrata

In modalità integrata, la chiamata a Server.ClearError in EndRequest non cancella la risposta dell'eccezione se si è verificata un'eccezione in precedenza nell'elaborazione delle richieste. Le applicazioni che cancellano il messaggio di eccezione in EndRequest non possono rimuovere l'output dell'eccezione dalla risposta.

Se un'applicazione richiede l'implementazione di tale gestione delle eccezioni durante EndRequest, deve essere eseguita in modalità classica anziché in modalità integrata.

Le applicazioni in modalità integrata possono scrivere in una risposta in EndRequest dopo che un'eccezione è stata formattata e scritta nella risposta

In modalità integrata è possibile scrivere in e visualizzare una risposta aggiuntiva scritta dopo che si è verificata un'eccezione.

Questa operazione non si verifica in modalità classica. Se si verifica un errore durante la richiesta e l'applicazione scrive nella risposta in EndRequest dopo che si è verificata l'eccezione, vengono visualizzate le informazioni sulla risposta scritte in EndRequest. Ciò influisce solo sulle richieste che includono eccezioni non gestite.

Per evitare di scrivere nella risposta dopo un'eccezione, un'applicazione deve controllare HttpContext.Error o HttpResponse.StatusCode prima di scrivere nella risposta.

In modalità integrata, ASP.NET non elimina più il tipo di contenuto quando la risposta è vuota

In modalità integrata, ASP.NET gestori generano intestazioni del tipo di contenuto quando vengono impostate in modo esplicito da un modulo, anche se la risposta è vuota. Alcune applicazioni generano un tipo di contenuto per le risposte vuote. Se lo si desidera, modificare le applicazioni per rimuovere in modo esplicito l'intestazione Tipo di contenuto impostandola su NULL.

Identità di Windows diversa nell'autenticazione basata su form

Quando l'autenticazione basata su form viene usata da un'applicazione e l'accesso anonimo è consentita, l'identità in modalità integrata è diversa dall'identità in modalità classica nei modi seguenti:

  • ServerVariables["LOGON_USER"] viene compilato.
  • Request.LogognUserIdentity usa le credenziali dell'account [NT AUTHORITY\NETWORK SERVICE] anziché l'account [NT AUTHORITY\INTERNET USER].

Questo comportamento si verifica perché l'autenticazione viene eseguita in una singola fase in modalità integrata. Viceversa, in modalità classica, l'autenticazione viene eseguita prima con IIS usando l'accesso anonimo e quindi con ASP.NET tramite l'autenticazione basata su form. Di conseguenza, il risultato dell'autenticazione è sempre un singolo utente, ovvero l'utente di autenticazione basata su form. AUTH_USER/LOGON_USER restituisce lo stesso utente perché le credenziali utente di autenticazione basata su form vengono sincronizzate tra IIS e ASP.NET.

Un effetto collaterale è che LOGON_USER, HttpRequest.LogonUserIdentity e la rappresentazione non possono più accedere alle credenziali utente anonime che IIS avrebbe autenticato tramite la modalità classica.

L'evento Authentication_OnAuthenticate predefinito non genera in modalità integrata

In modalità integrata l'evento DefaultAuthenticationModule.Authentication non genera più. In modalità classica questo evento viene generato quando non si è verificata alcuna autenticazione. In modalità integrata, un'applicazione che imposta la modalità di autenticazione=None e sottoscrive l'evento DefaultAuthentication.Authentication riceverà un'eccezione che indica che questa funzionalità non è supportata in modalità integrata. Gli schemi di autenticazione che si basano su questo modello non funzioneranno.

Per risolvere questa modifica, le applicazioni in modalità integrata possono invece sottoscrivere AuthenticationRequest.

In Modalità integrata Request.RawUrl contiene la nuova stringa di query dopo la chiamata di RewritePath

In modalità integrata, dopo che RewritePath viene chiamato in un URL con una nuova stringa di query, la proprietà Request.RawUrl contiene la nuova stringa di query. In modalità classica contiene la stringa di query precedente.

Per risolvere questa modifica, riscrivere l'applicazione in modo che non dipende dal comportamento precedente.

L'autenticazione delle credenziali di rete Passport non è supportata in Windows Vista

Le funzionalità delle credenziali di rete Passport vengono rimosse da Windows Vista e dal sistema operativo Microsoft Windows Server® 2008, pertanto le applicazioni di autenticazione delle credenziali di rete Passport non funzionano per impostazione predefinita in modalità ISAPI o Integrata.

Il modulo PassportAuthentication non fa parte della pipeline integrata

In modalità integrata, il modulo di autenticazione passport ASP.NET viene rimosso dalla pipeline per impostazione predefinita. Se viene usato da un'applicazione, può essere aggiunto nuovamente alla pipeline. Come indicato in precedenza, la funzionalità delle credenziali di rete Passport sottostante viene rimossa da Windows Vista e Microsoft Windows Server 2008, pertanto le applicazioni di autenticazione delle credenziali di rete Passport non funzionano per impostazione predefinita in modalità ISAPI o Integrata.

I ticket di autenticazione di moduli validi di grandi dimensioni (lunghezza <= 4096 byte) presenti nella stringa di query vengono rifiutati da IIS 7.0 e Versioni successive

IIS rifiuta le richieste con ticket di ASP.NET con cookieless di grandi dimensioni, ad esempio quelle usate nell'autenticazione dei moduli, nello stato della sessione e nell'ID anonimo che in totale superano i 4096 byte. Per motivi di sicurezza, questo impedisce gli exploit di overflow del buffer che usano stringhe di query di grandi dimensioni. Le applicazioni che archiviano dati personalizzati o che usano nomi utente molto grandi nei ticket di autenticazione form possono vedere che le richieste vengono rifiutate perché le stringhe di query sono troppo grandi.

Per modificare questo comportamento, modificare le dimensioni massime della stringa di query nella sezione configurazione del filtro delle richieste IIS.

In modalità integrata, il timeout della richiesta di ASP.NET viene applicato più volte durante la richiesta, consentendo all'esecuzione più lunga della richiesta

In modalità integrata, il timeout di esecuzione della richiesta gestita viene reimpostato per ogni nuova transizione nella pipeline. Ciò significa che la richiesta può usare fino a (timeout *(# delle notifiche del modulo), purché qualsiasi timeout singolo non superi il tempo massimo impostato per un timeout.

Le richieste lente potrebbero non essere interrotte o potrebbero richiedere un tempo molto più lungo prima di interrompere, a seconda del numero di moduli ASP.NET e del modo in cui questi moduli vengono uniti insieme. Evitare questo comportamento riducendo il tempo di impostazione per il timeout.

Le impostazioni di traccia non vengono trasferite alla pagina di destinazione Server.Transfer

La modalità integrata non supporta il trasferimento delle impostazioni di traccia alla destinazione di un'operazione Server.Transfer.

Il metodo Httpcontext.Current.Response.Write() non può funzionare in Application_Onstart()

In modalità integrata un'applicazione non può chiamare Http.Current.Response.Write() in un metodo Application_Onstart().

HttpRequest.LogonUserIdentity genera un'eccezione quando si accede prima di PostAuthenticateRequest

In modalità integrata, la proprietà HttpRequest.LogonUserIdentity genererà un'eccezione quando viene eseguito l'accesso prima di PostAuthenticateRequest. Se un modulo accede a questa proprietà prima di PostAuthenticateRequest, viene generata un'eccezione.

Per evitare questo comportamento: non accedere a questa proprietà nell'applicazione; oppure, accedervi dopo il completamento di PostAuthenticateRequest.

In modalità integrata, ASP.NET moduli riceveranno la prima richiesta non autenticata a IIS 7.0 e versioni successive quando l'autenticazione anonima è disabilitata

In modalità integrata, quando viene usato uno schema di autenticazione IIS diverso dall'autenticazione anonima, la prima richiesta dal client che non contiene le credenziali necessarie è visibile per ASP.NET moduli nelle fasi BeginRequest e AuthenticationRequest.

Invece, in modalità classica un'applicazione ASP.NET non visualizzerebbe tale richiesta perché IIS lo rifiuta con una sfida 401 prima di ASP.NET ha la possibilità di elaborarlo.

Ciò significa che i moduli ASP.NET visualizzeranno una richiesta aggiuntiva nelle fasi BeginRequest e AuthenticationRequest. La richiesta viene visualizzata negli eventi Web e in qualsiasi registrazione personalizzata eseguita in BeginRequest o EndRequest.

ASP.NET non può rappresentare l'identità client fino a PostAuthenticateRequest

In modalità integrata, ASP.NET non rappresenta il client fino a quando postAuthenticateEvent se la rappresentazione client è abilitata per un'applicazione usando il Web.config dell'applicazione o in Machine.config.

Inoltre, quando la rappresentazione client è abilitata, i moduli in esecuzione negli eventi BeginRequest e AuthenticationRequest vengono eseguiti con l'identità del processo anziché con l'identità dell'utente autenticata. Questo non deve essere un problema perché i moduli accedono raramente alle risorse in questi eventi, poiché l'utente autenticato non è ancora stato stabilito.

Tuttavia, se questa operazione viene eseguita, l'identità del processo viene usata per accedere alle risorse.

A causa della possibile elevazione dei diritti utente che questa modifica può causare, IIS genera un'eccezione quando la rappresentazione client è abilitata. Ciò indica che l'applicazione deve essere spostata in modalità classica o che questo errore deve essere disattivato se può essere confermato che le risorse sono accessibili negli eventi BeginRequest o AuthenticationRequest.

L'intestazione content-Type non viene generata quando il tipo di contenuto e charset sono impostati su stringa vuota

HTTP.sys non genera più l'intestazione Content-Type quando è impostata in modo esplicito su String.Empty. Le applicazioni i cui client si basano sulla presenza di un'intestazione Di tipo contenuto vuota possono essere interessate da questa modifica.

In modalità integrata, sia gli eventi sincroni che asincroni generano per ogni modulo prima che il modulo successivo venga eseguito

In modalità integrata, sia gli eventi sincroni che asincroni genereranno per ogni modulo, prima che il server si trasferisca al modulo successivo.

Ciò differisce dalla modalità classica in cui tutte le notifiche del modulo asincrone vengono eseguite prima, seguite da tutte le notifiche sincrone. Non è necessario alcun effetto sulle applicazioni a meno che non vi sia una dipendenza dall'ordinamento (vedere "L'ordinamento dei moduli viene invertito per PreSendRequestHeaders e PreSendRequestContent quando si usa la modalità integrata" altrove in questo documento).

Le intestazioni di risposta vengono rimosse in modalità integrata dopo aver chiamato ClearHeader in un oggetto IHttpModule personalizzato

In modalità integrata la chiamata a ClearHeaders non genera automaticamente intestazioni predefinite. Le applicazioni che chiamano ClearHeaders per restituire le intestazioni allo stato predefinito per una pagina con estensione aspx cancellano invece tutte le intestazioni di risposta.

L'uso dell'autenticazione di Windows e Forms insieme in modalità integrata non è supportata

In modalità integrata l'impostazione Impersonate=true e l'uso dell'autenticazione form non è supportata e causa un errore o un comportamento errato.

In modalità integrata, IIS 7.0 e versioni successive rifiuta sempre nuove righe nelle intestazioni di risposta (anche se ASP.NET enableHeaderChecking è impostato su false)

In modalità integrata viene generata un'eccezione quando si tenta di impostare un'intestazione di risposta su un valore contenente \r o \n. In modalità classica questo valore viene codificato per impostazione predefinita e passato tramite se la codifica dell'intestazione viene disattivata. Per motivi di sicurezza, le applicazioni non devono provare a scrivere nuove righe non codificate nei valori di intestazione.

Gli eventi PreSendRequestHeaders e PreSendRequestContent verranno generati insieme per ogni modulo

In modalità integrata, i moduli che sottoscrivono gli eventi PreSendRequestHeaders e PreSendRequestContent vengono notificati insieme per gli eventi PreSendRequestHeaders e PreSendRequestContent.

Ad esempio, un'applicazione può interrompere se il modulo A ha una dipendenza dal modulo B eseguito prima in PreSendRequestHeaders, prima che il modulo A venga eseguito per PreSendRequestContent, ad esempio se il modulo B modifica lo stato della richiesta e il modulo A si basa su di esso.

L'ordinamento dei moduli viene invertito per PreSendRequestHeaders e PreSendRequestContent quando si usa la modalità integrata

In modalità integrata, i moduli che sottoscrivono PreSendRequestHeaders e PreSendRequestContent verranno notificati nell'ordine opposto dell'aspetto nella sezione. Le applicazioni che dispongono di più moduli configurate per l'esecuzione in uno di questi eventi sono interessate da questa modifica se condividono una dipendenza dall'ordinamento degli eventi.

Per risolvere questi problemi, modificare l'ordine dei moduli nella sezione o eseguire l'applicazione in modalità classica.

In modalità integrata, le impostazioni di threading e accodamento in vengono ignorate

In modalità integrata, ASP.NET, non IIS, elabora le richieste nei thread e non usa la semantica di threading o accodamento utilizzata in modalità classica. A causa di questa differenza, le applicazioni possono riscontrare un comportamento di velocità effettiva o di stress diverso in modalità integrata rispetto all'esecuzione in modalità classica.

Se si verifica un errore del file di configurazione quando si usa la modalità integrata, IIS, non ASP.NET, genera il messaggio di errore

Per le applicazioni in esecuzione in modalità integrata, IIS legge ora i file di configurazione dell'applicazione. Pertanto, se il file XML non valido viene trovato nel file Web.config o se nel file sono presenti errori di configurazione, IIS genera sempre un messaggio di errore e non ASP.NET.

Poiché IIS e ASP.NET scrivere errori in formati diversi, il formato del messaggio di errore varia a seconda che l'applicazione venga eseguita in modalità integrata o in modalità classica. Di seguito è riportato un esempio di un tipo di errore del file di configurazione generato da IIS: Errore di configurazione del server interno: file di configurazione non formattato correttamente XML

In modalità integrata, le applicazioni ASP.NET devono sottoscrivere eventi della pipeline durante la chiamata Init di un modulo

ASP.NET applicazioni che usano la pipeline HTTP ASP.NET possono sottoscrivere eventi dell'applicazione all'esterno della pipeline. Tuttavia, ASP.NET applicazioni che usano la pipeline di modalità integrata IIS devono ora sottoscrivere sempre gli eventi durante il metodo Init() del modulo. Nell'esempio seguente viene illustrato come viene implementata una sottoscrizione di eventi in Init:

Public void Init(httpApplication context)
{
    Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}

Per altre informazioni su come creare moduli IIS, vedere l'articolo Sviluppo di un modulo tramite .NET.

Risorse aggiuntive

Per altre informazioni sull'aggiornamento a IIS 7.0 e versioni successive in Windows Vista, vedere l'articolo sulla compatibilità delle applicazioni IIS 7.0 in Windows Vista, Compatibilità e Requisiti delle funzionalità per Windows Vista.