Uma visão geral do Ciclo de Vida do Aplicativo ASP.NET para o IIS 7.0
Este tópico descreve o ciclo de vida do aplicativo para aplicativos ASP.NET que estão sendo executados em IIS 7.0 em modo integrado com o .NET Framework 3,0 ou posterior. IIS 7.0 também oferece suporte a modo clássico, que se comporta como ASP.NET executado no IIS 6.0. Para obter mais informações, consulte Ciclo de Vida do Aplicativo ASP.NET uma visão geral para o IIS 5.0 e 6.0.
O pipeline integrado IIS 7.0 é um pipeline de processamento de solicitações unificado que suporta tanto código nativo como módulos de código gerenciado.Módulos de código gerenciado que implementam a interface IHttpModule tem acesso a todos os enventos do pipeline de solicitações.Por exemplo, um módulo de código gerenciado pode ser usado para formulários de autenticação ASP.NET tanto para páginas Web ASP.NET (arquivos .aspx) como para páginas HTML (arquivos .htm ou .html).Isso é verdadeiro mesmo que páginas HTML são tratadas sistema autônomo recursos estático pelo IIS e ASP.NET.Para obter mais informações sobre o IIS 7.0 Modo integrado, consulte Integração do ASP.NET com o IIS7.
Este tópico contém as seções a seguir:
Visão geral sobre arquitetura
Estágios do Ciclo de Vida
Usando o Arquivo Global.asax
Módulos de Código Gerenciado no IIS7.0
Visão geral sobre arquitetura
Uma solicitação no modo Integrado IIS 7.0 passa por estágios que são semelhantes aos estágios de solicitações para recursos ASP.NET no IIS 6.0.Porém, no IIS 7.0, esses estágios incluem vários outros eventos de aplicativo adicionais, como os eventos MapRequestHandler, LogRequest e PostLogRequest.
A principal diferença entre IIS 7.0 e o IIS 6.0 nos estágios de processamento é o modo como o ASP.NET está integrado com o servidor IIS.No IIS 6.0, existem dois pipelines de processamento de solicitações.Um pipeline é para os filtros e componentes de extensão para código nativo ISAPIOutros tubulação é para componentes do aplicativo de código gerenciado, sistema autônomo ASP.NET.In IIS 7.0, o tempo de execução do ASP.NET é integrado com o servidor Web, o que há em um pipeline de processamento de solicitação unificada para todas as solicitações. Para desenvolvedores ASP.NET, os benefícios do pipeline integrado são os seguintes:
O pipeline integrado dispara todos os eventos que são expostos pelo objeto HttpApplication, que permite que módulos ASP.NET HTTP existentes trabalhem no modo integrado IIS 7.0.
Módulos de código nativo e de código gerenciado podem ser configurados no nível do site da Web, servidor Web ou aplicativo da Web.Isso inclui os módulos de código gerenciado módulos internos do ASP.NET para estado de sessão, a autenticação de formulários, perfis e gerenciamento de funções.Além disso, os módulos de código gerenciado podem ser ativados ou desativados para todas as solicitações, independentemente da solicitação ser para um recurso do ASP.NET, como um arquivo .aspx.
Módulos de código gerenciado podem ser chamados em qualquer estágio no pipeline.Isso inclui o momento antes que qualquer processamento do servidor ocorra para a solicitação, após todo o processamento do servidor ocorreu, ou em qualquer lugar entre eles.
Você pode registrar e ativar ou desativar os módulos por meio do arquivo web.config de um aplicativo da Web.
A ilustração a seguir mostra a configuração do pipeline de solicitação de um aplicativo.O exemplo inclui o seguinte:
O módulo de código nativo Anonymous e o módulo de código gerenciado Forms (que corresponde ao FormsAuthenticationModule.Esses módulos são configurados, e eles são chamados durante o Estágio Authentication da solicitação.
O módulo de código nativo Basic e o módulo de código gerenciado Windows (que corresponde ao WindowsAuthenticationModule.Eles são mostrados, mas não estão configurados para o aplicativo.
O estágio Execute handler, onde o manipulador (um módulo escopo a um URL) é chamado para construir a resposta.Para arquivos .aspx, o manipulador PageHandlerFactory é usado para responder à solicitação.Para arquivos estáticos, o módulo de código nativo StaticFileModule responde à solicitação.
O módulo de código nativo Trace.Isto é mostrado, mas ele não está configurado para o aplicativo.
A classe Custom module de código gerenciado.Ele é chamado durante o estágio Log request.
.png)
Para obter informações sobre questões de compatibilidade conhecido com aplicativos ASP.NET que estejam sendo migrados de versões anteriores do IIS para IIS 7.0, consulte a seção "Conhecidos diferenças entre modo e Classic modo integrado" Atualizando aplicativos ASP.NET para o IIS 7.0: Diferenças entre modo integrado do IIS 7.0 e de modo clássico.
Estágios do Ciclo de Vida
A tabela a seguir lista os estágios do ciclo de vida o aplicativo ASP.NET com modo integrado no IIS 7.0.
Estágio |
Descrição |
|---|---|
Uma solicitação for feita para um recurso de aplicativo. |
O ciclo de vida de um aplicativo ASP.NET inicia com uma solicitação enviada por um navegador para o servidor Web. No modo Clássico no IIS 7.0 e no IIS 6.0, o pipeline de solicitação do ASP.NET é separado do pipeline do servidor Web.Módulos aplicam-se somente a solicitações que são roteadas para a extensão ISAPI do ASP.NET.Se a extensão de nome de arquivo do tipo de recurso solicitado não for explicitamente mapeada para o ASP.NET, a funcionalidade ASP.NET não é invocada para a solicitação porque a solicitação não é processada pelo runtime do ASP.NET. No modo integrado do IIS 7.0, um pipeline unificado trata todas as solicitações.Quando o pipeline integrado recebe uma solicitação, a solicitação passa por etapas que são comuns a todas as solicitações.Esses estágios são representados pela enumeração RequestNotification.Todas as solicitações podem ser configuradas para aproveitar a funcionalidade ASP.NET, porque essa funcionalidade é encapsulada em módulos de código gerenciado que têm acesso ao pipeline de solicitações.Por exemplo, mesmo que a extensão de nome de arquivo .htm não explicitamente está mapeada para o ASP.NET, uma solicitação para uma página HTML ainda chama módulos do ASP.NET.Isso permite que você tirar proveito da autenticação e da autorização ASP.NET para todos os recursos. |
O pipeline unificado recebe a primeira solicitação para o aplicativo. |
Quando o pipeline unificado recebe a solicitação primeira qualquer recurso em um aplicativo, uma instância do ApplicationManager classe é criada, que é que a solicitação é processada no domínio do aplicativo. Domínios de aplicativo fornecem isolamento entre aplicativos para as variáveis global e permitem que cada aplicativo ser descarregado separadamente.Dentro de um domínio de aplicativo, uma instância de uma classe nomeada HostingEnvironment é criada, que proporciona acesso à informação sobre o aplicativo, como o nome da pasta onde ele está armazenado. Durante a primeira solicitação, itens de nível superior do aplicativo são compilados, se necessário, o que inclui o código do aplicativo na pasta App_Code.Você pode incluir manipuladores e módulos personalizados na pasta App_Code conforme descrito posteriormente em módulos de código gerenciado no IIS 7.0 neste tópico. |
Objetos de resposta são criados para cada solicitação. |
Após a criação do domínio do aplicativo e da instanciação do objeto HostingEnvironment, os objetos da aplicação como HttpContext, HttpRequest e HttpResponse são criados e inicializados.A classe HttpContext contém objetos que são específico da solicitação do aplicativo atual, como os objetos HttpRequest e HttpResponse.O objeto HttpRequest contém informações sobre a solicitação atual, que inclui informações sobre o navegador e cookies.O objeto HttpResponse contém a resposta que é enviada para o cliente, que inclui todos os cookies e saída processada. A seguir estão algumas das principais diferenças entre o IIS 6.0 e IIS 7.0 executando no modo integrado e com a .NET Framework 3,0 ou posterior:
|
Um objeto HttpApplication é designado à solicitação. |
Após todos os objetos do aplicativo tiverem sido inicializados, o aplicativo é iniciado com a criação de uma instância da classe HttpApplication.Se o aplicativo tiver um arquivo Global.asax, o ASP.NET, em vez disso, cria uma instância da classe Global.asax que é derivada da classe HttpApplication.Ele usa a classe derivada para representar o aplicativo. .gif "Observação") Observação:
Na primeira vez que um página ou processo ASP.NET é solicitado em um aplicativo, uma nova instância da classe HttpApplication é criada.No entanto, para maximizar o desempenho, instância de HttpApplication podem ser usado para múltiplas solicitações.
Quais módulos do ASP.NET são carregados (como o SessionStateModule) dependem de como o aplicativo herda os módulos de código gerenciado de um aplicativo pai.Ele também depende de quais módulos são configurados na seção de configuração do arquivo web.config do aplicativo.Módulos são adicionados ou removidos do elemento modules do web.config do aplicativo na seção system.webServer.Para obter mais informações, consulte Como: Configurar a seção <sistema.webServer> para IIS 7.0. |
A solicitação é processada pelo pipeline HttpApplication. |
As seguintes tarefas são executadas pela classe HttpApplication enquanto a solicitação está sendo processada.Os eventos são úteis para desenvolvedores de página que desejam executar o código quando os eventos de solicitação chave do pipeline são gerados.Eles também são úteis se você estiver desenvolvendo um módulo personalizado e você desejar que o módulo seja chamado para todas as solicitações para o pipeline.Módulos personalizados implementam a interface IHttpModule.No modo integrado do IIS 7.0, você deve registrar manipuladores de eventos em um módulo do método Init.
|
Usando o Arquivo Global.asax
O arquivo Global.asax é usado tanto no modo integrado no IIS 7.0 como no ASP.NET no IIS 6.0.Para obter mais informações, consulte a seção "Eventos de Ciclo de Vida e o arquivo Global.asax" em Ciclo de Vida do Aplicativo ASP.NET uma visão geral para o IIS 5.0 e 6.0.
Uma diferença é que você pode adicionar manipuladores para os eventos MapRequestHandler, LogRequest e PostLogRequest.Esses eventos são suportados para aplicativos que são executados no modo integrado do IIS 7.0 e com o .NET Framework 3,0 ou posterior.
Você pode fornecer manipuladores de eventos do aplicativo no arquivo Global.asax para adicionar o código que é executado para todas as solicitações que são manipuladas pelo ASP.NET, como solicitações de páginas .aspx e .axd.No entanto, código do manipulador no arquivo Global.asax não é chamado para solicitações para recursos que não sejam do ASP.NET, como arquivos estáticos.Para executar código gerenciado que é executado para todos os recursos, crie um módulo personalizado que implementa a interface IHttpModule.O módulo personalizado será executado para todas as solicitações aos recursos no aplicativo, mesmo se o manipulador de recursos não é um manipulador do ASP.NET.
Módulos de Código Gerenciado no IIS7.0
Os módulos de código gerenciado do ASP.NET que podem ser configurados e carregados no IIS 7.0 incluem o seguinte:
Para configurar os módulos de código gerenciado IIS 7.0 você pode usar um dos seguintes métodos:
Use Gerenciador do IIS. Para obter mais informações, consulte Como: Abra o Gerenciador do IIS.
Use o IIS 7.0 ferramenta de linha de comando (appcmd.exe). Para obter mais informações, consulte IIS 7.0 ferramenta de linha de comando.
Edite o armazenamento IIS 7.0 de configuração baseado em XML.Para obter mais informações, consulte IIS 7.0: IIS 7.0 configuração Store.
Quando um módulo de código gerenciado, como o módulo FormsAuthenticationModule ASP.NET é configurado para carregar na IIS 7.0, ele tem acesso a todos os eventos no pipeline de pedido.Isso significa que todas as solicitações passam pelo módulo de código gerenciado.Para a classe FormsAuthenticationModule, isso significa que o conteúdo estático pode ser protegido usando autenticação de formulários, mesmo que o conteúdo não é tratado por um manipulador do ASP.NET.
Desenvolvendo Módulos de Código Gerenciados Personalizados
O ciclo de vida do aplicativo ASP.NET pode ser estendido com módulos que implementam a interface IHttpModule.Os módulos que implementam a interface IHttpModule são módulos de código gerenciado.O pipeline integrado do ASP.NET e IIS 7.0 também é extensível através de código nativo módulos, que não são abordados neste tópico.Para obter mais informações sobre módulos de código nativo e sobre como configurar módulos em geral, consulte Visão geral de módulo do IIS.
Você pode definir um módulo de código gerenciado como um arquivo de classe na pasta App_Code do aplicativo.Você também pode criar o módulo como um projeto de biblioteca de classes, compilá-lo e adicioná-la à pasta Bin do aplicativo.Depois de criar o módulo personalizado, é necessário registrá-lo com IIS 7.0.Você pode usar um dos métodos descritos para gerenciar módulos de código gerenciado IIS 7.0.Por exemplo, você pode edição da Web. um aplicativo arquivo de configuração para registrar o módulo de código gerenciado para o aplicativo apenas. Para obter um exemplo de registrar um módulo, consulte Passo-a-passo: Criando e Registrando um Módulo HTTP Personalizado.
Se um módulo é definido como uma pasta Bin ou App_Code de um aplicativo e ele é registrado no arquivo web.config do aplicativo, o módulo é invocado apenas para aquele aplicativo.Para registrar o módulo no arquivo web.config do aplicativo, você trabalha com o elemento modules na seção system.webServer.Para obter mais informações, consulte Como: Configurar a seção <sistema.webServer> para IIS 7.0.Alterações feitas usando Gerenciador do IIS ou a ferramenta Appcmd.exe fará alterações no arquivo web.config do aplicativo.
Módulos de código gerenciado também podem ser registrados no modules elemento das IIS 7.0 armazenamento de configuração (o arquivo ApplicationHost.config). Módulos registrados no arquivo ApplicationHost.config têm escopo global, porque eles são registrados para todos os aplicativos da Web hospedados por IIS 7.0. Da mesma forma, módulos de código nativo que são definidos no elemento globalModules do arquivo ApplicationHost.config têm escopo global.Se um módulo global não é necessário para um aplicativo da Web, você pode desativá-lo.
Exemplo
O exemplo a seguir mostra um módulo personalizado que manipula os eventos LogRequest e PostLogRequest.Os manipuladores de eventos são registrados no método Init do 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.
}
}
}
}
}
O exemplo a seguir mostra como registrar o módulo no arquivo web.config do aplicativo.Adicionar a seção de configuração system.webServer dentro da seção configuração.
<system.webServer>
<modules>
<add name="ModuleExample" type="Samples.ModuleExample"/>
</modules>
</system.webServer>
Para obter um exemplo adicional que mostra como criar e registrar um módulo personalizado, consulte Passo-a-passo: Criando e Registrando um Módulo HTTP Personalizado.
Consulte também
Conceitos
Visão Geral do Ciclo de Vida da Página ASP.NET
Visão geral da Compilação do ASP.NET