Compartilhar via

ASP.NET 4 alterações interruptivas

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

Baixar este white paper

Conteúdos

Configuração de ControlRenderingCompatibilityVersion no arquivo Web.config
Alterações de ClientIDMode
HtmlEncode e UrlEncode agora codificam aspas simples
O interpretador de páginas ASP.NET (.aspx) é mais rígido
Arquivos de definição do navegador atualizados
System.Web.Mobile.dll Removido do Arquivo de Configuração da Web no Diretório Raiz
Validação de Solicitação do ASP.NET
O algoritmo de hash padrão agora é HMACSHA256
Erros de configuração relacionados à nova configuração raiz do ASP.NET 4
Aplicativos filhos do ASP.NET 4 falham ao iniciar quando sob aplicativos ASP.NET 2.0 ou ASP.NET 3.5
Sites da Web do ASP.NET 4 não são iniciados em computadores com o SharePoint instalado
A propriedade HttpRequest.FilePath não inclui mais valores PathInfo
aplicativos ASP.NET 2.0 podem gerar erros httpException que fazem referência a 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 (ASP.NET Code Access Security)
MembershipUser e outros tipos no namespace System.Web.Security foram movidos
Alterações no Cache de Saída para Variar o 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 não conseguem renderizar imagens quando os caminhos contêm barras invertidas
Disclaimer

Configuração de ControlRenderingCompatibilityVersion no arquivo Web.config

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

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, 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 Label ) não renderizarão mais o disabled="disabled" atributo se a propriedade Habilitada 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 de 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, 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 aspa única (') 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 Page (.aspx) Parser está mais rigoroso

O analisador de páginas do ASP.NET (.aspx arquivos) e controles de usuário (.ascx arquivos) tornou-se mais rigoroso no ASP.NET 4 e rejeitará um maior número de instâncias de marcação inválida. Por exemplo, os dois snippets a seguir analisariam com êxito as versões anteriores de 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 style não fechado que continua até o atributo CssClass.

Arquivos de definição do navegador atualizados

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

Se o aplicativo contiver definições personalizadas do navegador que herdam 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 que herda da definição do navegador IE2, você receberá a seguinte mensagem de erro de configuração:

  • O navegador ou elemento de 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 na 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

Nas 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. 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 está obsoleto. 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 para o assembly System.Web.Mobile.dll ao arquivo Web.config.

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

O recurso de validação de solicitação no ASP.NET fornece um determinado nível de proteção padrão contra ataques de script entre sites (XSS). Nas versões anteriores do ASP.NET, a validação de solicitação era habilitada por padrão. No entanto, isto se aplicava apenas às páginas ASP.NET, arquivos de página (.aspx) 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 é 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áginas .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 para o 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 padrão de hash agora é o HMACSHA256.

ASP.NET usa algoritmos de criptografia e hash para ajudar a proteger dados, como cookies de autenticação de formulários e exibir o estado. 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 de HMACSHA1 mais antigo.

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

<machineKey validation="SHA1" />

Os arquivos de configuração raiz (machine.config e o arquivo raiz Web.config) para o .NET Framework 4 (e, portanto, ASP.NET 4) foram atualizados para incluir a maioria das informações de configuração pré-definidas que, no ASP.NET 3.5, eram encontradas nos arquivos do aplicativo Web.config. Devido à complexidade dos sistemas de configuração gerenciados do IIS 7 e do IIS 7.5, executar aplicativos ASP.NET 3.5 no ASP.NET 4, 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 do 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 seja necessário fazer para diferentes combinações de software.

Windows Vista SP1 ou Windows Server 2008 SP1, onde 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 de 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 do aplicativo Web.config modificadas manualmente que não correspondem precisamente às definições originais da seção de configuração padrão introduzidas com o Visual Studio 2008 causarão erros de configuração do 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 de 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 onde o hotfix KB958854 está instalado.

Nesse cenário, o sistema de configuração nativa IIS 7 e 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 Visual Studio 2008 SP1 têm "3.5" na cadeia de caracteres de tipo para os manipuladores de 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 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 do aplicativo Web.config incluindo o texto de configuração padrão de um arquivo Web.config 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 de configuração-mesclagem incorreto do sistema de configuração do IIS. No entanto, depois de executar qualquer 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 de seção de configuração system.web.extensions e definições de grupo de seção de configuração do arquivo de nível de aplicação Web.config. 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

ASP.NET 4 aplicativos configurados como filhos de aplicativos que executam versões anteriores do ASP.NET podem falhar ao iniciar devido a erros de configuração ou 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 falhará ao iniciar 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 indicar 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 configurações mescladas finais que são usadas pelo aplicativo Web filho na childwebapp pasta. Dependendo se o aplicativo Web ASP.NET 4 está 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ão um erro.

As etapas que você deve seguir para resolver esse problema e fazer com que o aplicativo filho ASP.NET 4 funcione dependem 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 somente em sistemas operacionais que executam o IIS 7 ou o IIS 7.5, que inclui Windows Vista, Windows Server 2008, Windows 7 e Windows Server 2008 R2.

Mova a definição configSections no arquivo Web.config do aplicativo pai (o aplicativo que executa ASP.NET 2.0 ou ASP.NET 3.5) para o arquivo raiz Web.config do .NET Framework 2.0. O sistema de configuração nativa IIS 7 e IIS 7.5 verifica o elemento configSections quando mescla a hierarquia de arquivos de configuração. Mover a definição do configSections do arquivo do aplicativo Web pai Web.config para o arquivo raiz Web.config efetivamente oculta 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 para 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 bits 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 legibilidade.

<?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)

Esta etapa é necessária se o aplicativo Web filho ASP.NET 4 está em execução no IIS 6 ou no IIS 7 (ou 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 localização que especifica explicitamente (para os sistemas de configuração do IIS e do ASP.NET) que as entradas de configuração se aplicam apenas ao aplicativo Web pai. O exemplo a seguir mostra a sintaxe do elemento de localização 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 filhos do ASP.NET 4 serão iniciados sem erros.

Os sites da Web do ASP.NET 4 falham ao iniciar em computadores onde 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 o Site Padrão). Neste Web.config arquivo, o SharePoint define um nível de confiança parcial personalizado chamado WSS_Minimal.

Se você tentar executar um site 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 de Segurança de Acesso ao Código (CAS) 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 de 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 seguinte fragmento de URL:

/testapp/Action.mvc/SomeAction

Nas 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 2.0 Aplicativos podem gerar erros HttpException que fazem referência a eurl.axd

Depois que ASP.NET 4 tiver sido habilitado no IIS 6, ASP.NET aplicativos 2.0 executados no IIS 6 (no Windows Server 2003 ou no Windows Server 2003 R2) podem 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 de ASP.NET 4 passa uma URL sem extensão para a parte gerenciada de ASP.NET para processamento adicional. No entanto, se os diretórios virtuais abaixo de um site ASP.NET 4 forem configurados para usar ASP.NET 2.0, processar a 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 nomeado 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 o ASP.NET 4 for necessário para executar o site, mova todos os subdiretórios virtuais do 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 , que faz com que o IIS leia o novo valor do Registro.

Observação

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

Manipuladores de eventos podem não ser acionados em um documento default 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 a uma URL sem extensão que tem um documento padrão mapeado para ele. Por exemplo, em versões anteriores de ASP.NET, uma solicitação para http://contoso.com resultaria em uma solicitação para Default.aspx. Nesse documento, a tag form 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 resultar em uma solicitação para Default.aspx. No entanto, o ASP.NET agora renderiza a tag de abertura formulário 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 IIS DefaultDocumentModule criará uma solicitação filho para Default.aspx. Na maioria das circunstâncias, essa solicitação secundária não afeta o código do aplicativo e a Default.aspx página é executada normalmente.

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

  1. Uma página .aspx é enviada ao navegador com o atributo de ação do elemento de formulário definido como "".
  2. O formulário é postado novamente no ASP.NET.
  3. Um módulo HTTP gerenciado lê alguma parte do conteúdo 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 nenhum módulo de código nativo que esteja em execução no modo integrado IIS 7 ou IIS 7.5.
  4. O objeto IIS DefaultDocumentModule 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 subordinada, o manipulador de arquivos .aspx é 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ágina .aspx para determinar qual evento (se houver) deve ser gerado. Como resultado, nenhum dos manipuladores de eventos de postback é executado na página .aspx afetada.

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 ele pode ser configurado para execução somente para solicitações gerenciadas. No modo integrado do IIS 7 e do 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 não sendo solicitações 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, que ainda está disponível e é passado para a requisição secundária 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 resolvem para o objeto DefaultDocumentModule , para solicitações gerenciadas etc.), modifique as páginas de .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 (ASP.NET Code Access Security)

ASP.NET 2.0 e, por extensão, os recursos do ASP.NET que foram adicionados na versão 3.5, usam o modelo CAS (Segurança de Acesso de Código) do .NET Framework 1.1 e 2.0. No entanto, a implementação do CAS no ASP.NET 4 foi substancialmente revisada. Como resultado, aplicativos de ASP.NET de confiança parcial 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 abrangentes na política CAS da máquina também podem falhar com exceções de segurança.

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

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

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

  • A política de CAS da máquina é 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 o ASP.NET ou outro código do .NET Framework está na pilha.

Um cenário não pode ser revertido no .NET Framework 4: aplicativos não web de confiança parcial 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 podem 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 a partir de aplicativos de confiança parcial que não são da 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:

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

Para obter mais informações sobre o novo modelo de segurança de acesso de 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 na associação do ASP.NET 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 arquitetônicas entre tipos no cliente e em SKUs estendidas do .NET Framework.

Projetos de sites da web não têm problemas como resultado da movimentação desses tipos de arquivos, pois System.Web.ApplicationServices.dll foi adicionada à lista de assemblies referenciados, que é usada por padrão pelo sistema de compilação ASP.NET. Se você atualizar um projeto de site 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 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) 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. Informações de encaminhamento de tipo foram adicionadas à versão do ASP.NET 4 de System.Web.dll que roteia automaticamente as referências de tempo de execução desses tipos para o novo local.

No entanto, 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 ao projeto da 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 que especificavam Location="ServerAndClient" como uma configuração de cache de saída emitisse um cabeçalho HTTP Vary:* na resposta. Isso teve o efeito de dizer aos navegadores cliente para nunca armazenarem 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 significativa na época. 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 existente de SetOmitVaryStar .

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 poderão ser 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 são obsoletos

O suporte do 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 de 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 que estão especificados nas propriedades StaticPopOutImageUrl e DynamicPopOutImageUrl para usar barras (/). O exemplo a seguir mostra esta 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.

Disclaimer

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. Uma vez que a Microsoft tem de responder a condições de mercado em mudança, não deve ser interpretada como um compromisso por parte da Microsoft e a Microsoft não pode garantir a exatidão de quaisquer informações apresentadas após a data de publicação.

Este White Paper é somente para fins informativos. A MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍCITAS OU ESTATUTÁRIAS, QUANTO ÀS INFORMAÇÕES DESTE DOCUMENTO.

O cumprimento de todas as leis de direitos autorais aplicáveis é de responsabilidade do usuário. Sem limitar os direitos sob 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 (eletrônico, mecânico, fotocopiador, gravação ou de outra forma) ou para qualquer finalidade, sem a permissão expressa por escrito da Microsoft Corporation.

A Microsoft pode ter patentes, pedidos de patentes, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abrangem assunto neste documento. Exceto conforme expressamente fornecido em qualquer contrato de licença escrito da Microsoft, o fornecimento deste documento não lhe concede qualquer licença para estas patentes, marcas registadas, direitos de autor ou outra propriedade intelectual.

A menos que observado 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 marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países.

Os nomes das empresas e produtos reais aqui mencionados podem ser marcas registadas dos respetivos proprietários.

  • Last updated on