Compartilhar via

Alterações significativas do ASP.NET 4

  • Artigo

Este documento descreve as alterações que foram feitas para a versão .NET Framework versão 4 que pode afetar potencialmente aplicativos que foram criados usando versões anteriores, incluindo as versões ASP.NET 4 Beta 1 e Beta 2.

Baixar este white paper

Sumário

Configuração controlRenderingCompatibilityVersion no arquivo Web.config
Alterações de ClientIDMode
HtmlEncode e UrlEncode agora codificam aspas simples
analisador de página de ASP.NET (.aspx) é mais rigoroso
Arquivos de definição do navegador atualizados
System.Web.Mobile.dll removido do arquivo de configuração raiz da Web
Validação de solicitação
O algoritmo de hash padrão agora é HMACSHA256
Erros de configuração relacionados à nova configuração raiz do ASP.NET 4
ASP.NET 4 aplicativos filho falham ao iniciar quando em aplicativos ASP.NET 2.0 ou ASP.NET 3.5
ASP.NET 4 Sites falham ao iniciar em computadores em que o SharePoint está instalado
A propriedade HttpRequest.FilePath não inclui mais valores PathInfo
aplicativos ASP.NET 2.0 podem gerar erros httpException que referenciam eurl.axd
Manipuladores de eventos podem não ser gerados em um documento padrão no modo integrado do IIS 7 ou IIS 7.5
Alterações na implementação do CAS (Segurança de Acesso ao Código) do ASP.NET
MembershipUser e outros tipos no namespace System.Web.Security foram movidos
Alterações de cache de saída para Variar * Cabeçalho HTTP
Os tipos System.Web.Security para Passport são obsoletos
A propriedade MenuItem.PopOutImageUrl falha ao renderizar uma imagem no ASP.NET 4
Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl falham ao renderizar imagens quando os caminhos contêm barras invertidas
Disclaimer

Configuração controlRenderingCompatibilityVersion no arquivo Web.config

ASP.NET controles foram modificados no .NET Framework versão 4 para permitir que você especifique com mais precisão como eles renderizam a marcação. Em versões anteriores do .NET Framework, alguns controles emitiram marcação que você não tinha como desabilitar. Por padrão, ASP.NET 4 esse tipo de marcação não é mais gerado.

Se você usar o Visual Studio 2010 para atualizar seu aplicativo do ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adicionará automaticamente uma configuração ao arquivo que preserva a Web.config renderização herdada. No entanto, se você atualizar um aplicativo alterando o pool de aplicativos no IIS para direcionar o .NET Framework 4, o ASP.NET usará o novo modo de renderização por padrão. Para desabilitar o novo modo de renderização, adicione a seguinte configuração no Web.config arquivo:

<pages controlRenderingCompatibilityVersion="3.5" />

As principais alterações de renderização que o novo comportamento traz são as seguintes:

  • Os controles Image e ImageButton não renderizam mais um border="0" atributo.
  • A classe BaseValidator e os controles de validação que derivam dela não renderizam mais o texto vermelho por padrão.
  • O controle HtmlForm não renderiza um atributo de nome .
  • O controle Tabela não renderiza mais um border="0" atributo.
  • Os controles que não foram projetados para entrada do usuário (por exemplo, o controle Rótulo ) não renderizarão mais o disabled="disabled" atributo se a propriedade Enabled estiver definida como false (ou se herdarem essa configuração de um controle de contêiner).

Alterações de ClientIDMode

A configuração ClientIDMode no ASP.NET 4 permite especificar como ASP.NET gera o atributo id para elementos HTML. Nas versões anteriores do ASP.NET, o comportamento padrão era equivalente à configuração autoID de ClientIDMode. No entanto, a configuração padrão agora é Previsível.

Se você usar o Visual Studio 2010 para atualizar seu aplicativo do ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adicionará automaticamente uma configuração ao Web.config arquivo que preserva o comportamento de versões anteriores do .NET Framework. No entanto, se você atualizar um aplicativo alterando o pool de aplicativos no IIS para direcionar o .NET Framework 4, o ASP.NET usará o novo modo por padrão. Para desabilitar o novo modo de ID do cliente, adicione a seguinte configuração no Web.config arquivo:

<pages clientIDMode="AutoID" />

HtmlEncode e UrlEncode agora codificam aspas simples

No ASP.NET 4, os métodos HtmlEncode e UrlEncode das classes HttpUtility e HttpServerUtility foram atualizados para codificar o caractere de aspas simples (') da seguinte maneira:

  • O método HtmlEncode codifica instâncias da aspa única como ' .
  • O método UrlEncode codifica instâncias da aspa única como %27.

ASP.NET Analisador de Página (.aspx) é mais estrito

O analisador de página para páginas de ASP.NET (.aspx arquivos) e controles de usuário (.ascx arquivos) é mais rigoroso no ASP.NET 4 e rejeitará mais instâncias de marcação inválida. Por exemplo, os dois snippets a seguir seriam analisados com êxito em versões anteriores do ASP.NET, mas agora gerarão erros de analisador no ASP.NET 4.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

Observe o ponto e vírgula inválido no final da marca HiddenField .

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Observe o atributo de estilo não revelado que é executado no atributo CssClass .

Arquivos de definição do navegador atualizados

Os arquivos de definição do navegador foram atualizados para incluir informações sobre dispositivos e navegadores novos e atualizados. Navegadores e dispositivos mais antigos como o Netscape Navigator foram removidos e navegadores e dispositivos mais novos como o Google Chrome e Apple iPhone foram adicionados.

Se seu aplicativo contiver definições do navegador personalizadas herdadas de uma das definições do navegador que foram removidas, você verá um erro. Por exemplo, se a App_Browsers pasta contiver uma definição de navegador herdada da definição do navegador IE2, você receberá a seguinte mensagem de erro de configuração:

  • O elemento de navegador ou gateway com a ID 'IE2' não pode ser encontrado.

Observação

O objeto HttpBrowserCapabilities (que é exposto pela propriedade Request.Browser da página) é controlado pelos arquivos de definições do navegador. Portanto, as informações retornadas acessando uma propriedade desse objeto no ASP.NET 4 podem ser diferentes das informações retornadas em uma versão anterior do ASP.NET.

Você pode reverter para os arquivos de definição do navegador antigos copiando os arquivos de definição do navegador da seguinte pasta:

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Copie os arquivos para a pasta correspondente \CONFIG\Browsers para ASP.NET 4. Depois de copiar os arquivos, execute a ferramenta de linha de comando Aspnet_regbrowsers.exe.

System.Web.Mobile.dll removido do arquivo de configuração raiz da Web

Em versões anteriores do ASP.NET, uma referência ao assembly System.Web.Mobile.dll foi incluída no arquivo raiz Web.config na seção assemblies em. Para melhorar o desempenho, a referência a esse assembly foi removida.

O assembly System.Web.Mobile.dll está incluído no ASP.NET 4, mas foi preterido. Se você quiser usar tipos do assembly System.Web.Mobile.dll, adicione uma referência a esse assembly ao arquivo raiz Web.config ou a um arquivo de aplicativo Web.config . Por exemplo, se você quiser usar qualquer um dos controles móveis ASP.NET (preteridos), adicione uma referência ao assembly System.Web.Mobile.dll ao Web.config arquivo.

Validação de solicitação ASP.NET

O recurso de validação de solicitação em ASP.NET fornece um determinado nível de proteção padrão contra ataques XSS (script entre sites). Em versões anteriores do ASP.NET, a validação de solicitação era habilitada por padrão. No entanto, ele se aplicava apenas a ASP.NET páginas (.aspx arquivos e seus arquivos de classe) e somente quando essas páginas estavam em execução.

No ASP.NET 4, por padrão, a validação de solicitação está habilitada para todas as solicitações, pois está habilitada antes da fase BeginRequest de uma solicitação HTTP. Como resultado, a validação de solicitação se aplica a solicitações para todos os recursos ASP.NET, não apenas solicitações de página .aspx. Isso inclui solicitações como chamadas de serviço Web e manipuladores HTTP personalizados. A validação de solicitação também está ativa quando módulos HTTP personalizados estão lendo o conteúdo de uma solicitação HTTP.

Como resultado, agora podem ocorrer erros de validação de solicitação para solicitações que anteriormente não disparavam erros. Para reverter ao comportamento do recurso de validação de solicitação ASP.NET 2.0, adicione a seguinte configuração no Web.config arquivo:

<httpRuntime requestValidationMode="2.0" />

No entanto, recomendamos que você analise quaisquer erros de validação de solicitação para determinar se manipuladores, módulos ou outros códigos personalizados existentes acessam entradas HTTP potencialmente inseguras que podem ser vetores de ataque XSS.

O algoritmo de hash padrão agora é HMACSHA256

O ASP.NET usa algoritmos de hash e criptografia para ajudar a proteger dados como cookies de autenticação de formulários e estado de exibição. Por padrão, ASP.NET 4 agora usa o algoritmo HMACSHA256 para operações de hash em cookies e estado de exibição. Versões anteriores do ASP.NET usavam o algoritmo HMACSHA1 mais antigo.

Seus aplicativos poderão ser afetados se você executar ambientes mistos ASP.NET 2.0/ASP.NET 4 em que dados como cookies de autenticação de formulários devem funcionar across.NET versões do Framework. Para configurar um aplicativo Web ASP.NET 4 para usar o algoritmo HMACSHA1 mais antigo, adicione a seguinte configuração no Web.config arquivo:

<machineKey validation="SHA1" />

Os arquivos de configuração raiz (o machine.config arquivo e o arquivo raizWeb.config) para o .NET Framework 4 (e, portanto, ASP.NET 4) foram atualizados para incluir a maioria das informações de configuração clichê que foram encontradas no ASP.NET 3.5 nos arquivos do aplicativoWeb.config. Devido à complexidade dos sistemas de configuração gerenciados do IIS 7 e do IIS 7.5, a execução ASP.NET aplicativos 3.5 em ASP.NET 4 e no IIS 7 e IIS 7.5 pode resultar em erros de configuração do ASP.NET ou do IIS.

Recomendamos que você atualize ASP.NET aplicativos 3.5 para ASP.NET 4 usando as ferramentas de atualização de projeto no Visual Studio 2010, se for prático. O Visual Studio 2010 modifica automaticamente o arquivo do Web.config aplicativo ASP.NET 3.5 para conter as configurações apropriadas para ASP.NET 4.

No entanto, é um cenário com suporte para executar ASP.NET aplicativos 3.5 usando o .NET Framework 4 sem recompilação. Nesse caso, talvez seja necessário modificar manualmente o arquivo do Web.config aplicativo antes de executar o aplicativo no .NET Framework 4 e no IIS 7 ou IIS 7.5.

As próximas duas seções descrevem as alterações que talvez você precise fazer para diferentes combinações de software.

Windows Vista SP1 ou Windows Server 2008 SP1, em que nem o hotfix KB958854 nem o SP2 estão instalados. Nessa configuração, o sistema de configuração do IIS 7 mescla incorretamente a configuração gerenciada de um aplicativo comparando o arquivo no nível Web.config do aplicativo com os arquivos ASP.NET 2.0 machine.config . Por isso, os arquivos no nível Web.config do aplicativo do .NET Framework 3.5 ou posterior devem ter uma definição da seção de configuração system.web.extensions (o elemento) para não causar uma falha de validação do IIS 7.

No entanto, entradas de arquivo no nível Web.config do aplicativo modificadas manualmente que não correspondem precisamente às definições originais da seção de configuração clichê que foram introduzidas com o Visual Studio 2008 causarão erros de configuração ASP.NET. (As entradas de configuração padrão geradas pelo Visual Studio 2008 funcionam corretamente.) Um problema comum é que os arquivos modificados Web.config manualmente deixam de fora os atributos de configuração allowDefinition e requirePermission encontrados em várias definições da seção de configuração. Isso causa uma incompatibilidade entre a seção de configuração abreviada em arquivos no nível Web.config do aplicativo e a definição completa no arquivo ASP.NET 4 machine.config . Como resultado, em tempo de execução, o sistema de configuração ASP.NET 4 lança um erro de configuração.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 e também Windows Vista SP1 e Windows Server 2008 SP1 em que o hotfix KB958854 está instalado.

Nesse cenário, o sistema de configuração nativo do IIS 7 e do IIS 7.5 retorna um erro de configuração porque executa uma comparação de texto no atributo de tipo definido para um manipulador de seção de configuração gerenciada. Como todos os Web.config arquivos gerados pelo Visual Studio 2008 e pelo Visual Studio 2008 SP1 têm "3.5" na cadeia de caracteres de tipo para os manipuladores da seção de configuração system.web.extensions (e relacionados), e como o arquivo ASP.NET 4 machine.config tem "4.0" no atributo de tipo para os mesmos manipuladores de seção de configuração, os aplicativos gerados no Visual Studio 2008 ou no Visual Studio 2008 SP1 sempre falham na validação de configuração no IIS 7 e no IIS 7.5.

Resolvendo esses problemas

A solução alternativa para o primeiro cenário é atualizar o arquivo no nível Web.config do aplicativo, incluindo o texto de configuração clichê de um Web.config arquivo que foi gerado automaticamente pelo Visual Studio 2008.

Uma solução alternativa para o primeiro cenário é instalar o Service Pack 2 para Vista ou o Windows Server 2008 em seu computador para corrigir o comportamento incorreto de mesclagem de configuração do sistema de configuração do IIS. No entanto, depois que você executar uma dessas ações, seu aplicativo provavelmente encontrará um erro de configuração devido ao problema descrito para o segundo cenário.

A solução alternativa para o segundo cenário é excluir ou comentar todas as definições da seção de configuração system.web.extensions e definições de grupo da seção de configuração do arquivo no nível Web.config do aplicativo. Essas definições geralmente estão na parte superior do arquivo no nível Web.config do aplicativo e podem ser identificadas pelo elemento configSections e seus filhos.

Para ambos os cenários, é recomendável que você também exclua manualmente a seção system.codedom , embora isso não seja necessário.

ASP.NET 4 aplicativos filho falham ao iniciar quando em aplicativos ASP.NET 2.0 ou ASP.NET 3.5

Os aplicativos ASP.NET 4 configurados como filhos de aplicativos que executam versões anteriores do ASP.NET talvez falhem ao iniciar devido a erros de configuração ou de compilação. O exemplo a seguir mostra uma estrutura de diretório para um aplicativo afetado.

/parentwebapp (configurado para usar ASP.NET 2.0 ou ASP.NET 3.5)
/childwebapp (configurado para usar ASP.NET 4)

O aplicativo na childwebapp pasta não será iniciado no IIS 7 ou IIS 7.5 e relatará um erro de configuração. O texto de erro incluirá uma mensagem semelhante à seguinte:

  • The requested page cannot be accessed because the related configuration data for the page is invalid.

  • The configuration section 'configSections' cannot be read because it is missing a section declaration.

No IIS 6, o aplicativo na childwebapp pasta também não será iniciado, mas relatará um erro diferente. Por exemplo, o texto de erro pode declarar o seguinte:

  • The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

Esses cenários ocorrem porque as informações de configuração do aplicativo pai na parentwebapp pasta fazem parte da hierarquia de informações de configuração que determina as definições de configuração mescladas finais que são usadas pelo aplicativo Web filho na childwebapp pasta . Dependendo se o aplicativo Web ASP.NET 4 estiver em execução no IIS 7 (ou IIS 7.5) ou no IIS 6, o sistema de configuração do IIS ou o sistema de compilação ASP.NET 4 retornará um erro.

As etapas que você deve seguir para resolve esse problema e fazer com que o aplicativo filho ASP.NET 4 funcione dependendo se o aplicativo ASP.NET 4 é executado no IIS 6 ou no IIS 7 (ou IIS 7.5).

Etapa 1 (somente IIS 7 ou IIS 7.5)

Essa etapa é necessária apenas em sistemas operacionais que executam o IIS 7 ou o IIS 7.5, que inclui o Windows Vista, o Windows Server 2008, o Windows 7 e o Windows Server 2008 R2.

Mova a definição configSections no Web.config arquivo do aplicativo pai (o aplicativo que executa ASP.NET 2.0 ou ASP.NET 3.5) para o arquivo raiz Web.config do the.NET Framework 2.0. O sistema de configuração nativo do IIS 7 e do IIS 7.5 examina o elemento configSections quando mescla a hierarquia de arquivos de configuração. Mover a definição configSections do arquivo do Web.config aplicativo Web pai para o arquivo raiz Web.config oculta efetivamente o elemento do processo de mesclagem de configuração que ocorre para o aplicativo filho ASP.NET 4.

Em um sistema operacional de 32 bits ou em pools de aplicativos de 32 bits, o arquivo raiz Web.config para ASP.NET 2.0 e ASP.NET 3.5 normalmente está localizado na seguinte pasta:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

Em um sistema operacional de 64 bits ou para pools de aplicativos de 64 bits, o arquivo raiz Web.config para ASP.NET 2.0 e ASP.NET 3.5 normalmente está localizado na seguinte pasta:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

Se você executar aplicativos Web de 32 e 64 bits em um computador de 64 bits, deverá mover o elemento configSections para arquivos raiz Web.config para os sistemas de 32 e 64 bits.

Quando você colocar o elemento configSections no arquivo raiz Web.config , cole a seção imediatamente após o elemento de configuração . O exemplo a seguir mostra como deve ser a parte superior do arquivo raiz Web.config quando você terminar de mover os elementos.

Observação

No exemplo a seguir, as linhas foram encapsuladas para facilitar a leitura.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

Etapa 2 (todas as versões do IIS)

Essa etapa é necessária se o aplicativo Web filho ASP.NET 4 está em execução no IIS 6 ou no IIS 7 (ou no IIS 7.5).

Web.config No arquivo do aplicativo Web pai que está executando ASP.NET 2 ou ASP.NET 3.5, adicione uma marca de local que especifique explicitamente (para os sistemas de configuração do IIS e do ASP.NET) que as entradas de configuração só se aplicam ao aplicativo Web pai. O exemplo a seguir mostra a sintaxe do elemento location a ser adicionado:

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

O exemplo a seguir mostra como a marca de localização é usada para encapsular todas as seções de configuração começando com a seção appSettings e terminando com a seção system.webServer .

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

Quando você concluir as etapas 1 e 2, os aplicativos Web filho ASP.NET 4 serão iniciados sem erros.

ASP.NET 4 sites falham ao iniciar em computadores em que o SharePoint está instalado

Os servidores Web que executam o SharePoint têm um Web.config arquivo implantado na raiz de um site do SharePoint (por exemplo, c:\inetpub\wwwroot\web.config para Site Padrão). Nesse Web.config arquivo, o SharePoint define um nível de confiança parcial personalizado chamado WSS_Minimal.

Se você tentar executar um site do ASP.NET 4 implantado como um filho desse tipo de site do SharePoint, verá o seguinte erro:

Could not find permission set named 'ASP.NET'.

Esse erro ocorre porque a infraestrutura cas (segurança de acesso ao código) do ASP.NET 4 procura um conjunto de permissões chamado ASP.NET. No entanto, o arquivo de configuração de confiança parcial referenciado por WSS_Minimal não contém nenhum conjunto de permissões com esse nome.

Atualmente, não há uma versão do SharePoint disponível compatível com ASP.NET. Como resultado, você não deve tentar executar um site ASP.NET 4 como um site filho em sites do SharePoint.

A propriedade HttpRequest.FilePath não inclui mais valores PathInfo

As versões anteriores do ASP.NET incluíam um valor PathInfo no valor retornado de várias propriedades relacionadas ao caminho do arquivo, incluindo HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath e HttpRequest.CurrentExecutionFilePath. ASP.NET 4 não inclui mais o valor PathInfo nos valores retornados dessas propriedades. Em vez disso, as informações de PathInfo estão disponíveis em HttpRequest.PathInfo. Por exemplo, imagine o fragmento da URL a seguir:

/testapp/Action.mvc/SomeAction

Em versões anteriores do ASP.NET, as propriedades HttpRequest têm os seguintes valores:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (vazio)

Em ASP.NET 4, as propriedades HttpRequest têm os seguintes valores:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET aplicativos 2.0 podem gerar erros httpException que fazem referência a eurl.axd

Depois que o ASP.NET 4 tiver sido habilitado no IIS 6, os aplicativos ASP.NET 2.0 executados no IIS 6 (no Windows Server 2003 ou Windows Server 2003 R2) poderão gerar erros como o seguinte:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

Esse erro ocorre porque quando ASP.NET detecta que um site está configurado para usar ASP.NET 4, um componente nativo do ASP.NET 4 passa uma URL sem extensão para a parte gerenciada do ASP.NET para processamento adicional. No entanto, se os diretórios virtuais abaixo de um site do ASP.NET 4 estiverem configurados para usar ASP.NET 2.0, o processamento da URL sem extensão dessa forma resultará em uma URL modificada que contém a cadeia de caracteres "eurl.axd". Essa URL modificada é enviada para o aplicativo ASP.NET 2.0. ASP.NET 2.0 não pode reconhecer o formato "eurl.axd". Portanto, ASP.NET 2.0 tenta encontrar um arquivo chamado eurl.axd e executá-lo. Como esse arquivo não existe, a solicitação falha com uma exceção HttpException .

Você pode contornar esse problema usando uma das opções a seguir.

Opção 1

Se ASP.NET 4 não for necessário para executar o site, remapee o site para usar ASP.NET 2.0.

Opção 2

Se ASP.NET 4 for necessário para executar o site, mova todos os diretórios virtuais filho ASP.NET 2.0 para um site diferente mapeado para ASP.NET 2.0.

Opção 3

Se não for prático remapear o site para ASP.NET 2.0 ou alterar o local de um diretório virtual, desabilite explicitamente o processamento de URL sem extensão no ASP.NET 4. Use este procedimento:

  1. No Registro do Windows, abra o seguinte nó:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Crie um novo valor DWORD chamado EnableExtensionlessUrls.
  2. Defina EnableExtensionlessUrls como 0. Isso desabilita o comportamento da URL sem extensão.
  3. Salve o valor do Registro e feche o editor do Registro.
  4. Execute a ferramenta de linha de comando iisreset , o que faz com que o IIS leia o novo valor do Registro.

Observação

Definir EnableExtensionlessUrls como 1 habilita o comportamento de URL sem extensão. Essa será a configuração padrão se nenhum valor for especificado.

Manipuladores de eventos podem não ser gerados em um documento padrão no modo integrado do IIS 7 ou IIS 7.5

ASP.NET 4 inclui modificações que alteram a forma como o atributo de ação do elemento de formulário HTML é renderizado quando uma URL sem extensão é resolvida para um documento padrão. Um exemplo de uma URL sem extensão resolvendo para um documento padrão seria http://contoso.com/, resultando em uma solicitação para http://contoso.com/Default.aspx.

ASP.NET 4 agora renderiza o valor do atributo de ação do elemento de formulário HTML como uma cadeia de caracteres vazia quando uma solicitação é feita para uma URL sem extensão que tem um documento padrão mapeado para ele. Por exemplo, em versões anteriores do ASP.NET, uma solicitação para http://contoso.com resultaria em uma solicitação para Default.aspx. Nesse documento, a marca de formulário de abertura seria renderizada como no exemplo a seguir:

<form action="Default.aspx" />

No ASP.NET 4, uma solicitação para http://contoso.com também resulta em uma solicitação para Default.aspx. No entanto, ASP.NET agora renderiza a marca de formulário de abertura HTML como no exemplo a seguir:

<form action="" />

Essa diferença na forma como o atributo de ação é renderizado pode causar alterações sutis na forma como uma postagem de formulário é processada pelo IIS e ASP.NET. Quando o atributo de ação for uma cadeia de caracteres vazia, o objeto DefaultDocumentModule do IIS criará uma solicitação filho para Default.aspx. Na maioria das condições, essa solicitação filho é transparente para o código do aplicativo e a Default.aspx página é executada normalmente.

No entanto, uma eventual interação entre código gerenciado e o modo integrado do IIS 7 ou IIS 7.5 pode fazer páginas .aspx gerenciadas pararem de funcionar adequadamente durante a solicitação filho. Se as seguintes condições ocorrerem, a solicitação filho para um Default.aspx documento resultará em um erro ou em um comportamento inesperado:

  1. Uma página .aspx é enviada para o navegador com o atributo de ação do elemento de formulário definido como "".
  2. O formulário é postado novamente em ASP.NET.
  3. Um módulo HTTP gerenciado lê parte do corpo da entidade. Por exemplo, um módulo lê Request.Form ou Request.Params. Isso faz o corpo da entidade da solicitação POST ser lido na memória gerenciada. Como resultado, o corpo da entidade não está mais disponível para quaisquer módulos de código nativo em execução no modo integrado do IIS 7 ou do IIS 7.5.
  4. O objeto DefaultDocumentModule do IIS eventualmente é executado e cria uma solicitação filho para o Default.aspx documento. No entanto, como o corpo da entidade já foi lido por um trecho de código gerenciado, não há nenhum corpo de entidade disponível para enviar a solicitação filho.
  5. Quando o pipeline HTTP é executado para a solicitação filho, o manipulador de .aspx arquivos é executado durante a fase de execução do manipulador.
  6. Como não há nenhum corpo de entidade, não há variáveis de formulário e nenhum estado de exibição e, portanto, nenhuma informação está disponível para o manipulador de páginas .aspx determinar qual evento (se houver) deve ser gerado. Como resultado, nenhum manipulador de eventos de postback para a página .aspx afetada é executado.

Você pode contornar esse comportamento das seguintes maneiras:

  • Identifique o módulo HTTP que está acessando o corpo da entidade da solicitação durante solicitações de documento padrão e determine se ela pode ser configurada para ser executada somente para solicitações gerenciadas. No modo Integrado para o IIS 7 e o IIS 7.5, os módulos HTTP podem ser marcados para serem executados somente para solicitações gerenciadas adicionando o seguinte atributo à entrada system.webServer/modules do módulo:

  • precondition="managedHandler"

  • Essa configuração desabilita o módulo para solicitações que o IIS 7 e o IIS 7.5 determinam como solicitações não gerenciadas. Para solicitações de documento padrão, a primeira solicitação é para uma URL sem extensão. Portanto, o IIS não executa nenhum módulo gerenciado marcado com uma pré-condição de manipulador gerenciado durante o processamento inicial da solicitação. Como resultado, os módulos gerenciados não lerão acidentalmente o corpo da entidade e, portanto, o corpo da entidade ainda estará disponível e será passado para a solicitação filho e para o documento padrão.

  • Se os módulos HTTP problemáticos tiverem que ser executados para todas as solicitações (para arquivos estáticos, para URLs sem extensão que resolve para o objeto DefaultDocumentModule, para solicitações gerenciadas etc.), modifique as páginas .aspx afetadas definindo explicitamente a propriedade Action do controle System.Web.UI.HtmlControls.HtmlForm da página como uma cadeia de caracteres não vazia. Por exemplo, se o documento padrão for Default.aspx, modifique o código da página para definir explicitamente a propriedade Action do controle HtmlForm como "Default.aspx".

Alterações na implementação do CAS (Segurança de Acesso ao Código) do ASP.NET

ASP.NET 2.0 e, por extensão, os recursos de ASP.NET que foram adicionados na versão 3.5 usam o modelo cas (segurança de acesso de código) .NET Framework 1.1 e 2.0. No entanto, a implementação da CAS no ASP.NET 4 foi substancialmente revisada. Como resultado, a confiança parcial ASP.NET aplicativos que dependem de código confiável em execução no GAC (cache de assembly global) podem falhar com várias exceções de segurança. Aplicativos de confiança parcial que dependem de modificações extensivas na política cas do computador também podem falhar com exceções de segurança.

Você pode reverter aplicativos de confiança parcial ASP.NET 4 ao comportamento de ASP.NET 1.1 e 2.0 usando o novo atributo legacyCasModel no elemento de configuração de confiança, conforme mostrado no exemplo a seguir:

<trust level= "Medium" legacyCasModel="true" />

Quando você reverter para o modelo CAS herdado, os seguintes comportamentos cas antigos são habilitados:

  • A política cas do computador é respeitada.
  • Vários conjuntos de permissões diferentes em um único domínio de aplicativo são permitidos.
  • As declarações de permissão explícitas não são necessárias para assemblies no GAC que são invocados quando apenas ASP.NET ou outro código .NET Framework está na pilha.

Um cenário não pode ser revertido no .NET Framework 4: aplicativos de confiança parcial não Web não podem mais chamar determinadas APIs em System.Web.dll e System.Web.Extensions.dll. Nas versões anteriores do .NET Framework, era possível que aplicativos de confiança parcial não Web recebessem explicitamente permissões AspNetHostingPermission. Esses aplicativos poderiam usar System.Web.HttpUtility, tipos nos namespaces System.Web.ClientServices.* e tipos relacionados a associação, funções e perfis. Não há mais suporte para chamar esses tipos de aplicativos de confiança parcial não Web no .NET Framework 4.

Observação

A funcionalidade HtmlEncode e HtmlDecode da classe System.Web.HttpUtility foi movida para a nova classe System.Net.WebUtility do .NET Framework 4. Se essa fosse a única funcionalidade ASP.NET que estava sendo usada, modifique o código do aplicativo para usar a nova classe WebUtility .

Veja a seguir um resumo de alto nível das alterações na implementação padrão do CAS no ASP.NET 4:

  • ASP.NET domínios de aplicativo agora são domínios de aplicativo homogêneos. Somente conjuntos de concessões de confiança parcial e confiança total estão disponíveis em um domínio de aplicativo.
  • ASP.NET conjuntos de concessões de confiança parcial são independentes de qualquer política CAS de nível empresarial, de nível de computador ou de usuário.
  • ASP.NET assemblies enviados no 3.5 e 3.5 SP1 foram convertidos para usar o modelo de transparência .NET Framework 4.
  • O uso do atributo AspNetHostingPermission do ASP.NET foi substancialmente reduzido. A maioria das instâncias desse atributo foi removida das APIs de ASP.NET pública.
  • Assemblies compilados dinamicamente criados pelo ASP.NET provedores de build foram atualizados para marcar explicitamente assemblies como transparentes.
  • Todos os assemblies ASP.NET agora são marcados de forma que o atributo APTCA seja respeitado apenas em ambientes de hospedagem na Web. Ambientes de hospedagem não Web parcialmente confiáveis, como o ClickOnce, não poderão chamar ASP.NET assemblies.

Para obter mais informações sobre o novo modelo de segurança de acesso ao código ASP.NET 4, consulte Usando a segurança de acesso ao código em aplicativos ASP.NET no site do MSDN.

MembershipUser e outros tipos no namespace System.Web.Security foram movidos

Alguns tipos usados em ASP.NET associação foram movidos de System.Web.dll para o novo assembly System.Web.ApplicationServices.dll. Os tipos foram movidos para resolver as dependências de camadas de arquitetura entre os tipos no cliente e nos SKUs do .NET Framework estendido.

Os projetos de site não têm problemas como resultado da movimentação desses tipos, pois System.Web.ApplicationServices.dll foi adicionado à lista de assemblies referenciados usados por padrão pelo sistema de compilação ASP.NET. Se você atualizar um projeto de site que foi criado usando uma versão anterior do ASP.NET para ASP.NET 4 abrindo-o no Visual Studio 2010, o projeto será compilado sem erros.

Da mesma forma, se você atualizar um projeto de aplicativo Web que foi criado em uma versão anterior do ASP.NET para ASP.NET 4 abrindo-o no Visual Studio 2010, o processo de atualização adicionará uma referência a System.Web.ApplicationServices.dll ao projeto. Portanto, projetos de aplicativo Web atualizados também serão compilados sem erros.

Arquivos compilados (binários) que foram criados usando versões anteriores do ASP.NET também serão executados sem erros no ASP.NET 4, mesmo que os tipos de associação tenham sido movidos para um assembly diferente. As informações de encaminhamento de tipo foram adicionadas à versão ASP.NET 4 do System.Web.dll que roteia automaticamente referências de tempo de execução para esses tipos para o novo local para os tipos.

No entanto, as bibliotecas de classes que usam tipos de associação específicos e que foram atualizadas de versões anteriores do ASP.NET não serão compiladas quando usadas em um projeto ASP.NET 4. Por exemplo, um projeto de biblioteca de classes pode falhar ao compilar e relatar um erro como o seguinte:

  • The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

  • The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

Você pode contornar esse problema adicionando uma referência em seu projeto de biblioteca de classes para System.Web.ApplicationServices.dll.

A lista a seguir mostra os tipos System.Web.Security que foram movidos de System.Web.dll para System.Web.ApplicationServices.dll:

  • System.Web.Security.MembershipCreateStatus
  • System.Web.Security.Membership.CreateUserException
  • System.Web.Security.MembershipPasswordException
  • System.Web.Security.MembershipPasswordFormat
  • System.Web.Security.MembershipProvider
  • System.Web.Security.MembershipProviderCollection
  • System.Web.Security.MembershipUser
  • System.Web.Security.MembershipUserCollection
  • System.Web.Security.MembershipValidatePasswordEventHandler
  • System.Web.Security.ValidatePasswordEventArgs
  • System.Web.Security.RoleProvider
  • System.Web.Configuration.MembershipPasswordCompatibilityMode

Alterações de cache de saída para Variar * Cabeçalho HTTP

No ASP.NET 1.0, um bug fazia com que páginas armazenadas em cache especificadas Location="ServerAndClient" como uma configuração de cache de saída emitem um Vary:* cabeçalho HTTP na resposta. O efeito disso era informar os navegadores de clientes a nunca armazenar a página em cache localmente.

No ASP.NET 1.1, o método System.Web.HttpCachePolicy.SetOmitVaryStar foi adicionado, que você pode chamar para suprimir o Vary:* cabeçalho. Esse método foi escolhido porque a alteração do cabeçalho HTTP emitido foi considerada uma alteração potencialmente interruptiva no momento. No entanto, os desenvolvedores foram confundidos com o comportamento em ASP.NET, e relatórios de bugs sugerem que os desenvolvedores não estão cientes do comportamento setOmitVaryStar existente.

No ASP.NET 4, foi tomada a decisão de corrigir o problema raiz. O Vary:* cabeçalho HTTP não é mais emitido de respostas que especificam a seguinte diretiva:

<%@OutputCache Location="ServerAndClient" %>

Como resultado, SetOmitVaryStar não é mais necessário para suprimir o Vary:* cabeçalho.

Em aplicativos que especificam Location="ServerAndClient" na diretiva @ OutputCache em uma página, agora você verá o comportamento implícito pelo nome do valor do atributo Location , ou seja, as páginas serão armazenadas em cache no navegador sem exigir que você chame o método SetOmitVaryStar .

Se as páginas em seu aplicativo precisarem emitir Vary:*, chame o método AppendHeader , como no exemplo a seguir:

HttpResponse.AppendHeader("Vary","*");

Como alternativa, você pode alterar o valor do atributo Local de cache de saída para "Servidor".

Os tipos System.Web.Security para Passport estão obsoletos

O suporte ao Passport integrado ao ASP.NET 2.0 está obsoleto e sem suporte há alguns anos devido a alterações no Passport (agora LiveID). Como resultado, os cinco tipos relacionados ao Passport em System.Web.Security agora estão marcados com o atributo ObsoleteAttribute .

A propriedade MenuItem.PopOutImageUrl falha ao renderizar uma imagem no ASP.NET 4

No ASP.NET 3.5, a propriedade MenuItem.PopOutImageUrl permite especificar a URL de uma imagem exibida em um item de menu para indicar que o item de menu tem um submenu dinâmico. O exemplo a seguir mostra como especificar essa propriedade na marcação no ASP.NET 3.5.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Como resultado de uma alteração de design no ASP.NET 4, nenhuma saída será renderizada para o PopOutImageUrl se a propriedade estiver definida para a classe MenuItem . Em vez disso, você deve especificar uma URL de imagem diretamente no controle Menu usando a propriedade StaticPopOutImageUrl ou a propriedade DynamicPopOutImageUrl . Quando você trabalha com um menu estático, a propriedade Menu.StaticPopOutImageUrl especifica a URL de uma imagem exibida para indicar que o item de menu estático tem um submenu, conforme mostrado no exemplo a seguir:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Se você estiver trabalhando com um menu dinâmico, use a propriedade Menu.DynamicPopOutImageUrl para especificar a URL de uma imagem que indica que um item de menu dinâmico tem um submenu. O exemplo a seguir é semelhante ao anterior, mas mostra como definir a propriedade DynamicPopOutImageUrl para um menu dinâmico.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Se a propriedade Menu.DynamicPopOutImageUrl não estiver definida e a propriedade Menu.DynamicEnableDefaultPopOutImage estiver definida como false, nenhuma imagem será exibida. Da mesma forma, se a propriedade StaticPopOutImageUrl não estiver definida e a propriedade StaticEnableDefaultPopOutImage for definida como false, nenhuma imagem será exibida.

Ao definir os caminhos para essas propriedades, use uma barra (/) em vez de uma barra invertida (). Para obter mais informações, consulte Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl falham ao renderizar imagens quando os caminhos contêm barras invertidas em outro lugar neste documento.

No ASP.NET 4, as imagens especificadas usando as propriedades Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl não serão renderizadas se o caminho contiver reações (). Essa é uma alteração das versões anteriores do ASP.NET.

O exemplo a seguir da marcação de controle menu mostra a propriedade StaticPopOutImageUrl definida usando um caminho que contém uma barra invertida. No ASP.NET 4, a imagem especificada na propriedade não será renderizada.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Para corrigir esse problema, altere os valores de caminho especificados nas propriedades StaticPopOutImageUrl e DynamicPopOutImageUrl para usar barras (/). O exemplo a seguir mostra essa alteração:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Observe que os aplicativos que foram migrados de versões anteriores do ASP.NET para ASP.NET 4 também podem ser afetados, pois a propriedade MenuItem.PopOutImageUrl foi alterada. Para obter mais informações, consulte A propriedade MenuItem.PopOutImageUrl falha ao renderizar uma imagem em ASP.NET 4 em outro lugar neste documento.

Isenção de responsabilidade

Este é um documento preliminar e pode ser alterado substancialmente antes da versão comercial final do software descrito aqui.

As informações contidas neste documento representam a visão atual da Microsoft Corporation acerca das questões discutidas até a data da publicação. Como a Microsoft deve reagir às dinâmicas condições do mercado, essas informações não devem ser interpretadas como um compromisso por parte da Microsoft e a Microsoft não garante a precisão de qualquer informação apresentada após a data de publicação.

Este whitepaper é apenas para fins informativos. A MICROSOFT NÃO OFERECE GARANTIA, EXPRESSA, IMPLÍCITA OU ESTATUTÁRIA, DAS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO.

Obedecer a todas as leis de direitos autorais aplicáveis é responsabilidade do usuário. Sem limitar os direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada ou introduzida em um sistema de recuperação, ou transmitida de qualquer forma ou por qualquer meio (seja eletrônico, mecânico, fotocópia, gravação ou outro), ou para qualquer finalidade, sem a permissão expressa e por escrito da Microsoft Corporation.

A Microsoft pode ter patentes ou requisições para obtenção de patente, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abrangem o conteúdo deste documento. A posse deste documento não lhe confere nenhum direito sobre patentes, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual, salvo aqueles expressamente mencionados em um contrato de licença, por escrito, da Microsoft.

A menos que indicado de outra forma, as empresas de exemplo, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, locais e eventos descritos aqui são fictícios e nenhuma associação com nenhuma empresa real, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, local ou evento é pretendida ou deve ser inferida.

© Microsoft Corporation 2010. Todos os direitos reservados.

Microsoft e Windows são marcas registradas ou comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países.

Os nomes de empresas reais e produtos mencionados aqui podem ser marcas comerciais de seus respectivos proprietários.