Partilhar via

ASP.NET 4 Mudanças Disruptivas

Este documento descreve alterações feitas para a versão 4 do .NET Framework que podem potencialmente afetar aplicações criadas com versões anteriores, incluindo as versões Beta 1 e Beta 2 do ASP.NET 4.

Descarregue Este Whitepaper

Conteúdos

Configuração de ControlRenderingCompatibilityVersion no ficheiro Web.config
Alterações no ClientIDMode
HtmlEncode e UrlEncode agora codificam aspas simples
O analisador de páginas ASP.NET (.aspx) tornou-se mais rigoroso
Ficheiros de Definição do Navegador Atualizados
System.Web.Mobile.dll Removido do Arquivo de Configuração Web Raiz
ASP.NET Validação de Pedidos
O algoritmo de hashing padrão é agora HMACSHA256
Erros de Configuração Relacionados com a Configuração Raiz do New ASP.NET 4
ASP.NET 4 Subaplicações Falham ao Iniciar ao serem executadas em ASP.NET 2.0 ou ASP.NET 3.5
ASP.NET 4 sites web falham em arrancar nos computadores onde o SharePoint está instalado
A propriedade HttpRequest.FilePath já não inclui valores PathInfo
aplicações ASP.NET 2.0 podem gerar erros de HttpException que fazem referência a eurl.axd
Os Manipuladores de Eventos podem não ser ativados num documento predefinido no modo integrado do IIS 7 ou no IIS 7.5
Alterações à implementação da Segurança de Acesso ao Código ASP.NET (CAS)
MembershipUser e outros tipos no espaço de nomes do System.Web.Security foram transferidos
Alterações no Cache de Saída para Variar o Cabeçalho HTTP
System.Web.Tipos de Segurança para Passaportes estão Obsoletos
A propriedade MenuItem.PopOutImageUrl falha em renderizar uma imagem em ASP.NET 4
Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl falham em renderizar imagens quando os caminhos contêm barras invertidas
Aviso legal

ControlRenderingCompatibilityVersion Definições no ficheiro Web.config

ASP.NET controles foram modificados no .NET Framework versão 4 para permitir que você especifique com mais precisão como renderizam o markup. Em versões anteriores do .NET Framework, alguns controlos emitiam marcação que não havia forma de desativar. Por defeito, no ASP.NET 4, este tipo de marcação já não é gerada.

Se usar o Visual Studio 2010 para atualizar a sua aplicação de ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adiciona automaticamente uma definição ao Web.config ficheiro que preserva a renderização legada. No entanto, se atualizar uma aplicação alterando o pool de aplicações no IIS para apontar para o .NET Framework 4, o ASP.NET usa o novo modo de renderização por padrão. Para desativar o novo modo de renderização, adicione a seguinte definição no Web.config ficheiro:

<pages controlRenderingCompatibilityVersion="3.5" />

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

  • Os controlos Image e ImageButton já não renderizam nenhum border="0" atributo.
  • A classe BaseValidator e os controlos de validação que dela derivam já não renderizam texto vermelho por defeito.
  • O controlo HtmlForm não renderiza um atributo de nome .
  • O controlo Table já não renderiza um border="0" atributo.
  • Controlos que não são concebidos para entrada do utilizador (por exemplo, o controlo Rótulo ) já não renderizam o disabled="disabled" atributo se a sua propriedade Ativada estiver definida como falsa (ou se herdarem esta definição de um controlo de contentor).

Alterações no ClientIDMode

A definição ClientIDMode em ASP.NET 4 permite-lhe especificar como ASP.NET gera o atributo id para elementos HTML. Em versões anteriores do ASP.NET, o comportamento padrão era equivalente à definição AutoID do ClientIDMode. No entanto, a configuração padrão agora é Previsível.

Se usar o Visual Studio 2010 para atualizar a sua aplicação de ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adiciona automaticamente uma definição ao Web.config ficheiro que preserva o comportamento das versões anteriores do .NET Framework. No entanto, se atualizar uma aplicação alterando o pool de aplicações no IIS para direcioná-lo especificamente ao .NET Framework 4, o ASP.NET utiliza o novo modo por predefinição. Para desativar o novo modo de ID do cliente, adicione a seguinte definição no Web.config ficheiro:

<pages clientIDMode="AutoID" />

HtmlEncode e UrlEncode agora codificam aspas únicas

Em ASP.NET 4, os métodos HtmlEncode e UrlEncode das classes HttpUtility e HttpServerUtility foram atualizados para codificar o carácter de aspas simples (') da seguinte forma:

  • O método HtmlEncode codifica instâncias da aspas simples como '.
  • O método UrlEncode codifica instâncias da aspas simples como %27.

ASP.NET O Parser de Páginas (.aspx) é mais rigoroso

O parser de páginas para ficheiros de páginas ASP.NET (.aspx) e ficheiros de controlos de utilizador (.ascx) é mais rigoroso no ASP.NET 4 e rejeitará mais instâncias de marcação inválida. Por exemplo, os dois snippets seguintes conseguiam analisar com sucesso em versões anteriores do ASP.NET, mas agora geram erros de analisador em ASP.NET 4.

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

Repare no ponto e vírgula inválido no final da tag HiddenField.

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

Repare no atributo style não fechado que se encontra com o atributo CssClass.

Ficheiros 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 seu aplicativo contiver definições de navegador personalizadas que herdam de uma das definições de 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, receberá a seguinte mensagem de erro de configuração:

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

Observação

O objeto HttpBrowserCapabilities (que é exposto pela propriedade Request.Browser da página) é orientado pelos ficheiros de definições do navegador. Portanto, a informação devolvida ao aceder a uma propriedade deste objeto em ASP.NET 4 pode ser diferente da informação devolvida numa versão anterior de ASP.NET.

Pode reverter para os antigos ficheiros de definição do navegador copiando os ficheiros de definição do navegador da seguinte pasta:

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

Copie os ficheiros para a pasta correspondente \CONFIG\Browsers para ASP.NET 4. Depois de copiares os ficheiros, executa a Aspnet_regbrowsers.exe ferramenta de linha de comandos.

System.Web.Mobile.dll Removido do Ficheiro de Configuração Web Raiz

Em versões anteriores de ASP.NET, uma referência ao assembly System.Web.Mobile.dll estava incluída no ficheiro raiz Web.config na secção assemblies abaixo. Para melhorar o desempenho, a referência a este conjunto foi removida.

A System.Web.Mobile.dll assembly está incluída no ASP.NET 4, mas está obsoleta. Se quiseres usar tipos do assembly System.Web.Mobile.dll, adiciona uma referência a esse assembly ao ficheiro raiz Web.config ou a um ficheiro de aplicação Web.config . Por exemplo, se quiseres usar algum dos controlos móveis (obsoletos) ASP.NET, tens de adicionar uma referência ao conjunto do System.Web.Mobile.dll ao Web.config ficheiro.

ASP.NET Validação de Pedidos

A funcionalidade de validação de pedidos no ASP.NET proporciona um certo nível de proteção por defeito contra ataques Cross-Site Scripting (XSS). Em versões anteriores do ASP.NET, a validação de pedidos estava ativada por defeito. No entanto, aplicava-se apenas a páginas ASP.NET (.aspx ficheiros e seus ficheiros de classe) e apenas quando essas páginas estavam em execução.

No ASP.NET 4, por defeito, a validação de pedidos está ativada para todos os pedidos, porque está ativada antes da fase BeginRequest de um pedido HTTP. Como resultado, a validação de solicitações aplica-se a todas as solicitações de recursos do ASP.NET, não apenas a solicitações de páginas .aspx. Isto inclui pedidos como chamadas de serviço Web e manipuladores HTTP personalizados. A validação de pedidos também está ativa quando módulos HTTP personalizados estão a ler o conteúdo de um pedido HTTP.

Como resultado, podem agora ocorrer erros de validação de pedidos para pedidos que anteriormente não desencadeavam erros. Para reverter ao comportamento da funcionalidade de validação de pedidos do ASP.NET 2.0, adicione a seguinte definição no Web.config ficheiro:

<httpRuntime requestValidationMode="2.0" />

No entanto, recomendamos que analise quaisquer erros de validação de pedidos para determinar se handlers, módulos ou outros códigos personalizados existentes acedem a entradas HTTP potencialmente inseguras que possam ser vetores de ataque XSS.

O algoritmo de hashing padrão é agora HMACSHA256

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

As suas aplicações podem ser afetadas se executar ambientes mistos ASP.NET 2.0/ASP.NET 4, onde dados como cookies de autenticação de formulários têm de funcionar entre versões do .NET Framework. Para configurar uma aplicação Web ASP.NET 4 para usar o algoritmo HMACSHA1 mais antigo, adicione a seguinte definição no Web.config ficheiro:

<machineKey validation="SHA1" />

Os ficheiros de configuração raiz (o ficheiro machine.config e o ficheiro raiz Web.config) para o .NET Framework 4 (e, portanto, ASP.NET 4) foram atualizados para incluir a maior parte da informação de configuração geral que no ASP.NET 3.5 era encontrada nos ficheiros de aplicação Web.config. Devido à complexidade dos sistemas geridos de configuração IIS 7 e IIS 7.5, executar aplicações ASP.NET 3.5 sob ASP.NET 4 e sob IIS 7 e IIS 7.5 pode resultar em erros de configuração ASP.NET ou IIS.

Recomendamos que atualize ASP.NET aplicações 3.5 para ASP.NET 4 utilizando as ferramentas de atualização de projetos no Visual Studio 2010, se possível. O Visual Studio 2010 modifica automaticamente o ficheiro da Web.config aplicação ASP.NET 3.5 para conter as definições apropriadas para ASP.NET 4.

No entanto, é um cenário suportado para executar ASP.NET aplicações 3.5 usando o .NET Framework 4 sem recompilação. Nesse caso, pode ser necessário modificar manualmente o ficheiro da Web.config aplicação antes de a executar no .NET Framework 4 e no IIS 7 ou IIS 7.5.

As duas secções seguintes descrevem as alterações que poderá precisar de 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. Nesta configuração, o sistema de configuração IIS 7 funde incorretamente a configuração gerida de uma aplicação, comparando o ficheiro ao nível Web.config da aplicação com os ficheiros ASP.NET 2.0 machine.config . Por causa disso, os ficheiros de nível de aplicação do .NET Framework 3.5 ou posterior devem ter a definição da secçã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 ficheiros ao nível Web.config da aplicação modificadas manualmente que não correspondam precisamente às definições originais de secção de configuração boilerplate 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 ficheiros modificados Web.config manualmente deixam de fora os atributos de configuração allowDefinition e requirePermission que se encontram em várias definições de secções de configuração. Isto causa uma incompatibilidade entre a secção de configuração abreviada nos ficheiros ao nível Web.config da aplicação e a definição completa no ficheiro ASP.NET 4 machine.config . Como resultado, em tempo de execução, o sistema de configuração ASP.NET 4 gera 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.

Neste cenário, o sistema de configuração nativo IIS 7 e IIS 7.5 devolve um erro de configuração porque realiza uma comparação de texto no atributo type definido para um handler de secção de configuração gerida. Como todos os Web.config ficheiros gerados pelo Visual Studio 2008 e Visual Studio 2008 SP1 têm "3.5" na cadeia de tipo para os handlers da secção de configuração system.web.extensions (e relacionados), e porque o ficheiro ASP.NET 4 machine.config tem "4.0" no atributo type para os mesmos handlers da secção de configuração, as aplicações geradas no Visual Studio 2008 ou Visual Studio 2008 SP1 falham sempre na validação de configuração no IIS 7 e IIS 7.5.

Resolução destas questões

A solução alternativa para o primeiro cenário é atualizar o ficheiro ao nível Web.config da aplicação incluindo o texto de configuração padrão a partir de um Web.config ficheiro gerado automaticamente pelo Visual Studio 2008.

Uma alternativa alternativa para o primeiro cenário é instalar o Service Pack 2 para Vista ou Windows Server 2008 no seu computador para corrigir o comportamento incorreto de fusão de configuração do sistema IIS. No entanto, depois de realizar qualquer uma destas ações, a sua aplicação provavelmente encontrará um erro de configuração devido ao problema descrito no segundo cenário.

A solução alternativa para o segundo cenário é eliminar ou comentar todas as definições de secção de configuração system.web.extensions e definições de grupos de secções de configuração do ficheiro ao nível Web.config da aplicação. Estas definições encontram-se normalmente no topo do ficheiro ao nível Web.config da aplicação e podem ser identificadas pelo elemento configSections e seus filhos.

Para ambos os cenários, recomenda-se que também elimine manualmente a secção system.codedom , embora isso não seja obrigatório.

ASP.NET 4 Aplicações Filhos Não Iniciam Quando Estão sob 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 seguinte mostra uma estrutura de diretórios para uma aplicação afetada.

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

A aplicação na childwebapp pasta falhará ao iniciar no IIS 7 ou IIS 7.5 e reportará um erro de configuração. O texto do 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, a aplicação na childwebapp pasta também falha ao iniciar, mas reporta um erro diferente. Por exemplo, o texto do 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

Estes cenários ocorrem porque a informação de configuração da aplicação mãe na parentwebapp pasta faz parte da hierarquia de informação de configuração que determina as definições finais de configuração fusionadas que são usadas pela aplicação web filha na childwebapp pasta. Dependendo se a aplicação Web ASP.NET 4 está a correr no IIS 7 (ou IIS 7.5) ou no IIS 6, ou o sistema de configuração do IIS ou o sistema de compilação do ASP.NET 4 devolverá um erro.

Os passos que deve seguir para resolver este problema e para pôr a aplicação filha ASP.NET 4 a funcionar dependem se a aplicação ASP.NET 4 corre no IIS 6 ou no IIS 7 (ou IIS 7.5).

Passo 1 (apenas IIS 7 ou IIS 7.5)

Esta etapa é necessária apenas em sistemas operativos que executam IIS 7 ou IIS 7.5, incluindo Windows Vista, Windows Server 2008, Windows 7 e Windows Server 2008 R2.

Mova a definição configSections no Web.config ficheiro da aplicação mãe (a aplicação que corre ASP.NET 2.0 ou ASP.NET 3.5) para o ficheiro raiz Web.config do the.NET Framework 2.0. O sistema de configuração nativo IIS 7 e IIS 7.5 varre o elemento configSections quando este funde a hierarquia dos ficheiros de configuração. Mover a definição configSections do ficheiro da aplicação Web principal Web.config para o ficheiro raiz Web.config oculta efetivamente o elemento do processo de fusão de configuração que ocorre para a aplicação ASP.NET 4 secundária.

Num sistema operativo de 32 bits ou em pools de aplicações de 32 bits, o ficheiro raiz Web.config para ASP.NET 2.0 e ASP.NET 3.5 encontra-se normalmente na seguinte pasta:

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

Num sistema operativo de 64 bits ou em pools de aplicações de 64 bits, o ficheiro raiz Web.config para ASP.NET 2.0 e ASP.NET 3.5 encontra-se normalmente na seguinte pasta:

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

Se executar aplicações Web de 32 e 64 bits num computador de 64 bits, deve mover o elemento configSections para ficheiros raiz Web.config tanto para os sistemas de 32 bits como para os sistemas de 64 bits.

Quando colocares o elemento configSections no ficheiro raiz, Web.config cola a secção imediatamente a seguir ao elemento de configuração . O exemplo seguinte mostra como deve ser a parte superior do ficheiro raiz Web.config quando terminar de mover os elementos.

Observação

No exemplo seguinte, as linhas foram enroladas para maior 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>

Passo 2 (todas as versões do IIS)

Este passo é necessário quer a aplicação Web filho ASP.NET 4 esteja a correr no IIS 6 ou no IIS 7 (ou IIS 7.5).

No Web.config ficheiro da aplicação Web mãe que está a correr ASP.NET 2 ou ASP.NET 3.5, adicione uma etiqueta de localização que especifique explicitamente (tanto para o sistema IIS como para o sistema de configuração ASP.NET) que as entradas de configuração se aplicam apenas à aplicação Web principal. O exemplo seguinte mostra a sintaxe do elemento de localização a adicionar:

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

O exemplo seguinte mostra como a etiqueta de localização é usada para envolver todas as secções de configuração, começando pela secção appSettings e terminando com a secçã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 tiver concluído as etapas 1 e 2, as aplicações Web filhas do ASP.NET 4 iniciarão sem erros.

ASP.NET 4 sites web falham em arrancar nos computadores onde o SharePoint está instalado

Servidores web que executam SharePoint têm um Web.config ficheiro que é implementado na raiz de um site SharePoint (por exemplo, c:\inetpub\wwwroot\web.config para o Site Web Padrão). Neste Web.config ficheiro, o SharePoint define um nível personalizado de confiança parcial chamado WSS_Minimal.

Se tentar executar um site ASP.NET 4 que seja implementado como filho deste tipo de site SharePoint, verá o seguinte erro:

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

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

Atualmente, não existe uma versão do SharePoint disponível que seja compatível com ASP.NET. Por isso, não deve tentar executar um site ASP.NET 4 como um site filho dentro de sites do SharePoint.

A propriedade HttpRequest.FilePath já não inclui valores PathInfo

Versões anteriores de ASP.NET incluíam um valor PathInfo no valor devolvido por várias propriedades relacionadas com caminhos de ficheiros, incluindo HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath e HttpRequest.CurrentExecutionFilePath. ASP.NET 4 já não inclui o valor PathInfo nos valores de retorno destas propriedades. Em vez disso, a informação do PathInfo está disponível em HttpRequest.PathInfo. Por exemplo, imagine o seguinte fragmento de URL:

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

Depois de o ASP.NET 4 estar ativado no IIS 6, ASP.NET aplicações 2.0 que corram no IIS 6 (no Windows Server 2003 ou Windows Server 2003 R2) podem gerar erros como os seguintes:

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

Este erro ocorre porque, quando ASP.NET deteta 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 gerida da ASP.NET para processamento adicional. No entanto, se diretórios virtuais abaixo de um site ASP.NET 4 estiverem configurados para usar ASP.NET 2.0, processar a URL sem extensão desta forma resulta numa URL modificada que contém a cadeia "eurl.axd". Este URL modificado é então enviado para a aplicação ASP.NET 2.0. ASP.NET 2.0 não reconhece o formato "eurl.axd". Portanto, ASP.NET 2.0 tenta encontrar um ficheiro nomeado eurl.axd e executá-lo. Como tal ficheiro não existe, o pedido falha com uma exceção HttpException .

Pode contornar este problema usando uma das seguintes opções.

Opção 1

Se o ASP.NET 4 não for necessário para gerir o site, remapeie o site para usar ASP.NET 2.0 em vez disso.

Opção 2

Se o ASP.NET 4 for necessário para executar o site da Web, mova quaisquer diretórios virtuais filhos do ASP.NET 2.0 para um site Web diferente que esteja mapeado para o ASP.NET 2.0.

Opção 3

Se não for prático remapear o site para ASP.NET 2.0 ou alterar a localização de um diretório virtual, desative explicitamente o processamento de URLs sem extensão em ASP.NET 4. Utilize o seguinte procedimento:

  1. No registo 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 a 0. Isto desativa o comportamento de URL sem extensão.
  3. Guarde o valor do registo e feche o editor do registo.
  4. Executa a ferramenta de linha de comandos iisreset , que faz com que o IIS leia o novo valor do registo.

Observação

Definir o EnableExtensionlessUrls para 1 permite o comportamento de URL sem extensão. Esta é a definição padrão se não for especificado nenhum valor.

Os Manipuladores de Eventos podem não ser ativados num documento predefinido no modo integrado do IIS 7 ou IIS 7.5

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

ASP.NET 4 agora renderiza o valor do atributo action do elemento HTML como uma string vazia quando um pedido é feito a uma URL sem extensão que tem um documento padrão mapeado. Por exemplo, em versões anteriores de ASP.NET, um pedido a http://contoso.com resultaria num pedido a Default.aspx. Nesse documento, a etiqueta do formulário de abertura seria apresentada como no seguinte exemplo:

<form action="Default.aspx" />

Em ASP.NET 4, um pedido para http://contoso.com também resulta num pedido para Default.aspx. No entanto, ASP.NET agora renderiza a etiqueta HTML de abertura do formulário como no seguinte exemplo:

<form action="" />

Esta diferença na forma como o atributo action é renderizado pode causar alterações subtis na forma como um post de formulário é processado pelo IIS e ASP.NET. Quando o atributo action é uma string vazia, o objeto IIS DefaultDocumentModule criará um pedido filho para Default.aspx. Na maioria das circunstâncias, este pedido secundário é transparente no código da aplicação, e a Default.aspx página executa 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 fazer com que as páginas de .aspx gerenciadas parem de funcionar corretamente durante a solicitação filho. Se ocorrerem as seguintes condições, o pedido secundário para um documento Default.aspx resultará num erro ou num 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 é devolvido ao ASP.NET.
  3. Um módulo HTTP gerido lê alguma parte do corpo da entidade. Por exemplo, um módulo lê Request.Form ou Request.Params. Isso faz com que o corpo da entidade da solicitação POST seja 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 sendo executado no modo integrado do IIS 7 ou do IIS 7.5.
  4. O objeto IIS DefaultDocumentModule acaba por correr e cria um pedido filho para o Default.aspx documento. No entanto, como o corpo da entidade já foi lido por um pedaço de código gerenciado, não há nenhum corpo de entidade disponível para enviar à solicitação filho.
  5. Quando o pipeline HTTP é executado para o pedido filho, o handler para ficheiros .aspx é executado durante a fase de execução do handler.
  6. Como não existe corpo de entidade, não existem variáveis de forma nem estado de visualização, e por isso não há informação disponível para o handler de página .aspx determinar que evento (se existe) deve ser gerado. Como resultado, nenhum dos manipuladores de eventos de postback para a página de .aspx afetada é executado.

Pode contornar este comportamento das seguintes formas:

  • Identifique o módulo HTTP que está a aceder ao corpo do conteúdo do pedido durante os pedidos de documentos padrão e determine se pode ser configurado para executar somente em pedidos geridos. No modo Integrado tanto para IIS 7 como para IIS 7.5, os módulos HTTP podem ser marcados para execução apenas para pedidos geridos, adicionando o seguinte atributo à entrada system.webServer/modules do módulo:

  • precondition="managedHandler"

  • Esta configuração desativa o módulo para solicitações que o IIS 7 e o IIS 7.5 determinam como não geridas. Para requisições de documentos predefinidos, a primeira requisição é para uma URL sem extensão. Portanto, o IIS não executa módulos geridos que estejam marcados com uma pré-condição de Gestor Gerido durante o processamento inicial dos pedidos. Como resultado, os módulos geridos não lerão acidentalmente o corpo da entidade e, assim, o corpo da entidade continua disponível e é encaminhado para o pedido filho e para o documento padrão.

  • Se os módulos HTTP problemáticos tiverem de ser executados para todos os pedidos (para ficheiros estáticos, para URLs sem extensão que resolvem para o objeto DefaultDocumentModule , para pedidos geridos, etc.), modifique as páginas .aspx afetadas definindo explicitamente a propriedade Ação do controlo System.Web.UI.HtmlControls.HtmlForm da página para uma cadeia não vazia. Por exemplo, se o documento predefinido for Default.aspx, modifique o código da página para definir explicitamente a propriedade HtmlForm do controlo Action como "Default.aspx".

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

ASP.NET 2.0, e por extensão as funcionalidades ASP.NET adicionadas na 3.5, utilizam o modelo de segurança de acesso ao código (CAS) do .NET Framework 1.1 e 2.0. No entanto, a aplicação do CAS no ASP.NET 4 foi substancialmente revista. Como resultado, aplicações de confiança parcial ASP.NET que dependem de código confiável a correr na cache assembly global (GAC) podem falhar com várias exceções de segurança. Aplicações de confiança parcial que dependem de modificações extensas na política CAS da máquina também podem falhar com exceções de segurança.

Pode reverter aplicações 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 de confiança, como mostrado no seguinte exemplo:

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

Quando reverte para o modelo CAS antigo, os seguintes comportamentos antigos do CAS são ativados:

  • A política do CAS das máquinas é respeitada.
  • São permitidos múltiplos conjuntos de permissões diferentes num único domínio de aplicação.
  • Não são necessárias afirmações explícitas de permissão para assemblies na Cache Global de Assemblies (GAC) que são chamados quando apenas o ASP.NET ou outro código do .NET Framework está na stack.

Um cenário não pode ser revertido no .NET Framework 4: aplicações de confiança parcial não Web já não podem chamar certas APIs em System.Web.dll e System.Web.Extensions.dll. Em versões anteriores do .NET Framework, era possível que aplicações de confiança parcial não-Web recebessem explicitamente permissões AspNetHostingPermission . Estas aplicações poderiam então usar System.Web.HttpUtility, tipos nos espaços de nomes System.Web.ClientServices.* e tipos relacionados com adesão, funções e perfis. Já não é suportado chamar estes tipos a partir de aplicações de confiança parcial que não são Web no .NET Framework 4.

Observação

A funcionalidade HtmlEncode e HtmlDecode da classe System.Web.HttpUtility foi transferida para a nova classe .NET Framework 4 System.Net.WebUtility . Se essa fosse a única funcionalidade ASP.NET utilizada, modificava o código da aplicação para usar a nova classe WebUtility em vez disso.

Segue-se um resumo de alto nível das alterações à implementação padrão do CAS em ASP.NET 4:

  • ASP.NET domínios de aplicação são agora domínios homogéneos. Apenas conjuntos de concessões de confiança parcial e confiança total estão disponíveis num domínio de aplicação.
  • Os conjuntos de permissões de confiança parcial do ASP.NET são independentes de qualquer política CAS a nível empresarial, de máquina ou de utilizador.
  • Conjuntos do ASP.NET que foram lançados com o 3.5 e 3.5 SP1 foram convertidos para utilizar o modelo de transparência do .NET Framework 4.
  • A utilização do atributo ASP.NET AspNetHostingPermission foi substancialmente reduzida. A maioria das instâncias deste atributo foi removida das APIs ASP.NET públicas.
  • Assemblies compilados dinamicamente que são criados por provedores de build do ASP.NET foram atualizados para serem explicitamente marcados como transparentes.
  • Todas as assemblies ASP.NET estão agora marcadas de forma que o atributo APTCA é respeitado apenas em ambientes de hospedagem Web. Ambientes de alojamento não Web parcialmente confiáveis, como o ClickOnce, não poderão chamar assemblies do ASP.NET.

Para mais informações sobre o novo modelo de segurança de acesso ao código ASP.NET 4, consulte Utilização da Segurança de Acesso ao Código em ASP.NET Aplicações no site da MSDN.

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

Alguns tipos utilizados no ASP.NET Membership foram transferidos de System.Web.dll para a nova assembly System.Web.ApplicationServices.dll. Os tipos foram movidos para resolver dependências de camadas arquitetônicas entre tipos no cliente e em SKUs estendidos do .NET Framework.

Os projetos de websites não enfrentam problemas devido à mudança desses tipos, porque System.Web.ApplicationServices.dll foi adicionado à lista de assemblies referenciados que é usada por padrão pelo sistema de compilação ASP.NET. Se atualizar um projeto de site criado com uma versão anterior do ASP.NET para ASP.NET 4, abrindo-o no Visual Studio 2010, o projeto compilará sem erros.

De forma semelhante, se atualizar um projeto de aplicação Web criado numa versão anterior do ASP.NET para ASP.NET 4 ao abri-lo no Visual Studio 2010, o processo de atualização adiciona uma referência ao System.Web.ApplicationServices.dll ao projeto. Assim, os projetos de aplicações Web atualizados também compilam sem erros.

Ficheiros compilados (binários) criados com versões anteriores do ASP.NET também funcionam sem erros no ASP.NET 4, mesmo que os tipos de membro tenham sido movidos para uma assembly diferente. A informação de encaminhamento de tipos foi adicionada à versão ASP.NET 4 de System.Web.dll que encaminha automaticamente as referências em tempo de execução destes tipos para a nova localização.

No entanto, bibliotecas de classes que usam tipos de membros específicos e que foram atualizadas a partir de versões anteriores do ASP.NET falharão em compilar quando usadas num projeto ASP.NET 4. Por exemplo, um projeto de biblioteca de classes pode falhar em compilar e reportar 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.

Pode contornar este problema adicionando uma referência no projeto da sua biblioteca de aulas para System.Web.ApplicationServices.dll.

A lista seguinte mostra os tipos de System.Web.Security que foram transferidos para System.Web.dll 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.Configuração.MembroPasswordModo de CompatibilidadeT

A Cache de Saída Modifica o Cabeçalho HTTP para Variar

No ASP.NET 1.0, um bug fez com que páginas em cache que especificavam Location="ServerAndClient" como configuração de cache de saída emitissem um Vary:* cabeçalho HTTP na resposta. Isso teve o efeito de dizer aos navegadores clientes para nunca armazenar a página em cache localmente.

Na ASP.NET 1.1, foi adicionado o método System.Web.HttpCachePolicy.SetOmitVaryStar , que podia ser chamado para suprimir o Vary:* cabeçalho. Este método foi escolhido porque alterar o cabeçalho HTTP emitido era considerado uma alteração potencialmente disruptiva na altura. No entanto, os programadores ficaram confusos com o comportamento em ASP.NET, e os relatórios de bugs sugerem que os programadores desconhecem o comportamento existente do SetOmitVaryStar .

Em ASP.NET 4, foi tomada a decisão de resolver o problema de raiz. O Vary:* cabeçalho HTTP já não é emitido a partir de respostas que especificam a seguinte diretiva:

<%@OutputCache Location="ServerAndClient" %>

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

Em aplicações que especificam Location="ServerAndClient" na diretiva @ OutputCache numa página, agora verá o comportamento implícito pelo valor do atributo Localização – ou seja, as páginas serão cacheáveis no navegador sem necessidade de chamar o método SetOmitVaryStar .

Se as páginas da sua aplicação tiverem de emitir Vary:*, chame o método AppendHeader , como no seguinte exemplo:

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

Alternativamente, pode alterar o valor do atributo Localização de cache de saída para "Servidor".

System.Web.Tipos de Segurança para Passaportes estão Obsoletos

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

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

Na ASP.NET 3.5, a propriedade MenuItem.PopOutImageUrl permite-te especificar a URL de uma imagem que é exibida num item do menu para indicar que o item do menu tem um submenu dinâmico. O exemplo seguinte mostra como especificar esta propriedade na marcação em 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 em ASP.NET 4, não é apresentada saída para o PopOutImageUrl se a propriedade estiver definida para a classe MenuItem . Em vez disso, deve especificar uma URL de imagem diretamente no controlo do Menu , usando a propriedade StaticPopOutImageUrl ou a propriedade DynamicPopOutImageUrl . Quando trabalha com um menu estático, a propriedade Menu.StaticPopOutImageUrl especifica a URL de uma imagem que é apresentada para indicar que o elemento estático do menu tem um submenu, como mostrado no seguinte exemplo:

<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 estiver a trabalhar com um menu dinâmico, utiliza a propriedade Menu.DynamicPopOutImageUrl para especificar o URL de uma imagem que indica que um item dinâmico do menu tem um submenu. O exemplo seguinte é 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 falsa, nenhuma imagem é exibida. De forma semelhante, se a propriedade StaticPopOutImageUrl não estiver definida e a propriedade StaticEnableDefaultPopOutImage estiver definida como falsa, nenhuma imagem é exibida.

Quando definires os caminhos para estas propriedades, usa uma barra para a frente (/) em vez de uma barra inversa (). Para mais informações, consulte Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl falham em renderizar imagens quando os caminhos contêm barras inversas noutras partes deste documento.

Na ASP.NET 4, as imagens que especificas usando as propriedades Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl não serão renderizadas se o caminho contiver backlashes (). Isto é uma mudança em relação às versões anteriores do ASP.NET.

O exemplo seguinte de marcação de controlo do Menu mostra a propriedade StaticPopOutImageUrl definida usando um caminho que contém uma contrabarra. 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 este problema, altere os valores do caminho especificados nas propriedades StaticPopOutImageUrl e DynamicPopOutImageUrl para usar barras para frente (/). O exemplo seguinte 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>

Note que aplicações que foram migradas de versões anteriores do ASP.NET para o ASP.NET 4 também podem ser afetadas, porque a propriedade MenuItem.PopOutImageUrl foi alterada. Para mais informações, consulte A propriedade MenuItem.PopOutImageUrl falha em renderizar uma imagem em ASP.NET 4 noutro documento deste documento.

Disclaimer

Este é um documento preliminar e pode ser alterado substancialmente antes do lançamento comercial final do software aqui descrito.

As informações contidas neste documento representam a visão atual da Microsoft Corporation sobre os assuntos discutidos a partir da data de publicação. Como a Microsoft deve responder às mudanças nas condições de mercado, isso não deve ser interpretado como um compromisso por parte da Microsoft, e a Microsoft não pode garantir a precisão de quaisquer informações apresentadas após a data de publicação.

Este Livro Branco destina-se apenas a fins informativos. A MICROSOFT NÃO OFERECE GARANTIAS, EXPRESSAS, IMPLÍCITAS OU LEGAIS, RELATIVAMENTE À INFORMAÇÃO CONTIDA NESTE DOCUMENTO.

O cumprimento de todas as leis de direitos autorais aplicáveis é de responsabilidade do usuário. Sem limitar os direitos ao abrigo dos direitos de autor, nenhuma parte deste documento pode ser reproduzida, armazenada ou introduzida num sistema de recuperação, ou transmitida de qualquer forma ou por qualquer meio (eletrónico, mecânico, fotocópia, gravação ou de outra forma), ou para qualquer fim, sem a permissão expressa por escrito da Microsoft Corporation.

A Microsoft pode ter patentes, pedidos de patente, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual que abranjam o assunto deste documento. Exceto conforme expressamente previsto em qualquer contrato de licença por escrito da Microsoft, o fornecimento deste documento não concede a você nenhuma licença para essas patentes, marcas registradas, direitos autorais ou outra propriedade intelectual.

Salvo indicação em contrário, as empresas, organizações, produtos, nomes de domínio, endereços de email, logótipos, pessoas, lugares e eventos aqui representados são fictícios, e nenhuma associação com qualquer empresa, organização, produto, nome de domínio, endereço de email, logótipo, pessoa, local ou evento real é intencional ou deve ser inferida.

© 2010 Microsoft Corporation. Todos os direitos reservados.

Microsoft e Windows são marcas registadas ou marcas da Microsoft Corporation nos Estados Unidos e/ou noutros países.

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

  • Last updated on