Uma visão geral do Ciclo de Vida do Aplicativo ASP.NET para o IIS 7.0

Visual Studio 2010

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 seguintes seções:

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 gera todos os eventos que são expostos pelo objeto HttpApplication , que permite que módulos ASP.NET HTTP existentes trabalhem no modo integrado do IIS7.0.

  • Módulos de código nativo e código gerenciado tanto podem ser configurados no servidor Web , Web site ou nível do aplicativo Web .
    Isso inclui os módulos internos de código gerenciado ASP.NET para estado de sessão, a autenticação de formulários, perfis e gerenciamento de funções. Além disso, módulos de código gerenciado podem ser habilitados ou desabilitados para todos os requests, independentemente da solicitação para o recurso ASP.NET como um arquivo .aspx.

  • Módulos de código gerenciado podem ser chamados em qualquer fase do pipeline .
    Isso inclui antes de qualquer processamento de servidor ocorre para a solicitação , após todos os servidores de processamento ocorreu , ou em qualquer lugar .

  • Você pode registrar e habilitar ou desabilitar módulos através de arquivo de Web.config do aplicativo.

A ilustração a seguir mostra a configuração de pipeline de solicitação do 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 ).
    Estes módulos são configurados, e eles são invocados durante a fase de requisição do Authentication.

  • O módulo de código nativo Basic e o módulo de código gerenciado Windows(quecorresponde ao
    WindowsAuthenticationModule ).
    Eles são mostrados , mas eles não estão configurados para o aplicativo .

  • A fase Execute handler,ondeomanipulador(ummódulo com escopoparaumURL)échamadoparaconstruiràresposta.
    Para arquivos . aspx , o manipulador PageHandlerFactory é usado para responder ao pedido .
    Para arquivos estáticos , o módulo de código nativo StaticFileModule responde à solicitação .

  • O módulo de código nativo Trace .
    Isso é mostrado , mas ele não está configurado para o aplicativo .

  • A classe de código gerenciado Custom module .
    Ele é invocado durante a fase de Log request .

Solicitar pipeline no IIS 7.0

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 .

A tabela a seguir listas os estágios do ciclo de vida do aplicativo ASP.NET com o modo integrado do IIS 7.0 .

Estágio

Descrição

É feita uma solicitação para um recurso do aplicativo .

O ciclo de vida de um aplicativo ASP.NET começa com uma solicitação enviada por um navegador para o servidor Web .

No modo clássico do IIS 7.0 e no IIS 6.0 , o pipeline de solicitação do ASP.NET está separado do pipeline de servidor Web .
Módulos aplicam- se apenas às solicitações que são roteadas para a extensão ISAPI do ASP.NET .
Se a extensão do tipo solicitado recurso não está explicitamente mapeados para ASP.NET, ASP.NET funcionalidade não é invocada para a solicitação porque a solicitação não é processado pela ASP.NET tempo de execução.

No modo integrado do IIS 7.0 , um oleoduto unificado manipula todas as solicitações .
Quando o pipeline integrado recebe uma solicitação , a solicitação passa por fases que são comuns a todas as solicitações .
Estes 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ê aproveite de autenticação do ASP.NET e autorização para todos os recursos .

O pipeline unificado recebe a primeira solicitação para o aplicativo .

Quando o pipeline unificado recebe a primeira solicitação para qualquer recurso em um aplicativo, uma instância da classe ApplicationManager é criada, o que é o domínio de aplicativo que a solicitação é processada. 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 , 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.

Resposta objetos 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íficos para a solicitação do aplicativo atual, como os objetos HttpRequest e HttpResponse. O objeto HttpRequestcontéminformaçõessobreasolicitaçãoatual,queincluiinformações de navegadorecookies. O objeto HttpResponsecontém a resposta que é enviada para o cliente, que inclui toda a saída renderizada e cookies.

A seguir estão algumas das principais diferenças entre o IIS 6.0 e IIS 7.0 executando no modo integrado e com o .NET Framework 3.0 ou posterior :

Um objeto HttpApplication é atribuído à requisição

Depois que todos os objetos do aplicativo tem sido inicializados , o aplicativo é iniciado , criando 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.

Depois ele usa a classe derivada para representar o aplicativo .

ObservaçãoObservação:
A primeira vez que uma página ASP.NET ou processo é solicitado em uma aplicação , uma nova instância da classe HttpApplication é criada.
No entanto, para maximizar o desempenho, instâncias HttpApplication podem ser reutilizadas por múltiplas requisiçõ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.

Também depende de quais módulos são configurados na seção de configuração do Web. config da aplicação .
Módulos são adicionados ou removidos no elemento modules do Web.config do aplicativo na seção system.webServer.
Para mais informações, consulte How to: Configure the <system.webServer> Section for IIS 7.0.

A solicitação é processada pelo pipeline HttpApplication.

As seguintes tarefas são executadas pela classe HttpApplication a solicitação está sendo processada .

Os eventos são úteis para os desenvolvedores de páginas que deseja executar código quando pedido chave pipeline eventos são gerados .
Eles também são úteis se você estiver desenvolvendo um módulo personalizado e você quer o módulo a ser invocado 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.

  1. Valide a solicitação , que examina as informações enviadas pelo navegador e determina se ele contém marcação potencialmente maliciosa .
    Para mais informações, consulte ValidateRequest e Visão geral de scripts maliciosos.

  2. Execute mapeamento de URL, se alguma URL foi configurada na seção UrlMappingsSection do arquivo Seb.config.

  3. Dispara o evento BeginRequest.

  4. Dispara o evento AuthenticateRequest.

  5. Dispara o evento PostAuthenticateRequest.

  6. Dispara o evento AuthorizeRequest.

  7. Dispara o evento PostAuthorizeRequest.

  8. Dispara o evento ResolveRequestCache.

  9. Dispara o evento PostResolveRequestCache.

  10. Crie o evento MapRequestHandler.

    Um manipulador apropriado é selecionado com base na extensão de nome de arquivo do recurso solicitado .
    O identificador pode ser um módulo de código nativo, como o IIS 7.0StaticFileModule ou um módulo de código gerenciado, como a classe PageHandlerFactory (que manipula arquivos .aspx).

  11. Dispara o evento PostMapRequestHandler.

  12. Dispara o evento AcquireRequestState.

  13. Dispara o evento PostAcquireRequestState.

  14. Dispara o evento PreRequestHandlerExecute.

  15. Chamar o método ProcessRequest (ou a versão assíncrona System#Web#IHttpAsyncHandler#BeginProcessRequest(HttpContexto, AsyncCallVoltar, Objeto) de apropriadas classes IHttpHandler para a solicitação.

    Por exemplo , se a solicitação for para uma página , a instância de página atual manipula a solicitação .

  16. Dispara o evento PostRequestHandlerExecute.

  17. Dispara o evento ReleaseRequestState.

  18. Dispara o evento PostReleaseRequestState.

  19. Resposta a filtragem se executar a propriedade Filter()()() estiver definida.

  20. Dispara o evento UpdateRequestCache.

  21. Dispara o evento PostUpdateRequestCache.

  22. Crie o evento LogRequest.

  23. Crie o evento PostLogRequest.

  24. Dispara o evento EndRequest.

  25. Dispara o evento PreSendRequestHeaders.

  26. Dispara o evento PreSendRequestContent.

    ObservaçãoObservação:
    Os eventos MapRequestHandler, LogRequest e PostLogRequest são suportados apenas se o aplicativo é executado no modo integrado do IIS 7.0 e com o .NET Framework 3,0 ou posterior.

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.

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:

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 mais informações, consulte How to: Configure the <system.webServer> Section for 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.

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.

Contribuições da comunidade

ADICIONAR
Mostrar: