atualizar o ASP.NET 1.1 para o IIS 7.0 no Windows Vista e no Windows Server 2008

Equipe do IIS

Introdução

Para desenvolvedores de aplicativos ASP.NET que migram para o sistema operacional Windows Vista™ ou posteriores, o IIS 7.0 e versões superiores representam um avanço significativo em relação às versões anteriores do IIS. O Modo Integrado do IIS oferece maior segurança e novas possibilidades de aplicativos, entre outras melhorias.

A maioria dos desenvolvedores que migram para o Windows Vista fazem upgrade do sistema operacional Microsoft Windows® XP para o Windows Vista e também dos aplicativos ASP.NET no processo. Ou instalam no Windows Vista os aplicativos ASP.NET desenvolvidos em outros sistemas operacionais do Windows.

Este documento detalha as etapas importantes de configuração pós-instalação e pós-upgrade que devem ser executadas para que os aplicativos funcionem no novo sistema operacional. Ele descreve as mudanças entre o Modo Clássico e o Modo Integrado do IIS que afetam os aplicativos ASP.NET e como se pode contornar os problemas conhecidos.

Um dos aprimoramentos significativos no IIS 7.0 e superiores é o recurso de pipeline integrado que permite que os aplicativos Web usem um único pipeline de processamento de solicitações de aplicativos de código gerenciado ou não gerenciado. Além disso, o novo modelo de pipeline reduz o comportamento redundante resultante de duas implementações separadas do mesmo recurso.

Por exemplo, em versões anteriores, o IIS e o ASP.NET implementavam pipelines de solicitação separados, que não compartilhavam o acesso a eventos e módulos do manipulador. A autenticação era realizada independentemente dentro de cada pipeline. No novo modelo, a autenticação pode ser feita uma única vez para IIS e para ASP.NET.

Outros benefícios dessa integração incluem:

• Serviços ASP.NET, como Autenticação do Forms e Funções que trabalham com tipos de conteúdo do IIS, por exemplo, páginas ASP estáticas e clássicas.
• Funcionalidade estendidas do IIS com código gerenciado e com módulos ASP.NET de pipeline, em vez de apenas com extensões ISAPI ou CGI.
• Solução de problemas simplificada resultante da integração do rastreamento de eventos e do log de erros.
• Compartilhamento da configuração do aplicativo entre o ASP.NET e o IIS.

Este artigo examina os problemas de compatibilidade dos aplicativos ASP.NET que migram de versões anteriores do IIS para o IIS 7.0 e superiores e foca especificamente as diferenças relacionadas à transição do Modo Clássico para o uso do pipeline integrado no Modo Integrado.

Para obter uma visão geral completa dos recursos e benefícios da integração do ASP.NET e do IIS, consulte o artigo Integração do ASP.NET com o IIS 7.0 e superiores.

Upgrade de versões anteriores do IIS para o Windows Vista

O gráfico a seguir mostra a disponibilidade do IIS 7.0 para as versões do Windows Vista:

Versão do Windows Vista	Disponibilidade do IIS 7.0
Home Basic	N
Home Premium	Y
Negócios	Y
Ultimate	Y

Cenários de upgrade do ASP.NET para o Windows Vista

A tabela a seguir fornece uma breve descrição dos caminhos de upgrade suportados para ASP.NET em versões anteriores dos sistemas operacionais Windows para ASP.NET no Windows Vista. Nos pontos em que problemas são observados, consulte as seções a seguir para obter informações sobre restrições e limitações de upgrade.

A tabela também mostra que os upgrades das versões do sistema operacional do servidor para as versões do sistema operacional cliente não estão disponíveis. Nesse caso, você deve executar uma instalação limpa do Vista em um computador com um sistema operacional de servidor já instalado.

Sistema operacional	Versão do IIS	Versão do .NET Framework	Considerações ao fazer upgrade para o Windows Vista/IIS 7.0
Windows 2000 Server	IIS 5.0	1.0, 1.1, 2.0	O upgrade para o Windows Vista não está disponível.
Windows 2000 Professional	IIS 5.0	1.0, 1.1, 2.0	É obrigatório fazer uma instalação limpa do sistema operacional.
Windows Server 2003	IIS 6,0	1.0, 1.1, 2.0	O upgrade para o Windows Vista não está disponível.
Windows XP Home	N/D	1.0, 1.1, 2.0	O Windows XP Home não incluía o IIS. Os usuários podem instalar o IIS 7.0 ou superiores no Windows Vista.
Windows XP Professional	IIS 5.1	1.0	O .NET Framework 1.0 não é compatível com o Windows Server 2012. O upgrade dos aplicativos ASP.NET 1.0 devem ser feito para no mínimo o ASP.NET 1.1 (recomenda-se ASP.NET 2.0).
1,1	Após o upgrade, é preciso fazer a configuração manual (consulte mais adiante neste artigo).
2,0	Também é obrigatório selecionar o ASP.NET nas opções de instalação do IIS para que o ASP.NET 2.0 seja configurado no Modo Integrado.
Tablet e computador com Windows XP	IIS 5.1	1.0	O .NET Framework 1.0 não é compatível com o Windows Server 2012. O upgrade dos aplicativos ASP.NET 1.0 devem ser feito para no mínimo o ASP.NET 1.1 (recomenda-se ASP.NET 2.0).
1,1	Após o upgrade, é preciso fazer a configuração manual (consulte mais adiante neste artigo).
2,0	Também é obrigatório selecionar o ASP.NET nas opções de instalação do IIS para que o ASP.NET 2.0 seja configurado no Modo Integrado.
Windows XP Professional x64	IIS 5.1	1.1, 2.0	É obrigatório fazer uma instalação limpa do sistema operacional.

Configuração do aplicativo pós-instalação

Imediatamente após uma instalação ou upgrade para o Windows Vista, os usuários devem executar etapas adicionais de configuração para que os aplicativos funcionem. A configuração pós-instalação depende da versão do ASP.NET que cada aplicativo usa.

Configuração de aplicativos ASP.NET 1.1

Antes de instalar o .NET Framework 1.1 (obrigatório se estiver executando aplicativos ASP.NET 1.1), os usuários devem executar as duas etapas a seguir para habilitar os aplicativos ASP.NET:

Procedimento

Cada pool de aplicativos do IIS que executa um aplicativo ASP.NET deve ser explicitamente configurado usando a versão do .NET Framework que corresponde à versão do ASP.NET usada para o aplicativo. É possível executar somente uma versão do ASP.NET por pool de aplicativos, portanto, você deve usar pools de aplicativos separados para cada versão ASP.NET.

No console do Gerenciador do IIS, abra Pools de Aplicativos, clique com o botão direito do mouse em um pool de aplicativos e selecione Configurações Básicas. Na caixa de diálogo Editar Pool de Aplicativos mostrada na Figura 1, selecione a versão do .NET Framework que corresponde aos aplicativos configurados no pool de aplicativos e clique em OK.

Figura 1: Edição das configurações do pool de aplicativos

Uso do ASP.NET 1.1 no Modo Clássico

O ASP.NET 1.1 usa uma extensão ISAPI do IIS ao ser executado no Modo Clássico, que é a configuração padrão para as instalações ou upgrades a seguir do ASP.NET (observe que o ASP.NET 2.0 também pode ser executado no Modo Integrado no Windows Vista, que não requer uma extensão ISAPI).

No Console de Gerenciamento do IIS, você deve permitir explicitamente que a versão do ASP.NET usada por seus aplicativos seja executada usando a configuração de Restrições ISAPI e CGI. Abra o Gerenciador do IIS e selecione Restrições ISAPI e CGI. Na página Restrições ISAPI e CGI, selecione cada versão do ASP.NET definida como Não Permitido na coluna Restrição e clique no link Permitido no lado direito da página para alterar a configuração.

A Figura 2 mostra um exemplo da página Restrições ISAPI e CGI com a versão selecionada do assembly Aspnet_isapi.dll usada para ASP.NET 1.1. Na figura, a configuração dessa extensão ISAPI deve ser alterada de Não Permitido para Permitido.

Figura 2: Lista de Restrições ISAPI e CGI

Configuração de aplicativos ASP.NET 2.0

O .NET Framework 2.0 é instalado durante a instalação do Windows Vista, portanto, o ASP.NET 2.0 já está presente no servidor. No entanto, para concluir a configuração do ASP.NET no Vista para aplicativos ASP.NET 2.0, os usuários devem executar as duas etapas a seguir:

Etapa 1

No Gerenciador de Pacotes do Windows Vista (Painel de Controle\Programas e Recursos\Ativar ou Desativar Recursos do Windows), selecione ASP.NET como mostrado na Figura 3 e clique em OK.

Observação

Se o ASP.NET já estiver instalado no computador antes desta etapa, se você selecionar o ASP.NET dessa maneira, garantirá que as etapas de configuração adicionais serão concluídas.

Figura 3: Instalação do Windows Vista - Recursos do Windows

Etapa 2

Cada pool de aplicativos do IIS que executa um aplicativo ASP.NET deve ser explicitamente configurado usando a versão do .NET Framework que corresponde à versão do ASP.NET usada para o aplicativo. É possível executar somente uma versão do ASP.NET por pool de aplicativos, portanto, você deve usar pools de aplicativos separados para cada versão ASP.NET.

No Gerenciador do IIS, abra Pools de Aplicativos, clique com o botão direito do mouse em Pool de Aplicativos e selecione Configurações Básicas. Na caixa de diálogo Editar Pool de Aplicativos mostrada na Figura 4, selecione a versão do .NET Framework que corresponde aos aplicativos configurados no pool de aplicativos e clique em OK.

Figura 4: Pool de aplicativos e Modo Integrado

Configurações do Pool de Aplicativos

Ao fazer upgrade de aplicativos ASP.NET sobre versões anteriores dos sistemas operacionais Windows para o Windows Vista, os aplicativos são configurados nos pools de aplicativos com base nas configurações de isolamento de aplicativos do IIS da seguinte maneira:

Configuração do Isolamento do IIS antes do upgrade	Pool de Aplicativos do IIS	Identidade do Pool de Aplicativos do IIS
Baixo	AppPool Baixo	NT AUTHORITY\NETWORK SERVICE
Médio	AppPool Médio	Nome do IWAM_<machine>
Alto	Os aplicativos são configurados em um Pool de Aplicativos correspondente ao nome do aplicativo	Nome do IWAM_<machine>

O ASP.NET v1.0 não é suportado no Windows Vista

O .NET Framework 1.0 não é suportado no Windows Vista e, portanto, os aplicativos ASP.NET 1.0 devem ser atualizados para no mínimo o ASP.NET 1.1. Recomenda-se fortemente você faça upgrade de software dos seus aplicativos ASP.NET 1.0 para ASP.NET 2.0 para usufruir dos melhores recursos de desempenho e de facilidade de manutenção encontrados nas versões posteriores do ASP.NET.

Manipuladores HTTP

Em um upgrade para o IIS 7.0 e superiores no Windows Vista, somente manipuladores HTTP pré-condicionados configurados no nível global são atualizados. Os manipuladores configurados no nível do site não são atualizados.

Suporte lado a lado

Você pode executar aplicativos desenvolvidos em diferentes versões do ASP.NET (por exemplo, 1.1 e 2.0) lado a lado no IIS. Você precisa configurar os aplicativos em um pool de aplicativos do IIS. Esse pool deve ser configurado para a versão do ASP.NET na qual o aplicativo foi desenvolvido. Você pode configurar somente uma única versão do ASP.NET por pool de aplicativos.

O .NET Framework 1.1 requer configuração WoW 64 no Windows Vista de 64 bits

Se o .NET Framework 1.1 estiver instalado em versões de 64 bits do Windows Vista, o ASP.NET não será configurado corretamente. Depois de instalar o .NET Framework 1.1 em versões de 64 bits do Windows Vista, utilizando a ferramenta de administração do IIS, você deve configurar manualmente os aplicativos para serem executados usando o WOW 64 no nível global.

Configuração do Modo Pipeline usado por um aplicativo

Para os novos aplicativos, o IIS é configurado para usar o novo Modo Integrado. Esse é o comportamento padrão. O Modo Pipeline é definido usando as configurações do pool de aplicativos. Altere essas configurações usando uma destas opções:

• Ferramenta de administração do IIS
• Ferramenta de linha de comando APPCMD.EXE
• Editando o arquivo de configuração do aplicativo com um editor de texto

Se você estiver fazendo upgrade de um computador para o IIS 7.0 ou superiores, por padrão, os aplicativos serão configurados para executarem no Modo Clássico. O Modo Clássico oferece compatibilidade para aplicativos que têm dependências específicas na implementação do pipeline HTTP em versões anteriores do IIS.

No entanto, se você importar um aplicativo existente para um computador executando o IIS 7.0 e superiores e copiar o site, o Modo Pipeline usado será determinado pelas configurações do pool de aplicativos no qual o aplicativo está configurado para ser executado.

Por exemplo, se você copiar o aplicativo para o computador e configurá-lo para executar no Pool de Aplicativos Padrão, ele executará usando as configurações desse pool de aplicativos que, por padrão, está definido para o Modo Integrado. Para alterar o Modo Pipeline do aplicativo, altere as configurações do Pool de Aplicativos Padrão ou crie um novo pool de aplicativos com as configurações desejadas.

Leia mais sobre como configurar um aplicativo existente para usar o Modo Integrado no artigo Integração do ASP.NET com o IIS 7.0 e superiores, na seção "Migração de aplicativos ASP.NET para o Modo Integrado do IIS 7.0 e superiores". Ele fornece instruções para alterar as definições de configuração do aplicativo.

Compatibilidade

Os módulos Pipeline do ASP.NET, desenvolvidos para versões anteriores do IIS e configurados posteriormente para usar o Modo Integrado com o IIS 7.0 e superiores, podem apresentar diferenças de comportamento ou outros problemas de compatibilidade. Esses problemas são causados pelas diferenças de arquitetura entre o pipeline em versões anteriores do IIS (e o design modular do IIS 7.0 e superiores) e o pipeline HTTP integrado.

As seções restantes deste artigo descrevem possíveis problemas de compatibilidade que os aplicativos podem apresentar e incluem sugestões de soluções alternativas. Se a solução alternativa sugerida não for viável, configure o aplicativo para ser executado no Modo Clássico para evitar o problema de compatibilidade.

Diferenças conhecidas entre o Modo Integrado e o Modo Clássico

Veja a seguir a lista de problemas conhecidos entre os dois modos. Analise a lista com atenção.

No Modo Integrado, o Application_OnError não é chamado nas exceções que ocorrem em HttpApplication::Init

No Modo Integrado, as exceções que ocorrem durante a inicialização do aplicativo ou módulo não podem ser interceptadas usando o evento Application.Error.

Além disso, os aplicativos que usam Server.ClearError para se recuperarem depois da ocorrência de erros não conseguem limpar esses erros durante a inicialização do aplicativo. Isso ocorre para evitar que o aplicativo ignore os erros durante a inicialização. Os aplicativos que registram informações de erro a cada exceção que ocorre não conseguirão registrar os erros que ocorrerem durante a inicialização do aplicativo, embora eles sejam relatados usando eventos da Web e respostas HTTP.

Se o aplicativo precisar da implementação desse tratamento de exceção durante a inicialização, ele deverá ser executado no Modo Clássico em vez de no Modo Integrado.

O Server.ClearError no EndRequest não limpa mensagens de exceção no Modo Integrado

No Modo Integrado, se uma exceção ocorrer no início do processamento da solicitação, chamar o Server.ClearError no EndRequest não limpa a resposta de exceção. Os aplicativos que limpam mensagens de exceção no EndRequest não conseguem remover a saída da exceção na resposta.

Se o aplicativo precisar da implementação desse tratamento de exceção durante o EndRequest, ele deverá ser executado no Modo Clássico em vez de no Modo Integrado.

Depois que uma exceção tiver sido formatada e gravada na resposta, os aplicativos no Modo Integrado conseguem escrever na resposta no EndRequest

No Modo Integrado, é possível alterar e exibir uma resposta adicional que foi gravada após a ocorrência de uma exceção.

Isso não ocorre no Modo Clássico. Se ocorrer um erro durante a solicitação e o aplicativo escrever na resposta no EndRequest após a exceção ter ocorrido, serão exibidas as informações da resposta gravadas no EndRequest. Isso afeta apenas as solicitações que incluem exceções sem tratamento.

Para evitar gravar na resposta após uma exceção, o aplicativo deve verificar o HttpContext.Error ou o HttpResponse.StatusCode antes de escrever na resposta.

No Modo Integrado, o ASP.NET não suprime mais o tipo de conteúdo quando a resposta está vazia

Nesse modo, os manipuladores do ASP.NET geram cabeçalhos de Tipo de Conteúdo quando são explicitamente definidos por um módulo, mesmo que a resposta esteja vazia. Alguns aplicativos geram um tipo de conteúdo para respostas vazias. Se quiser que os aplicativos removam explicitamente o cabeçalho do Tipo de Conteúdo, defina-o como NULL.

Identidade diferente do Windows na autenticação do Forms

Quando a Autenticação do Forms é usada por um aplicativo e o acesso anônimo é permitido, a identidade do Modo Integrado difere da identidade do Modo Clássico da seguinte forma:

• O ServerVariables["LOGON_USER"] fica preenchido.
• O Request.LogognUserIdentity usa as credenciais da conta [NT AUTHORITY\NETWORK SERVICE] em vez da conta [NT AUTHORITY\INTERNET USER].

Esse comportamento ocorre porque a autenticação é executada em um único estágio no Modo Integrado. Por outro lado, no Modo Clássico, a autenticação ocorre primeiro com o IIS usando acesso anônimo e, depois, com o ASP.NET usando a autenticação do Forms. Assim, o resultado da autenticação é sempre um único usuário: o usuário da autenticação do Forms. O AUTH_USER/LOGON_USER retorna esse mesmo usuário porque as credenciais de usuário da autenticação do Forms são sincronizadas entre o IIS e o ASP.NET.

Um efeito colateral é que o LOGON_USER, o HttpRequest.LogonUserIdentity e a representação não podem mais acessar as credenciais do usuário anônimo que o IIS teria autenticado usando o Modo Clássico.

O evento Authentication_OnAuthenticate padrão não é gerado no Modo Integrado

Nesse modo, o evento DefaultAuthenticationModule.Authenticate não é mais gerado. No Modo Clássico, esse evento é gerado quando nenhuma autenticação ocorreu. No Modo Integrado, um aplicativo que definir o modo de autenticação como Nenhum e assinar o evento DefaultAuthentication.Authenticate receberá uma exceção indicando que esse recurso não é suportado no Modo Integrado. Os esquemas de autenticação que dependem desse padrão não funcionarão.

Para contornar essa alteração, os aplicativos no Modo Integrado podem assinar o AuthenticateRequest.

No Modo integrado, o Request.RawUrl conterá a nova cadeia de caracteres de consulta depois que o RewritePath for chamado

Nesse modo, depois que o RewritePath for chamado em uma URL com uma nova cadeia de caracteres de consulta, a propriedade Request.RawUrl conterá a nova cadeia de caracteres de consulta. No Modo Clássico, ele conterá a cadeia de caracteres antiga de consulta.

Para contornar essa alteração, reescreva o aplicativo para que ele não dependa do comportamento antigo.

Não há suporte para autenticação de credenciais de rede do Passport no Windows Vista

A funcionalidade de credenciais de rede do Passport foi removida do Windows Vista e do sistema operacional Microsoft Windows Server® 2008, portanto, os aplicativos de autenticação de credenciais de rede do Passport não funcionam por padrão no Modo Integrado ou ISAPI.

O módulo PassportAuthentication não faz parte do Pipeline integrado

No Modo Integrado, por padrão, o Módulo de Autenticação do ASP.NET Passport é removido do pipeline. Se for usado por um aplicativo, ele poderá ser adicionado novamente ao pipeline. Conforme indicado acima, a funcionalidade de credenciais de rede do Passport foi removida do Windows Vista e do sistema operacional Microsoft Windows Server® 2008, portanto, os aplicativos de autenticação de credenciais de rede do Passport não funcionam por padrão no Modo Integrado ou ISAPI.

Tíquetes de autenticação de formulários grandes e válidos (comprimento <= 4096 bytes) presentes na cadeia de caracteres de consulta serão rejeitados pelo IIS 7.0 e versões superiores

O IIS rejeita solicitações com tíquetes grandes do ASP.NET sem cookie, como aqueles usados na autenticação do Forms, no estado de sessão e na ID anônima que, no total, excedem 4.096 bytes. Por motivos de segurança, isso evita utilização de estouros de buffer que usam grandes cadeias de caracteres de consulta. Os aplicativos que armazenam dados personalizados ou usam nomes de usuário muito grandes em tíquetes de autenticação do Forms podem observar que as solicitações são rejeitadas porque as cadeias de caracteres de consulta são muito grandes.

Para alterar esse comportamento, na seção de configuração de filtragem de solicitações do IIS, ajuste o tamanho máximo da cadeia de caracteres de consulta.

No Modo Integrado, o tempo limite de solicitações ASP.NET é aplicado várias vezes durante a solicitação, permitindo que ela seja executada por mais tempo

Nesse modo, o tempo limite gerenciado de execução de solicitações é redefinido para cada nova transição no pipeline. Isso significa que a solicitação pode usar até (tempo limite *(número de notificações do módulo)), desde que qualquer tempo limite único não exceda o tempo máximo definido para o tempo limite.

Solicitações lentas podem não ser abortadas ou levar um tempo consideravelmente maior antes de serem abortadas, dependendo do número de módulos ASP.NET e de quão bem esses módulos são mesclados. Para evitar esse comportamento, reduza a configuração de duração do tempo limite.

As configurações de rastreamento não são transferidas para a página de destino Server.Transfer

O Modo Integrado não suporta a transferência das configurações de rastreamento para o destino de uma operação Server.Transfer.

O método Httpcontext.Current.Response.Write() não funciona no Application_Onstart()

No Modo Integrado, o aplicativo não pode chamar o Http.Current.Response.Write() em um método Application_Onstart().

HttpRequest.LogonUserIdentity lança uma exceção quando é acessada antes do PostAuthenticateRequest

No Modo Integrado, a propriedade HttpRequest.LogonUserIdentity lançará uma exceção quando for acessada antes do PostAuthenticateRequest. Se um módulo acessar essa propriedade antes do PostAuthenticateRequest, uma exceção será lançada.

Para evitar esse comportamento, não acesse essa propriedade no aplicativo ou acesse-a após a conclusão do PostAuthenticateRequest.

No Modo Integrado, os módulos ASP.NET receberão a primeira solicitação não autenticada para o IIS 7.0 e superiores quando a Autenticação anônima estiver desabilitada

Nesse modo, quando um esquema de autenticação do IIS, diferente da Autenticação anônima é usado, a primeira solicitação do cliente que não contém as credenciais necessárias fica visível para os módulos ASP.NET nos estágios BeginRequest e AuthenticateRequest.

Já no Modo Clássico, o aplicativo ASP.NET não veria essa solicitação porque o IIS a rejeitaria com uma mensagem 401 antes que o ASP.NET consiga processá-la.

Isso significa que os módulos ASP.NET verão uma solicitação adicional nos estágios BeginRequest e AuthenticateRequest. A solicitação aparecerá em eventos da Web e em todos os logs personalizados no BeginRequest ou no EndRequest.

O ASP.NET não consegue representar a identidade do cliente até o PostAuthenticateRequest

No Modo Integrado, o ASP.NET não representará o cliente até o PostAuthenticateEvent se a representação do cliente estiver habilitada para o aplicativo que usa o Web.config ou o Machine.config.

Além disso, quando a representação do cliente estiver habilitada, os módulos em execução nos eventos BeginRequest e AuthenticateRequest serão executados com a identidade de processo em vez de com a identidade do usuário autenticado. Isso não deve ser um problema porque os módulos raramente acessam recursos nesses eventos, pois o usuário autenticado ainda não foi estabelecido.

No entanto, se isso for feito, a identidade de processo será usada para acessar os recursos.

Devido à possível elevação dos direitos do usuário que essa alteração pode causar, o IIS lança uma exceção quando a representação de cliente está habilitada. Isso indica que o aplicativo deve ser movido para o Modo Clássico ou que esse erro deve ser desativado, se for possível confirmar que os recursos estão sendo acessados nos eventos BeginRequest ou AuthenticateRequest.

O cabeçalho Content-Type não é gerado quando o conjunto de caracteres e o tipo de conteúdo são definidos como uma cadeia de caracteres vazia

O HTTP.sys não gera mais o cabeçalho Content-Type quando ele é explicitamente definido como String.Empty. Os aplicativos cujos clientes precisam do cabeçalho Content-Type vazio podem ser afetados por essa alteração.

No Modo Integrado, os eventos síncronos e também os assíncronos são gerados para cada módulo antes da execução do próximo módulo

Nesse modo, os eventos síncronos e também os assíncronos serão gerados para cada módulo antes que o servidor avance para o próximo módulo.

Já no Modo Clássico, todas as notificações assíncronas de módulo são executadas primeiro, seguidas por todas as notificações síncronas. Isso não afeta os aplicativos, a menos que haja uma dependência da ordem (consulte nesse documento: "A ordem dos módulos é revertida para PreSendRequestHeaders e PreSendRequestContent ao usar o Modo Integrado").

Os cabeçalhos das respostas são removidos no Modo Integrado depois que o ClearHeader é chamado em um IHttpModule personalizado

No Modo Integrado, a ação de chamar o ClearHeaders não gera automaticamente cabeçalhos padrão. Os aplicativos que chamam o ClearHeaders para retornar os cabeçalhos ao estado padrão de uma página .aspx devem limpar todos os cabeçalhos das respostas.

Não use a autenticação do Windows e do Forms juntos no Modo Integrado

No Modo Integrado, a configuração Impersonate=true e o uso da autenticação do Forms não são suportados e causam erro ou comportamento incorreto.

Nesse modo, o IIS 7.0 e superiores sempre rejeita novas linhas em cabeçalhos de resposta (mesmo se o enableHeaderChecking do ASP.NET estiver definido como false)

Nesse modo, uma exceção é lançada quando você tenta definir o cabeçalho da resposta com um valor que contém \r ou \n. No Modo Clássico, por padrão, esse valor é codificado e passado se a codificação de cabeçalho estiver desativada. Por motivos de segurança, os aplicativos não devem tentar gravar novas linhas não codificadas nos valores do cabeçalho.

Os eventos PreSendRequestHeaders e PreSendRequestContent serão gerados juntos para cada módulo

No Modo Integrado, os módulos que assinam os eventos PreSendRequestHeaders e PreSendRequestContent são notificados juntos para os eventos PreSendRequestHeaders e PreSendRequestContent.

Por exemplo, um aplicativo pode falhar se o módulo A tiver uma dependência do módulo B sendo executado primeiro em PreSendRequestHeaders, antes que o módulo A seja executado para PreSendRequestContent. Um exemplo seria se o módulo B modificasse algum estado da solicitação e o módulo A dependesse dele.

Ao usar o modo integrado, a ordem dos módulos é invertida para o PreSendRequestHeaders e o PreSendRequestContent

No Modo Integrado, os módulos que assinam o PreSendRequestHeaders e o PreSendRequestContent serão notificados na ordem oposta da aparição deles na seção. Os aplicativos que têm vários módulos configurados para serem executados em qualquer um desses eventos serão afetados por essa alteração se compartilharem uma dependência da ordem dos eventos.

Para contornar esses problemas, altere a ordem dos módulos na seção ou execute o aplicativo no Modo Clássico.

No Modo Integrado, as configurações de threads e enfileiramentos são ignoradas

Nesse modo, o ASP.NET (não o IIS) processa as solicitações em threads e não usa a semântica dos threads ou dos enfileiramentos usada no Modo Clássico. Devido a essa desigualdade, no Modo Integrado, os aplicativos podem observar um comportamento de taxa de transferência ou de estresse diferente do que ocorre quando executados no Modo Clássico.

Se um erro de arquivo de configuração for encontrado ao usar o Modo Integrado, o IIS (não o ASP.NET) gerará uma mensagem de erro

Para aplicativos que executam no Modo Integrado, o IIS agora lê os arquivos de configuração de aplicativo. Portanto, se um XML malformado for encontrado no arquivo Web.config ou se houver erros de configuração no arquivo, o IIS sempre gerará uma mensagem de erro (o ASP.NET não gerará).

Como o IIS e o ASP.NET gravam erros em formatos diferentes, o formato da mensagem de erro difere dependendo se o aplicativo é executado no Modo Integrado ou no Modo Clássico. Veja um exemplo de um tipo de erro de arquivo de configuração gerado pelo IIS: Erro interno do servidor Erro de configuração: o arquivo de configuração não está bem formatado em XML.

No Modo Integrado, os aplicativos ASP.NET devem assinar os eventos de pipeline durante a chamada Init do módulo

Os aplicativos ASP.NET que usam o pipeline HTTP do ASP.NET podem assinar os eventos dos aplicativos fora do pipeline. No entanto, os aplicativos ASP.NET que usam o pipeline do Modo Integrado do IIS agora devem sempre assinar os eventos durante o método Init() do módulo. O exemplo a seguir mostra como uma assinatura de evento é implementada no Init:

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

Para obter mais informações sobre como criar módulos do IIS, consulte o artigo Desenvolvimento de módulo usando .NET.

Recursos adicionais

Para obter mais informações sobre como fazer upgrade para o IIS 7.0 e versões superiores no Windows Vista, consulte o artigo sobre compatibilidade de aplicativos do IIS 7.0 no Windows Vista: Requisitos de compatibilidade e recursos para o Windows Vista.