Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 7.0
Actualización: noviembre 2007
En este tema se describe el ciclo de vida de aplicación para las aplicaciones ASP.NET que se ejecutan en IIS 7.0 en modo integrado con .NET Framework 3.0 o posterior. IIS 7.0 también admite el modo clásico, que se comporta como ASP.NET cuando se ejecuta en IIS 6.0. Para obtener más información, vea Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y 6.0.
La canalización integrada de IIS 7.0 es una canalización de procesamiento de solicitudes unificada que admite módulos de código nativo y código administrado. Los módulos de código administrado que implementan la interfaz IHttpModule tienen acceso a todos los eventos de la canalización de solicitudes. Por ejemplo, se puede usar un módulo de código administrado para la autenticación de formularios de ASP.NET tanto de páginas web ASP.NET (archivos .aspx) como de páginas HTML (archivos .htm o .html). Esto es así incluso si las páginas HTML se tratan como recursos estáticos en IIS y ASP.NET. Para obtener más información sobre el modo integrado de IIS 7.0, vea Integración de ASP.NET con IIS7.
Este tema contiene las siguientes secciones:
Información general sobre la arquitectura
Fases del ciclo de vida
Utilizar el archivo Global.asax
Módulos de código administrado en IIS 7.0
Información general sobre la arquitectura
Una solicitud en el modo integrado de IIS 7.0 pasa por fases similares a las fases de las solicitudes de los recursos de ASP.NET en IIS 6.0. Sin embargo, en IIS 7.0, estas fases incluyen varios eventos de aplicación adicionales, como los eventos MapRequestHandler, LogRequest y PostLogRequest.
La diferencia principal en las fases de procesamiento entre IIS 7.0 e IIS 6.0 se encuentra en la forma en que ASP.NET se integra con el servidor IIS. En IIS 6.0, existen dos canalizaciones de procesamiento de solicitudes. Una canalización se usa para los componentes de extensión y los filtros ISAPI de código nativo. La otra se usa para los componentes de aplicación de código administrado como ASP.NET. En IIS 7.0, el tiempo de ejecución de ASP.NET se integra con el servidor web, de forma que existe una única canalización de procesamiento de solicitudes unificada para todas las solicitudes. Para los programadores de ASP.NET, las ventajas de la canalización integrada son las siguientes:
La canalización integrada provoca todos los eventos que expone el objeto HttpApplication, que habilita los módulos HTTP de ASP.NET existentes para trabajar en el modo integrado de IIS 7.0.
Tanto los módulos de código nativo como los módulos de código administrado se pueden configurar en el servidor web, en el sitio web o en la aplicación web. Esto incluye los módulos de código administrado integrados de ASP.NET para la administración del estado de sesión, la autenticación de formularios, los perfiles y las funciones. Además, los módulos de código administrado se pueden habilitar o deshabilitar para todas las solicitudes, independientemente de si la solicitud corresponde a un recurso de ASP.NET, como un archivo .aspx.
Los módulos de código administrado se pueden invocar en cualquier fase de la canalización. Por tanto, se pueden invocar antes de que se produzca procesamiento de servidor para la solicitud, después de que este procesamiento se haya producido y en cualquier momento entre ambas acciones.
Los módulos se pueden registrar y habilitar o deshabilitar mediante el archivo Web.config de una aplicación.
La ilustración siguiente muestra la configuración de la canalización de solicitudes de una aplicación. En el ejemplo se incluyen los elementos siguientes:
El módulo de código nativo Anonymous y el módulo de código administrado Forms (que corresponde a FormsAuthenticationModule). Estos módulos se configuran y se invocan durante la fase de Authentication de la solicitud.
El módulo de código nativo Basic y el módulo de código administrado Windows (que corresponde a WindowsAuthenticationModule). Se muestran, pero no se configuran para la aplicación.
La fase Execute handler, donde se invoca el controlador (un módulo en el ámbito de una dirección URL) para construir la respuesta. En los archivos .aspx, el controlador PageHandlerFactory se usa para responder a la solicitud. En los archivos estáticos, el módulo de código nativo StaticFileModule responde a la solicitud.
El módulo de código nativo Trace. Se muestra, pero no se configura para la aplicación.
La clase Custom module de código administrado. Se invoca durante la fase Log request.
.png)
Para obtener información sobre los problemas de compatibilidad conocidos con aplicaciones ASP.NET que se migran de las versiones anteriores de IIS a IIS 7.0, vea la sección sobre diferencias conocidas entre los modos integrado y clásico de Upgrading ASP.NET Applications to IIS 7.0: Differences between IIS 7.0 Integrated Mode and Classic mode.
Fases del ciclo de vida
La tabla siguiente muestra las fases del ciclo de vida de la aplicación ASP.NET con el modo integrado de IIS 7.0.
Fase |
Descripción |
|---|---|
Se realiza una solicitud para un recurso de aplicación. |
El ciclo de vida de una aplicación ASP.NET se inicia con una solicitud enviada por un explorador al servidor web. En el modo clásico de IIS 7.0 y en IIS 6.0, la canalización de solicitudes de ASP.NET es independiente de la canalización del servidor web. Los módulos sólo se aplican a las solicitudes que se enrutan a la extensión ISAPI de ASP.NET. Si la extensión de nombre de archivo del tipo de recurso solicitado no está asignada explícitamente a ASP.NET, no se invoca la funcionalidad de ASP.NET para la solicitud porque el motor en tiempo de ejecución de ASP.NET no es el que procesa la solicitud. En el modo integrado de IIS 7.0, una canalización unificada administra todas las solicitudes. Cuando la canalización integrada recibe una solicitud, ésta pasa por fases comunes a todas las solicitudes. Las fases se representan mediante la enumeración RequestNotification. Todas las solicitudes se pueden configurar para aprovechar la funcionalidad de ASP.NET, ya que esta funcionalidad está encapsulada en los módulos de código administrado que tienen acceso a la canalización de solicitudes. Por ejemplo, aunque la extensión de nombre de archivo .htm no esté asignada explícitamente a ASP.NET, una solicitud para una página HTML aún invoca módulos de ASP.NET. Esto permite aprovechar la autenticación y autorización de ASP.NET para todos los recursos. |
La canalización unificada recibe la primera solicitud para la aplicación. |
Cuando la canalización unificada recibe la primera solicitud para cualquier recurso de una aplicación, se crea una instancia de la clase ApplicationManager, que es el dominio de aplicación donde se procesa la solicitud. Los dominios de aplicación proporcionan aislamiento entre aplicaciones para las variables globales y permiten descargar cada aplicación por separado. En el dominio de aplicación, se crea una instancia de la clase HostingEnvironment, que proporciona acceso a la información sobre la aplicación, como el nombre de la carpeta en la que está almacenada la aplicación. Durante la primera solicitud, si es necesario se compilan los elementos de nivel superior de la aplicación, lo que incluye el código de aplicación de la carpeta App_Code. Puede incluir módulos personalizados y controladores en la carpeta App_Code, tal como se describe en Módulos de código administrado en IIS 7.0 más adelante en este tema. |
Se crean los objetos de respuesta para cada solicitud. |
Una vez creados el dominio de aplicación y una instancia del objeto HostingEnvironment, se crean e inicializan los objetos de aplicación, como HttpContext, HttpRequest y HttpResponse. La clase HttpContext contiene objetos específicos de la solicitud de aplicación actual, como los objetos HttpRequest y HttpResponse. El objeto HttpRequest contiene datos sobre la solicitud actual, entre los que se incluyen las cookies e información del explorador. El objeto HttpResponse contiene la respuesta que se envía al cliente, que incluye todos los resultados representados y las cookies. A continuación se muestran algunas diferencias clave entre IIS 6.0 e IIS 7.0 ejecutándose en modo integrado con .NET Framework 3.0 o posterior:
|
Se asigna un objeto HttpApplication a la solicitud. |
Una vez que se han inicializado todos los objetos de aplicación, ésta se inicia mediante la creación de una instancia de la clase HttpApplication. Si la aplicación tiene un archivo Global.asax, ASP.NET crea en su lugar una instancia de la clase Global.asax que se deriva de la clase HttpApplication. A continuación, usa la clase derivada para representar la aplicación. .gif "Nota") Nota:
La primera vez que se solicita una página o un proceso ASP.NET en una aplicación, se crea una nueva instancia de la clase HttpApplication. Sin embargo, para maximizar el rendimiento, las instancias de HttpApplication se podrían reutilizar para múltiples solicitudes.
Los módulos de ASP.NET que se cargan (como SessionStateModule) dependen de los módulos de código administrado que la aplicación hereda de una aplicación primaria. También dependen de los módulos que se configuran en la sección de configuración del archivo Web.config de la aplicación. Los módulos se agregan o quitan en el elemento modules del archivo Web.config de la aplicación, en la sección system.webServer. Para obtener más información, vea Cómo: Configurar la sección <system.webServer> para IIS 7.0. |
La canalización de HttpApplication procesa la solicitud. |
La clase HttpApplication ejecuta las tareas siguientes mientras se procesa la solicitud. Los eventos son útiles para los programadores de páginas que desean ejecutar código cuando se provocan eventos clave de canalización de solicitudes. También son útiles si se desarrolla un módulo personalizado que se desea invocar para todas las solicitudes a la canalización. Los módulos personalizados implementan la interfaz IHttpModule. En el modo integrado de IIS 7.0, debe registrar los controladores de eventos en el método Init de un módulo.
|
Utilizar el archivo Global.asax
El archivo Global.asax se utiliza en modo integrado en IIS 7.0 del mismo modo que en ASP.NET en IIS 6.0. Para obtener más información, vea la sección "Eventos de ciclo de vida y archivo Global.asax" en Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y 6.0.
Una diferencia es que puede agregar controladores para los eventos MapRequestHandler, LogRequesty PostLogRequest. Estos eventos se admiten para aplicaciones que se ejecutan en el modo integrado de IIS 7.0 con .NET Framework 3.0 o posterior.
Puede proporcionar controladores de eventos de aplicación en el archivo Global.asax para agregar código que se ejecute en todas las solicitudes administradas por ASP.NET, como las solicitudes para páginas .aspx y .axd. Sin embargo, el código del controlador del archivo Global.asax no se llamará en solicitudes para recursos que no son de ASP.NET, como los archivos estáticos. Para ejecutar código administrado que se ejecute en todos los recursos, cree un módulo personalizado que implemente la interfaz IHttpModule. El módulo personalizado se ejecutará en todas las solicitudes a recursos de la aplicación, incluso si el controlador del recurso no es un controlador de ASP.NET.
Módulos de código administrado en IIS 7.0
Entre los módulos de código administrado de ASP.NET que se pueden configurar y en IIS 7.0 se incluyen los siguientes:
Para configurar módulos de código administrado de IIS 7.0, puede usar uno de los métodos siguientes:
Utilice IIS Manager. Para obtener más información, vea Cómo: Abrir el Administrador de IIS.
Use la herramienta de línea de comandos de IIS 7.0 (Appcmd.exe). Para obtener más información, vea IIS 7.0 Command-Line Tool.
Modifique el almacén de configuración basado en XML de IIS 7.0. Para obtener más información, vea IIS 7.0: IIS 7.0 Configuration Store.
Cuando un módulo de código administrado de ASP.NET como el módulo FormsAuthenticationModule se configura para cargarse en IIS 7.0, tiene acceso a todos los eventos de la canalización de solicitudes. Esto significa que todas las solicitudes pasan por el módulo de código administrado. En la clase FormsAuthenticationModule, esto significa que el contenido estático se puede proteger con la autenticación de formularios, aunque el contenido no sea administrado por controlador de ASP.NET.
Desarrollar módulos de código administrado personalizados
El ciclo de vida de la aplicación ASP.NET se puede ampliar con módulos que implementan la interfaz IHttpModule. Los módulos que implementan la interfaz IHttpModule son módulos de código administrado. La canalización integrada de ASP.NET e IIS 7.0 también se puede ampliar a través de módulos de código nativo, que no se tratan en este tema. Para obtener más información sobre los módulos de código del nativo y cómo configurar los módulos en general, vea IIS Module Overview.
Puede definir un módulo de código administrado como un archivo de clase en la carpeta App_Code de la aplicación. También puede crear el módulo como un proyecto de bibliotecas de clases, compilarlo y agregarlo a la carpeta Bin de la aplicación. Después de crear el módulo personalizado, debe registrarlo con IIS 7.0. Puede usar uno de los métodos descritos para administrar módulos de código administrado de IIS 7.0. Por ejemplo, puede modificar el archivo Web.config de una aplicación para registrar el módulo de código administrado sólo para esta aplicación. Para obtener un ejemplo del registro de un módulo, vea Tutorial: Crear y registrar un módulo HTTP personalizado.
Si se define un módulo en las carpetas App_Code o Bin de una aplicación y se registra en el archivo Web.config de la aplicación, el módulo sólo se invoca para esa aplicación. Para registrar el módulo en el archivo Web.config de la aplicación, trabaja con el elemento modules en la sección system.webServer. Para obtener más información, vea Cómo: Configurar la sección <system.webServer> para IIS 7.0. Los cambios realizados con el IIS Manager o la herramienta Appcmd.exe se aplicarán en el archivo Web.config de la aplicación.
Los módulos de código administrado también se pueden registrar en el elemento modules del almacén de configuración de IIS 7.0 (el archivo ApplicationHost.config). Los módulos registrados en el archivo ApplicationHost.config tienen ámbito global ya que se registran para todas las aplicaciones web hospedadas por IIS 7.0. De igual forma, los módulos de código nativo que se definen en el elemento globalModules del archivo ApplicationHost.config tienen ámbito global. Si un módulo global no se necesita para una aplicación web, puede deshabilitarlo.
Ejemplo
En el ejemplo siguiente se muestra un módulo personalizado que administra los eventos LogRequest y PostLogRequest. Los controladores de eventos se registran en el método Init del módulo.
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.
}
}
}
}
}
En el ejemplo siguiente se muestra cómo registrar el módulo en el archivo Web.config de la aplicación. Agregue la sección de configuración system.webServer dentro de la sección configuration.
<system.webServer>
<modules>
<add name="ModuleExample" type="Samples.ModuleExample"/>
</modules>
</system.webServer>
Para obtener un ejemplo adicional que muestra cómo crear y registrar un módulo personalizado, vea Tutorial: Crear y registrar un módulo HTTP personalizado.
Vea también
Conceptos
Información general sobre el ciclo de vida de una página ASP.NET
Información general sobre ASP.NET
Información general sobre la compilación de ASP.NET