Problemas de migração do .NET Framework 4

2025-06-19

Este artigo descreve problemas de migração entre o .NET Framework versão 3.5 Service Pack 1 e o .NET Framework versão 4, incluindo correções, alterações para conformidade e segurança de padrões e alterações com base nos comentários do cliente. A maioria dessas alterações não exige modificações de programação em seus aplicativos. Para aqueles que podem envolver modificações, consulte a coluna de alterações recomendadas da tabela. Alterações notáveis são divididas por área, por exemplo, ASP.NET e WPF (Windows Presentation Foundation).

Para obter uma visão geral de nível superior dos problemas neste artigo, consulte o Guia de Migração para o .NET Framework 4.

Para obter informações sobre novos recursos, consulte As novidades no .NET Framework 4.

ASP.NET e Web

Namespaces: System.Web, System.Web.Mobile, System.Web.Security e System.Web.UI.WebControls

Assembly: System.Web (em System.Web.dll)

Característica	Diferenças de 3.5 SP1	Alterações recomendadas
Arquivos de definição do navegador	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. O objeto HttpBrowserCapabilities (que é exposto pela propriedade `Request.Browse` da página) é controlado pelos arquivos de definição 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.	Se o aplicativo depender dos arquivos de definição do navegador antigos, você poderá copiá-los da seguinte pasta: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copie os arquivos para a pasta \CONFIG\Browsers correspondente para ASP.NET 4. Depois de copiar os arquivos, execute a ferramenta de linha de comando Aspnet_regbrowsers.exe . Para obter mais informações, consulte o https://www.asp.net/mobile site.
Aplicativos filho em execução em versões mistas do ASP.NET	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 erro específico que ocorre depende se o aplicativo é executado no IIS 6.0 ou no IIS 7 ou IIS 7.5.	Você pode fazer alterações nos arquivos de configuração dos aplicativos afetados para que o sistema de configuração reconheça corretamente o aplicativo ASP.NET 4. Para obter informações sobre as alterações que você deverá fazer, consulte a seção "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" (Aplicativos ASP.NET 4 filho falham ao iniciar nos Aplicativos ASP.NET 2.0 ou ASP.NET 3.5) no documento ASP.NET 4 Breaking Changes (Alterações recentes do ASP.NET 4) no site da Web do ASP.NET.
Alterações de ClientID	A nova `clientIDMode` configuração no ASP.NET 4 permite especificar como ASP.NET gera o `id` atributo para elementos HTML. Nas versões anteriores do ASP.NET, o comportamento padrão era equivalente à configuração `AutoID` de `clientIDMode`. A configuração padrão agora é `Predictable`. Para obter mais informações, consulte ASP.NET Identificação de Controle do Servidor Web.	Se você usar o Visual Studio para atualizar seu aplicativo do ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adicionará automaticamente uma configuração ao arquivo Web.config 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 o .NET Framework 4 de destino, ASP.NET usará o novo modo por padrão. Para desabilitar o novo modo de ID do cliente, adicione a seguinte configuração ao arquivo Web.config: `<pages clientIDMode="AutoID" />`
CAS (segurança de acesso ao código)	Recursos do ASP.NET 2.0 que foram adicionados no ASP.NET 3.5 usam o modelo CAS (segurança de acesso de código) do .NET Framework 1.1 e do .NET Framework 2.0. No entanto, a implementação do CAS no ASP.NET 4 foi substancialmente revisada. Como resultado, os aplicativos ASP.NET de confiança parcial que dependem de código confiável em execução no cache de assembly global talvez falhem com diversas exceções de segurança. Aplicativos de confiança parcial que dependem de modificações extensivas na política de CAS do sistema também podem falhar e gerar exceções de segurança.	Você pode reverter aplicações ASP.NET 4 em confiança parcial para o comportamento do ASP.NET 1.1 e 2.0 utilizando o novo atributo `legacyCasModel` no elemento de configuração `trust`, conforme mostrado no exemplo a seguir: `<trust level= "Medium" legacyCasModel="true" />` Importante: reverter para o modelo cas mais antigo pode representar segurança reduzida. Para obter mais informações sobre o novo modelo de segurança de acesso de código ASP.NET 4, consulte Segurança de Acesso ao Código em aplicativos ASP.NET 4.
Arquivos de configuração	Os arquivos de configuração raiz (o arquivo machine.config e o arquivo raiz Web.config) para .NET Framework e ASP.NET 4 foram atualizados para incluir a maior parte das informações padrão de configuração encontradas nos arquivos de aplicação Web.config no ASP.NET 3.5. Devido à complexidade dos sistemas de configuração gerenciados do IIS 7 e IIS 7.5, executar aplicativos ASP.NET 3.5 em ASP.NET 4 e no IIS 7 e IIS 7.5 pode causar erros no ASP.NET ou no IIS.	Atualize ASP.NET aplicativos 3.5 para ASP.NET 4 usando as ferramentas de atualização do projeto no Visual Studio. O Visual Studio 2010 modifica automaticamente o arquivo Web.config do aplicativo ASP.NET 3.5 para conter as configurações apropriadas para ASP.NET 4. No entanto, você pode executar ASP.NET aplicativos 3.5 usando o .NET Framework 4 sem recompilação. Nesse caso, talvez seja necessário modificar manualmente o arquivo de Web.config do aplicativo antes de executar o aplicativo no .NET Framework 4 e no IIS 7 ou IIS 7.5. A alteração específica que você deve fazer depende da combinação de software com o qual você está trabalhando, incluindo versões do Service Pack (SP). Para obter informações sobre as possíveis combinações de software afetadas por essa alteração e como resolver problemas com combinações específicas, consulte a seção "Erros de configuração relacionados à nova configuração raiz do ASP.NET 4" no documento ASP.NET 4 Alterações interruptivas no site ASP.NET.
Controle de renderização	Nas versões anteriores do ASP.NET, alguns controles emitiram marcação que você não pôde desabilitar. Por padrão, esse tipo de marcação não é mais gerado no ASP.NET 4. As alterações de renderização afetam os seguintes controles: * Os controles `Image` e `ImageButton` não renderizam mais um atributo `border="0"`. * Os `BaseValidator` controles de classe e validação que derivam dela não renderizam mais o texto vermelho por padrão. * O `HtmlForm` controle não renderiza um `name` atributo. * O `Table` controle 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 atributo `disabled="disabled"` se sua propriedade `Enabled` estiver definida como `false` (ou se herdarem essa configuração de um controle de contêiner).	Se você usar o Visual Studio para atualizar seu aplicativo do ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adicionará automaticamente uma configuração ao arquivo Web.config que preserva a renderização herdada. No entanto, se você atualizar um aplicativo alterando o pool de aplicativos no IIS para o .NET Framework 4 de destino, 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 ao arquivo Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Manipuladores de eventos em documentos padrão	ASP.NET 4 renderiza o valor do atributo do `form` elemento HTML `action` 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. Em versões anteriores do ASP.NET, uma solicitação para `http://contoso.com` resultava em uma solicitação para o Default.aspx. Nesse documento, a marca de abertura `form` seria renderizada como no exemplo a seguir: `<form action="Default.aspx" />` No ASP.NET 4, uma solicitação para `http://contoso.com` também resulta em uma solicitação para Default.aspx, mas ASP.NET agora renderiza a tag de abertura `form` HTML como no exemplo a seguir: `<form action="" />` Quando o `action` atributo é uma cadeia de caracteres vazia, o objeto IIS `DefaultDocumentModule` cria uma solicitação filho para Default.aspx. Na maioria das condições, essa solicitação filho é transparente para o código do aplicativo e a página Default.aspx é 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 ocorrerem as seguintes condições, a solicitação secundária para um documento .aspx padrão resultará em erro ou comportamento inesperado. * Uma página .aspx é enviada ao navegador com o atributo do elemento `formaction` definido como "". * O formulário é postado de volta para ASP.NET. * Um módulo HTTP gerenciado lê alguma parte do corpo da entidade, como `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. * O objeto IIS `DefaultDocumentModule` acaba sendo executado e cria uma requisição filha para o documento Default.aspx. 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. * Quando o pipeline HTTP é executado para a solicitação filho, o manipulador dos arquivos .aspx é executado durante a fase de handler-execute. Como não há nenhum corpo de entidade, não há variáveis de formulário e nenhum estado de exibição. Portanto, não há informações disponíveis 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.	Para obter informações sobre como solucionar problemas que possam surgir como resultado dessa alteração, consulte “Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode” (Manipuladores de eventos podem não ser gerados em um documento padrão no modo integrado do IIS 7 ou IIS 7.5) no documento ASP.NET 4 Breaking Changes (Alterações recentes do ASP.NET 4) no site da Web do ASP.NET.
Algoritmo de hash	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 usa o HMACSHA256 algoritmo para operações de hash em cookies e estado de exibição. Versões anteriores do ASP.NET usavam o algoritmo mais antigo HMACSHA1 .	Se você executar aplicativos que combinam ASP.NET 2.0 e ASP.NET 4, em que dados como cookies de autenticação de formulários devem funcionar em versões do .NET Framework, configure um aplicativo Web ASP.NET 4 para usar o algoritmo mais antigo HMACSHA1 adicionando a seguinte configuração no arquivo Web.config: `<machineKey validation="SHA1" />`
Controles de hosteamento no Internet Explorer	Você não pode mais hospedar controles do Windows Forms no Internet Explorer, pois há soluções melhores para hospedar controles na Web. Portanto, os assemblies IEHost.dll e IEExec.exe foram removidos do .NET Framework.	Você pode usar as seguintes tecnologias para o desenvolvimento de controle personalizado em aplicativos Web: * Você pode criar um aplicativo Silverlight e configurá-lo para ser executado fora do navegador. Para obter mais informações, consulte o suporte fora do navegador. * Você pode criar um XBAP (aplicativo de navegador XAML) para aproveitar os recursos do WPF (requer o .NET Framework em computadores cliente). Para obter mais informações, consulte Visão Geral dos Aplicativos WPF XAML para Navegador.
Métodos HtmlEncode e UrlEncode	Os métodos `HtmlEncode` e `UrlEncode` das classes HttpUtility e HttpServerUtility foram atualizados para codificar o caractere de aspas simples (') da seguinte maneira: * O `HtmlEncode` método codifica instâncias da aspa única como `'` * O `UrlEncode` método codifica instâncias da aspa única como `%27`	Examine seu código para locais onde você utiliza os métodos `HtmlEncode` e `UrlEncode`, e certifique-se de que a alteração na codificação não resulta em uma mudança que afete sua aplicação.
Erros de HttpException em aplicativos ASP.NET 2.0	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.`	* Se ASP.NET 4 não for necessário para executar o site, remapee o site para usar ASP.NET 2.0. - ou - * Caso seja necessário o ASP.NET 4 para executar o site, mova todos os diretórios virtuais filhos do ASP.NET 2.0 para um site diferente que esteja mapeado para o ASP.NET 2.0. - ou - * Desabilite URLs sem extensão. Para obter mais informações, consulte "Aplicativos ASP.NET 2.0 podem gerar erros HttpException que fazem referência a eurl.axd" no documento ASP.NET 4 Mudanças Significativas no site da ASP.NET.
Tipos de associação	Alguns tipos (por exemplo, MembershipProvider) usados na associação do ASP.NET foram movidos do System.Web.dll para o 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.	Bibliotecas de classes que foram atualizadas de versões anteriores do ASP.NET e que usam tipos de associação que foram movidos podem não ser compiladas quando usadas em um projeto ASP.NET 4. Nesse caso, adicione uma referência no projeto da biblioteca de classes para System.Web.ApplicationServices.dll.
Alterações no controle de menu	As alterações no Menu controle resultam no seguinte comportamento: * Se MenuRenderingMode estiver definido como `List`, ou se MenuRenderingMode estiver definido como `Default` e ControlRenderingCompatibilityVersion estiver definido como `4.0` ou posterior, a propriedade PopOutImageUrl não terá efeito. * Se o caminho definido nas propriedades StaticPopOutImageUrl e DynamicPopOutImageUrl contiver uma barra invertida (\), as imagens não serão renderizadas. (Nas versões anteriores do ASP.NET, o caminho podia incluir uma barra invertida.)	* Em vez de definir a PopOutImageUrl propriedade para itens de menu individuais, defina o StaticPopOutImageUrl ou DynamicPopOutImageUrl do controle pai Menu. - ou - Definir MenuRenderingMode como `Table`, ou definir MenuRenderingMode como `Default` e definir ControlRenderingCompatibilityVersion como `3.5`. Essas configurações fazem com que o Menu controle use o layout baseado em tabela HTML usado em versões anteriores do ASP.NET. *Se o caminho na propriedade StaticPopOutImageUrl ou DynamicPopOutImageUrl contiver uma barra invertida (\), substitua por um caractere de barra (/).
Assembly móvel no arquivo Web.config	Nas versões anteriores do ASP.NET, uma referência ao assembly System.Web.Mobile.dll foi incluída no arquivo Web.config raiz na seção `assemblies` em `system.web`/`compilation`. Para melhorar o desempenho, a referência a esse assembly foi removida. Observação: o assembly System.Web.Mobile.dll e os controles móveis do ASP.NET estão incluídos no ASP.NET 4, mas eles são preteridos.	Se você quiser usar tipos desse assembly, adicione uma referência ao assembly no arquivo raiz Web.config ou no arquivo de aplicativo Web.config.
Cache de saída	No ASP.NET 1.0, um bug fazia com que páginas em cache que especificavam `Location="ServerAndClient"` como uma configuração de cache de saída emitirem 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 SetOmitVaryStar foi adicionado para ser chamado e suprimir o cabeçalho `Vary:`. No entanto, relatórios de bugs sugerem que os desenvolvedores não estão cientes do comportamento existente `SetOmitVaryStar` . No ASP.NET 4, o `Vary:` cabeçalho HTTP não é mais emitido de respostas que especificam a seguinte diretiva: `<%@ OutputCache Location="ServerAndClient" %>` Como resultado, o SetOmitVaryStar método não é mais necessário para suprimir o `Vary:` cabeçalho. Em aplicativos que especificam "ServerAndClient" para o atributo, as `Location` páginas poderão ser armazenadas em cache no navegador sem exigir que você chame SetOmitVaryStar.	Se as páginas no aplicativo precisarem emitir `Vary:`, chame o AppendHeader método, conforme mostrado no exemplo a seguir: `System.Web.HttpResponse.AppendHeader("Vary","");` Como alternativa, você pode alterar o valor do atributo de cache de saída `Location` para "Servidor".
Análise de páginas	O analisador de páginas para ASP.NET páginas da Web (arquivos .aspx) e controles de usuário (arquivos.ascx) é mais estrito em ASP.NET 4 do que em versões anteriores do ASP.NET e sinaliza mais marcação como inválida do que em versões anteriores.	Examine as mensagens de erro produzidas quando uma página é executada e corrija erros resultantes de marcação inválida.
Tipos de passaporte	O suporte do Passport integrado ao ASP.NET 2.0 é obsoleto e não tem suporte devido a alterações no Passport (agora SDK da ID Dinâmica). Como resultado, os tipos relacionados ao Passport em System.Web.Security agora estão marcados com o atributo `ObsoleteAttribute`.	Altere qualquer código que utilize tipos do Passport no namespace System.Web.Security (por exemplo, PassportIdentity) para utilizar o SDK do Windows Live ID.
Informações de PathInfo na propriedade FilePath	ASP.NET 4 não inclui mais o `PathInfo` valor nos valores retornados de propriedades como FilePath, AppRelativeCurrentExecutionFilePathe CurrentExecutionFilePath. Em vez disso, as `PathInfo` informações estão disponíveis em PathInfo. Por exemplo, imagine o seguinte fragmento de URL: `/testapp/Action.mvc/SomeAction` Nas versões anteriores do ASP.NET, HttpRequest as propriedades têm os seguintes valores: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (vazio) No ASP.NET 4, as propriedades HttpRequest têm os seguintes valores: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Examine seu código para locais em que você depende das propriedades da HttpRequest classe para retornar informações de caminho; altere o código para refletir as alterações na forma como as informações de caminho são retornadas.
Validação de solicitação	Para melhorar a validação da solicitação, a validação da solicitação ASP.NET é invocada anteriormente no ciclo de vida da solicitação. Como resultado, a validação de solicitação é executada para solicitações que não são para arquivos .aspx, como para chamadas de serviço Web e para manipuladores personalizados. A validação de solicitação também estará ativa quando os módulos HTTP personalizados estiverem em execução no pipeline de processamento de solicitação. Como resultado dessa alteração, solicitações de recursos diferentes de arquivos .aspx podem gerar erros de validação de solicitação. O código personalizado executado no pipeline de solicitação (por exemplo, módulos HTTP personalizados) também pode gerar erros de validação de solicitação.	Se necessário, você pode reverter para o comportamento antigo de ter apenas .aspx páginas disparando a validação de solicitação usando a seguinte configuração no arquivo de configuração da Web: `<httpRuntime requestValidationMode="2.0" />` Aviso: se você reverter para o comportamento antigo, verifique se todo o código em manipuladores, módulos e outros códigos personalizados existentes executa verificações de entradas HTTP potencialmente inseguras que podem ser vetores de ataque XSS.
Roteamento	Se você criar um site do sistema de arquivos no Visual Studio 2010 e o site estiver em uma pasta que contenha um ponto (.) no nome da pasta, o roteamento de URL não funcionará de forma confiável. Um erro HTTP 404 é retornado de alguns caminhos virtuais. Isso ocorre porque o Visual Studio 2010 inicia o Servidor de Desenvolvimento do Visual Studio usando um caminho incorreto para o diretório virtual raiz.	* Na página Propriedades do site baseado em arquivo, altere o atributo Caminho Virtual para "/". - ou - * Crie um projeto de aplicativo Web em vez de um projeto de site. Os projetos de aplicativo Web não têm esse problema e o roteamento de URL funciona mesmo que a pasta do projeto tenha um ponto em seu nome. - ou - * Crie um site baseado em HTTP hospedado no IIS. Os sites hospedados pelo IIS podem ter pontos no caminho virtual, bem como na pasta do arquivo de projeto.
Sites do SharePoint	Se você tentar executar um site ASP.NET 4 implantado como um filho de um site do SharePoint que contém um nível de confiança parcial personalizado chamado `WSS_Minimal`, você verá o seguinte erro: `Could not find permission set named 'ASP.Net'.`	Atualmente, nenhuma versão do SharePoint é compatível com ASP.NET. Como resultado, você não deve tentar executar um site ASP.NET 4 como filho de um site do SharePoint.
Padrões XHTML 1.1	Para habilitar a conformidade do XHTML 1.1 para novos sites, os controles de ASP.NET no .NET Framework 4 gerarão HTML compatível com XHTML 1.1. Essa renderização está habilitada usando a seguinte opção no arquivo Web.config dentro do `<system.Web>` elemento: `<pages controlRenderingCompatibilityVersion="4.0"/>` Essa opção é definida por padrão como 4.0. Os projetos Web atualizados do Visual Studio 2008 têm a configuração 3.5 habilitada para compatibilidade.	Nenhum.

Núcleo