Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 7.0
Aggiornamento: novembre 2007
In questo argomento viene descritto il ciclo di vita delle applicazioni ASP.NET in esecuzione nella modalità integrata di IIS 7.0 con .NET Framework 3.0 o successivo. IIS 7.0 supporta anche la modalità classica, paragonabile ad ASP.NET eseguito in IIS 6.0. Per ulteriori informazioni, vedere la classe Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0.
La pipeline integrata di IIS 7.0 è una pipeline di elaborazione delle richieste unificata che supporta moduli di codice nativo e gestito. I moduli di codice gestito che implementano l'interfaccia IHttpModule hanno accesso a tutti gli eventi nella pipeline delle richieste. Ad esempio, un modulo di codice gestito può essere utilizzato per l'autenticazione basata su form di ASP.NET sia per le pagine Web (file ASPX) sia per le pagine HTML (file HTM o HTML) di ASP.NET, benché queste ultime vengano trattate come risorse statiche da IIS e ASP.NET. Per ulteriori informazioni sulla modalità integrata di IIS 7.0, vedere ASP.NET Integration with IIS7 (informazioni in lingua inglese).
Di seguito sono elencate le diverse sezioni di questo argomento:
Cenni preliminari sull'architettura
Fasi del ciclo di vita
Utilizzo del file Global.asax
Moduli di codice gestito in IIS 7.0
Cenni preliminari sull'architettura
Una richiesta effettuata nella modalità integrata di IIS 7.0 attraversa diverse fasi analoghe a quelle delle richieste per le risorse ASP.NET in IIS 6.0. In IIS 7.0, tuttavia, queste fasi includono diversi eventi dell'applicazione aggiuntivi, ad esempio gli eventi MapRequestHandler, LogRequest e PostLogRequest.
La differenza principale tra le fasi di elaborazione di IIS 7.0 e di IIS 6.0 riguarda l'integrazione di ASP.NET con il server IIS. In IIS 6.0 esistono due pipeline di elaborazione delle richieste. Una pipeline è destinata ai filtri ISAPI e ai componenti di estensione di codice nativo. La seconda pipeline è destinata ai componenti dell'applicazione di codice gestito, ad esempio ASP.NET. In IIS 7.0, il runtime ASP.NET è integrato con il server Web, in modo tale da avere una pipeline di elaborazione delle richieste unificata per tutte le richieste. Per gli sviluppatori ASP.NET, i vantaggi della pipeline integrata sono i seguenti:
La pipeline integrata genera tutti gli eventi esposti dall'oggetto HttpApplication, il quale consente ai moduli HTTP ASP.NET esistenti di funzionare nella modalità integrata di IIS 7.0.
Sia i moduli di codice nativo che i moduli di codice gestito possono essere configurati a livello di server Web, sito Web o applicazione Web. Sono inclusi i moduli di codice gestito ASP.NET incorporati per lo stato sessione, l'autenticazione basata su form, i profili e la gestione dei ruoli. Inoltre, i moduli di codice gestito possono essere attivati o disattivati per tutte le richieste, indipendentemente dal fatto che la richiesta sia o meno per una risorsa ASP.NET, ad esempio un file ASPX.
I moduli di codice gestito possono essere richiamati in qualsiasi fase nella pipeline, incluso prima dell'elaborazione della richiesta da parte del server, una volta terminata l'elaborazione oppure nelle fasi intermedie.
È possibile registrare e attivare o disattivare i moduli tramite il file Web.config di un'applicazione.
Nell'illustrazione seguente viene mostrata la configurazione della pipeline delle richieste di un'applicazione. Nell'esempio è incluso quanto segue:
Il modulo di codice nativo Anonymous e il modulo di codice gestito Forms, corrispondente a FormsAuthenticationModule. Questi moduli vengono configurati e richiamati durante la fase Authentication della richiesta.
Il modulo di codice nativo Basic e il modulo di codice gestito Windows, corrispondente a WindowsAuthenticationModule. Vengono visualizzati ma non configurati per l'applicazione.
La fase Execute handler, in cui il gestore (un modulo con ambito in un URL) viene richiamato per costruire la risposta. Nel caso dei file ASPX, il gestore PageHandlerFactory viene utilizzato per rispondere alla richiesta. Nel caso dei file statici, è il modulo StaticFileModule di codice nativo a rispondere alla richiesta.
Il modulo di codice nativo Trace. Viene visualizzato ma non configurato per l'applicazione.
La classe di codice gestito Custom module. Viene richiamata durante la fase Log request.
.png)
Per informazioni sui problemi di compatibilità noti con le applicazioni ASP.NET migrate dalle versioni precedenti di IIS a IIS 7.0, vedere la sezione "Known Differences Between Integrated Mode and Classic Mode" di Upgrading ASP.NET Applications to IIS 7.0: Differences between IIS 7.0 Integrated Mode and Classic mode (informazioni in lingua inglese).
Fasi del ciclo di vita
Nella tabella seguente sono elencate le fasi del ciclo di vita delle applicazioni ASP.NET con IIS 7.0 eseguito in modalità integrata.
Fase |
Descrizione |
|---|---|
Viene effettuata una richiesta per una risorsa dell'applicazione. |
Il ciclo di vita di un'applicazione ASP.NET inizia con una richiesta inviata da un browser al server Web. Nella modalità classica di IIS 7.0 e in IIS 6.0, la pipeline delle richieste ASP.NET è separata dalla pipeline del server Web. I moduli vengono applicati unicamente alle richieste indirizzate all'estensione ISAPI ASP.NET. Se per l'estensione di file del tipo di risorsa richiesto non è stato eseguito in modo esplicito il mapping ad ASP.NET, la funzionalità ASP.NET non viene richiamata per la richiesta poiché questa non viene elaborata dal runtime ASP.NET. Nella modalità integrata di IIS 7.0 tutte le richieste vengono gestite da una pipeline unificata. Quando la pipeline integrata riceve una richiesta, questa attraversa diverse fasi comuni a tutte le richieste. Queste fasi sono rappresentate dall'enumerazione RequestNotification. Tutte le richieste possono essere configurate in modo tale da sfruttare la funzionalità ASP.NET, poiché tale funzionalità è incapsulata nei moduli di codice gestito in grado di accedere alla pipeline delle richieste. Ad esempio, anche se l'estensione di file HTM non viene mappata in modo esplicito ad ASP.NET, una richiesta per una pagina HTML richiama comunque moduli ASP.NET. In questo modo è possibile sfruttare l'autenticazione e l'autorizzazione ASP.NET per tutte le risorse. |
La pipeline unificata riceve la prima richiesta per l'applicazione. |
Quando la pipeline unificata riceve la prima richiesta per una risorsa in un'applicazione, viene creata un'istanza della classe ApplicationManager, ovvero il dominio dell'applicazione in cui la richiesta viene elaborata. I domini dell'applicazione forniscono un isolamento tra applicazioni per le variabili globali e consentono di scaricare separatamente ciascuna applicazione. Nel dominio dell'applicazione viene creata un'istanza della classe HostingEnvironment, che consente di accedere alle informazioni sull'applicazione quali ad esempio il nome della cartella in cui questa viene archiviata. Durante la prima richiesta, se necessario, vengono compilati gli elementi di livello superiore nell'applicazione, incluso il codice dell'applicazione nella cartella App_Code. È possibile includere moduli e gestori personalizzati nella cartella App_Code come descritto in Moduli di codice gestito in IIS 7.0 più avanti in questo argomento. |
Vengono creati oggetti risposta per ogni richiesta. |
Una volta creato il dominio dell'applicazione e creata un'istanza dell'oggetto HostingEnvironment, vengono creati e inizializzati oggetti applicazione quali HttpContext, HttpRequest e HttpResponse. La classe HttpContext contiene oggetti specifici per la richiesta corrente dell'applicazione, come gli oggetti HttpRequest e HttpResponse. L'oggetto HttpRequest contiene informazioni relative alla richiesta corrente, inclusi i cookie e le informazioni sul browser. L'oggetto HttpResponse contiene la risposta inviata al client, che include tutti gli output del rendering e i cookie. Di seguito vengono riportate alcune differenze fondamentali tra IIS 6.0 e IIS 7.0 eseguito in modalità integrata e con .NET Framework 3.0 o successivo:
|
Un oggetto HttpApplication viene assegnato alla richiesta. |
Dopo aver inizializzato tutti gli oggetti applicazione, questa viene avviata mediante creazione di un'istanza della classe HttpApplication. Se invece l'applicazione possiede un file Global.asax, ASP.NET crea un'istanza della classe Global.asax derivata dalla classe HttpApplication. Utilizza quindi la classe derivata per rappresentare l'applicazione. .gif "Nota") Nota:
Quando una pagina o un processo ASP.NET vengono richiesti per la prima volta in un'applicazione, viene creata una nuova istanza della classe HttpApplication. Tuttavia, per ottimizzare le prestazioni, si consiglia di riutilizzare le istanze HttpApplication per più richieste.
I moduli ASP.NET caricati, ad esempio SessionStateModule, dipendono dai moduli di codice gestito che l'applicazione eredita da un'applicazione padre. Dipendono anche dai moduli configurati nella sezione di configurazione del file Web.config dell'applicazione. I moduli vengono aggiunti o rimossi nell'elemento modules del file Web.config dell'applicazione, nella sezione system.webServer. Per ulteriori informazioni, vedere la classe Procedura: configurare la sezione <system.webServer> per IIS 7.0. |
La richiesta viene elaborata dalla pipeline HttpApplication. |
Le attività che seguono vengono eseguite dalla classe HttpApplication durante l'elaborazione della richiesta. Gli eventi sono utili per gli sviluppatori di pagine che desiderano eseguire il codice nel momento in cui vengono generati i principali eventi della pipeline delle richieste. Sono anche utili in caso di sviluppo di un modulo personalizzato che deve essere richiamato per tutte le richieste alla pipeline. I moduli personalizzati implementano l'interfaccia IHttpModule. Nella modalità integrata di IIS 7.0, è necessario registrare i gestori eventi nel metodo Init di un modulo.
|
Utilizzo del file Global.asax
Il file Global.asax viene utilizzato in modalità integrata in IIS 7.0 in modo del tutto analogo a come viene utilizzato in ASP.NET in IIS 6.0. Per ulteriori informazioni, vedere la sezione "Eventi del ciclo di vita e file Global.asax" di Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0.
Una differenza consiste nella possibilità di aggiungere gestori per gli eventi MapRequestHandler, LogRequest e PostLogRequest. Questi eventi sono supportati per le applicazioni eseguite nella modalità integrata di IIS 7.0 con .NET Framework 3.0 o successivo.
È possibile fornire gestori eventi dell'applicazione nel file Global.asax per aggiungere codice che viene eseguito per tutte le richieste gestite da ASP.NET, ad esempio le richieste per pagine ASPX e AXD. Tuttavia, il codice del gestore nel file Global.asax non viene chiamato per le richieste per risorse non ASP.NET, ad esempio i file statici. Per eseguire codice gestito per tutte le risorse, creare un modulo personalizzato che implementa l'interfaccia IHttpModule. Il modulo personalizzato verrà eseguito per tutte le richieste alle risorse nell'applicazione, anche se il gestore di risorse non è un gestore ASP.NET.
Moduli di codice gestito in IIS 7.0
Di seguito sono riportati alcuni dei moduli di codice gestito ASP.NET che possono essere configurati e caricati in IIS 7.0:
Per configurare i moduli di codice gestito di IIS 7.0 è possibile utilizzare uno dei metodi seguenti:
Utilizzare Gestione IIS. Per ulteriori informazioni, vedere Procedura: aprire Gestione IIS.
Utilizzare lo strumento della riga di comando di°IIS 7.0 (Appcmd.exe). Per ulteriori informazioni, vedere IIS 7.0 Command-Line Tool (informazioni in lingua inglese).
Modificare l'archivio di configurazione basato su XML di IIS 7.0. Per ulteriori informazioni, vedere IIS 7.0: IIS 7.0 Configuration Store (informazioni in lingua inglese).
Quando un modulo di codice gestito ASP.NET, ad esempio il modulo FormsAuthenticationModule, viene configurato per il caricamento in IIS 7.0 può accedere a tutti gli eventi nella pipeline delle richieste. Ciò significa che tutte le richieste passano attraverso il modulo di codice gestito. Nel caso della classe FormsAuthenticationModule, significa che il contenuto statico può essere protetto tramite l'autenticazione basata su form benché non sia gestito da un gestore ASP.NET.
Sviluppo di moduli di codice gestito personalizzati
Il ciclo di vita delle applicazioni ASP.NET può essere esteso con moduli che implementano l'interfaccia IHttpModule. I moduli che implementano l'interfaccia IHttpModulesono moduli di codice gestito. La pipeline integrata di ASP.NET e IIS 7.0 può essere estesa anche tramite moduli di codice nativo, i quali non vengono trattati in questo argomento. Per ulteriori informazioni sui moduli di codice nativo e in generale sulla configurazione dei moduli, vedere IIS Module Overview (informazioni in lingua inglese).
È possibile definire un modulo di codice gestito come file di classe nella cartella App_Code dell'applicazione. È anche possibile creare il modulo come progetto Libreria di classi, compilarlo e aggiungerlo alla cartella Bin dell'applicazione. Dopo aver creato il modulo personalizzato, è necessario registrarlo con IIS 7.0. Per gestire i moduli di codice gestito di IIS 7.0, è possibile utilizzare uno dei metodi descritti. Ad esempio, è possibile modificare il file Web.config di un'applicazione per registrare il modulo di codice gestito unicamente per quell'applicazione. Per un esempio di registrazione di un modulo, vedere Procedura dettagliata: creazione e registrazione di un modulo HTTP personalizzato.
Se un modulo viene definito nella cartella App_Code o Bin di un'applicazione e registrato nel file Web.config della stessa, verrà richiamato soltanto per l'applicazione in questione. Per registrare il modulo nel file Web.config dell'applicazione, utilizzare l'elemento modules nella sezione system.webServer. Per ulteriori informazioni, vedere la classe Procedura: configurare la sezione <system.webServer> per IIS 7.0. Le modifiche apportate mediante Gestione IIS o lo strumento Appcmd.exe comportano modifiche al file Web.config dell'applicazione.
I moduli di codice gestito possono essere registrati anche nell'elemento modules dell'archivio di configurazione di IIS 7.0, ossia il file ApplicationHost.config. I moduli registrati nel file ApplicationHost.config possiedono un ambito globale dal momento che vengono registrati per tutte le applicazioni Web ospitate da IIS 7.0. Anche i moduli di codice nativo definiti nell'elemento globalModules del file ApplicationHost.config possiedono un ambito globale. Se un modulo globale non è necessario per un'applicazione Web, è possibile disattivarlo.
Esempio
Nell'esempio seguente viene illustrato un modulo personalizzato che gestisce gli eventi LogRequest e PostLogRequest. I gestori eventi vengono registrati nel metodo Init del modulo.
Imports System
Imports System.Data
Imports System.Web
Imports System.Web.Security
Imports System.Web.UI
Imports Microsoft.VisualBasic
' Module that demonstrates one event handler for several events.
Namespace Samples
Public Class ModuleExample
Implements IHttpModule
Public Sub New()
' Constructor
End Sub
Public Sub Init(ByVal app As HttpApplication) Implements IHttpModule.Init
AddHandler app.LogRequest, AddressOf Me.App_Handler
AddHandler app.PostLogRequest, AddressOf Me.App_Handler
End Sub
Public Sub Dispose() Implements IHttpModule.Dispose
End Sub
' One for both the LogRequest and PostLogRequest events.
Public Sub App_Handler(ByVal source As Object, ByVal e As EventArgs)
Dim app As HttpApplication = CType(source, HttpApplication)
Dim context As HttpContext = app.Context
If (context.CurrentNotification = RequestNotification.LogRequest) Then
If Not (context.IsPostNotification) Then
' Put code here that is invoked when the LogRequest event is raised.
Else
' PostLogRequest
' Put code here that runs after the LogRequest event completes.
End If
End If
End Sub
End Class
End Namespace
using System;
using System.Data;
using System.Web;
using System.Web.Security;
using System.Web.UI;
// Module that demonstrates one event handler for several events.
namespace Samples
{
public class ModuleExample : IHttpModule
{
public ModuleExample()
{
// Constructor
}
public void Init(HttpApplication app)
{
app.LogRequest += new EventHandler(App_Handler);
app.PostLogRequest += new EventHandler(App_Handler);
}
public void Dispose()
{
}
// One handler for both the LogRequest and the PostLogRequest events.
public void App_Handler(object source, EventArgs e)
{
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;
if (context.CurrentNotification == RequestNotification.LogRequest)
{
if (!context.IsPostNotification)
{
// Put code here that is invoked when the LogRequest event is raised.
}
else
{
// PostLogRequest
// Put code here that runs after the LogRequest event completes.
}
}
}
}
}
Nell'esempio seguente viene illustrato come registrare il modulo nel file Web.config dell'applicazione. Aggiungere la sezione di configurazione system.webServer all'interno della sezione configurazione.
<system.webServer>
<modules>
<add name="ModuleExample" type="Samples.ModuleExample"/>
</modules>
</system.webServer>
Per un esempio aggiuntivo della creazione e registrazione di un modulo personalizzato, vedere Procedura dettagliata: creazione e registrazione di un modulo HTTP personalizzato.
Vedere anche
Concetti
Cenni preliminari sul ciclo di vita di una pagina ASP.NET
Cenni preliminari sulla compilazione in ASP.NET