Problemas de migração do .NET Framework 4

Artigo
04/03/2023

Este artigo descreve os 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 dos clientes. A maioria dessas alterações não requer a modificação da programação dos seus aplicativos. Para aquelas que podem envolver modificações, confira a coluna 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 resumida dos problemas neste artigo, confira Guia de migração para o .NET Framework 4.

Para saber mais sobre novos recursos, confira 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)

Recurso	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 dispositivos e navegadores novos e atualizados. Navegadores e dispositivos mais antigos como o Netscape Navigator foram removidos e navegadores e dispositivos mais novos como o Google Chrome e Apple iPhone foram adicionados. Se seu aplicativo contiver definições do navegador personalizadas herdadas de uma das definições do navegador que foram removidas, você verá um erro. O objeto HttpBrowserCapabilities (exposto pela propriedade da página `Request.Browse`) é orientada pelos arquivos de definição do navegador. Portanto, as informações retornadas ao acessar uma propriedade desse objeto no ASP.NET 4 talvez sejam diferentes das informações retornadas em uma versão anterior do ASP.NET.	Se seu aplicativo depender dos antigos arquivos de definição do navegador, será possível copiá-los da pasta a seguir: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers No caso do ASP.NET 4, copie os arquivos para a pasta \CONFIG\Browsers correspondente. Depois de copiar os arquivos, execute a ferramenta de linha de comando Aspnet_regbrowsers.exe. Para obter mais informações, consulte o site https://www.asp.net/mobile.
Aplicativos filho em execução em diferentes versões do ASP.NET	Os aplicativos ASP.NET 4 configurados como filhos de aplicativos que executam versões anteriores do ASP.NET talvez falhem ao iniciar devido a erros de configuração ou de compilação. O erro específico que ocorre depende se o aplicativo é executado no IIS 6.0 ou no IIS 7 ou no IIS 7.5.	É possível 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 da ClientID	A nova configuração `clientIDMode` no ASP.NET 4 permite especificar como o ASP.NET gera o atributo `id` para elementos HTML. Nas versões anteriores do ASP.NET, o comportamento padrão era equivalente à configuração `AutoID` do `clientIDMode`. A configuração padrão agora é `Predictable`. Para obter mais informações, consulte ASP.NET Web Server Control Identification (Identificação de controles do servidor Web do ASP.NET).	Se você usar o Visual Studio para atualizar seu aplicativo do ASP.NET 2.0 ou 3.5, a ferramenta adicionará automaticamente uma configuração ao arquivo Web.config para preservar o comportamento das versões anteriores do .NET Framework. No entanto, se você atualizar um aplicativo alterando o pool de aplicativos no IIS com relação ao .NET Framework 4, o ASP.NET usará o novo modo por padrão. Para desabilitar o novo modo da ID do cliente, adicione a seguinte configuração ao arquivo Web.config: `<pages clientIDMode="AutoID" />`
CAS (Segurança de Acesso do Código)	Os recursos NET do ASP.NET 2.0 que foram adicionados no ASP.NET 3.5 usam o modelo CAS (Segurança de Acesso do Código) do .NET Framework 1.1 e .NET Framework 2.0. No entanto, a implementação da 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 grandes modificações na política de CAS do computador talvez falhem e gerem exceções de segurança também.	É possível reverter 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 `trust`, conforme mostrado no exemplo a seguir: `<trust level= "Medium" legacyCasModel="true" />` Importante: reverter para o modelo CAS mais antigo talvez represente menos segurança. Para obter mais informações sobre o novo modelo de segurança de acesso do código do ASP.NET 4, consulte Segurança de acesso do código em aplicativos ASP.NET 4.
Arquivos de configuração	Os arquivos de configuração raiz (o arquivo machine.config e o arquivo Web.config raiz) para .NET Framework e ASP.NET 4 foram atualizados para incluir a maioria das informações de configuração padrão encontradas nos arquivos Web.config do aplicativo no ASP .NET 3.5. Devido à complexidade dos sistemas de configuração do IIS 7 e IIS 7.5 gerenciados, executar aplicativos ASP.NET 3.5 no ASP.NET 4 e no IIS 7 e IIS 7.5 pode resultar em erros do ASP.NET ou do IIS.	Atualize os aplicativos ASP.NET 3.5 para ASP.NET 4 usando as ferramentas de atualização de 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 do ASP.NET 4. No entanto, é possível executar aplicativos ASP.NET 3.5 usando o .NET Framework 4 sem recompilação. Nesse caso, talvez seja necessário modificar manualmente o arquivo Web.config do aplicativo antes de executá-lo no .NET Framework 4 e no IIS 7 ou 7.5. A alteração específica que é necessário ser feita depende da combinação de software com a qual você está trabalhando, incluindo as versões do SP (Service Pack). Para obter informações sobre as combinações de software possíveis 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 Breaking Changes (Alterações recentes do ASP.NET 4) no site da Web do ASP.NET.
Renderização de controles	Em versões anteriores do ASP.NET, alguns controles emitiam marcação que não podiam ser desabilitadas. 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"`. * A classe `BaseValidator` e os controles de validação derivados dela não renderizam mais texto vermelho por padrão. * O controle `HtmlForm` não renderiza um atributo `name`. * O controle `Table` não renderiza mais um atributo `border="0"`. Os controles que não foram projetados para a entrada de usuário (por exemplo, o controle `Label`) não renderizarão mais o atributo `disabled="disabled"` se sua propriedade `Enabled` for definida como `false` (ou se eles herdarem essa configuração de uma caixa de controles).	Se você usar o Visual Studio para atualizar seu aplicativo do ASP.NET 2.0 ou do ASP.NET 3.5, a ferramenta adicionará automaticamente uma configuração ao arquivo Web.config que preservará a renderização herdada. No entanto, ao atualizar um aplicativo alterando o pool de aplicativos no IIS com relação ao .NET Framework 4, o ASP.NET usará o novo modo de renderização por padrão. Para desabilitar o novo modo de renderização, adicione a seguinte configuração ao arquivo Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Manipuladores de eventos em documentos padrão	O ASP.NET 4 renderiza o valor de atributo `form` do elemento HTML `action` como uma cadeia de caracteres vazia quando uma solicitação é feita para uma URL sem extensão que tem um documento padrão mapeado para ela. Em versões anteriores do ASP.NET, uma solicitação para `http://contoso.com` resultaria em uma solicitação para Default.aspx. Nesse documento, a marca `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 resulta em uma solicitação para Default.aspx, mas agora o ASP.NET renderiza a marca `form` de abertura HTML como no exemplo a seguir: `<form action="" />` Quando o atributo `action` é uma cadeia de caracteres vazia, o objeto `DefaultDocumentModule` do IIS 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 eventual interação entre código gerenciado e o modo integrado do IIS 7 ou IIS 7.5 pode fazer páginas .aspx gerenciadas pararem de funcionar adequadamente durante a solicitação filho. Se ocorrerem as condições a seguir, a solicitação filho para um documento .aspx padrão resultará em um erro ou em um comportamento inesperado: * Uma página .aspx é enviada ao navegador com o atributo `action` do elemento `form` definido como "". * O formulário é publicado de volta no 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 quaisquer módulos de código nativo em execução no modo integrado do IIS 7 ou do IIS 7.5. * Em algum momento, o objeto `DefaultDocumentModule` do IIS é executado e cria uma solicitação filho 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, há nenhuma variável de formulário e nenhum estado de exibição. Portanto, não há nenhuma informação disponível para o manipulador de página .aspx para determinar qual evento (se houver) deve ser gerado. Como resultado, nenhum manipulador de eventos de postback para a página .aspx afetada é executado.	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	O ASP.NET usa algoritmos de hash e criptografia para ajudar a proteger dados como cookies de autenticação de formulários e estado de exibição. Por padrão, o ASP.NET 4 usa o algoritmo HMACSHA256 para operações de hash em cookies e estado de exibição. As versões anteriores do ASP.NET usavam o algoritmo HMACSHA1 mais antigo.	Se você executar aplicativos que combinam o ASP.NET 2.0 e o ASP.NET 4, em que dados como os 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 HMACSHA1 mais antigo adicionando a seguinte configuração no arquivo Web.config: `<machineKey validation="SHA1" />`
Hospedando controles no Internet Explorer	Não é mais possível hospedar controles do Windows Forms no Internet Explorer, porque há soluções melhores para hospedar controles na Web. Portanto, os assemblies IEHost.dll e IEExec.exe foram removidos do .NET Framework.	É possível usar as seguintes tecnologias para o desenvolvimento de controles personalizados em aplicativos Web: * É possível criar um aplicativo Silverlight e configurá-lo para ser executado fora do navegador. Para obter mais informações, consulte Out-of-Browser Support (Suporte à execução fora do navegador). *É possível 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 de aplicativos de navegador XAML WPF.
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 método `HtmlEncode` codifica instâncias de aspas simples como `'` * O método `UrlEncode` codifica instâncias de aspas simples como `%27`	Em seu código, procure locais nos quais você usa os métodos `HtmlEncode` e `UrlEncode`, e certifique-se de que a alteração na codificação não resulte em uma alteração que possa afetar seu aplicativo.
Erros HttpException em aplicativos ASP.NET 2.0	Depois que o ASP.NET 4 tiver sido habilitado no IIS 6, os aplicativos ASP.NET 2.0 executados no IIS 6 (no Windows Server 2003 ou Windows Server 2003 R2) poderão gerar erros como o seguinte: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Se não for necessário ter o ASP.NET 4 para executar o site da Web, remapeie o site para usar o ASP.NET 2.0. -ou- * Se for necessário ter o ASP.NET 4 para executar o site da Web, mova quaisquer diretórios virtuais do ASP.NET 2.0 filho para um site da Web diferente 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 referenciam eurl.axd" no documento ASP.NET 4 Breaking Changes (Alterações recentes do ASP.NET 4) no site da Web do 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 de arquitetura entre os tipos no cliente e nos SKUs do .NET Framework estendido.	As bibliotecas de classes que foram atualizadas de versões anteriores do ASP.NET e que usarem os tipos de associação movidos poderão falhar ao compilar quando usadas em um projeto do ASP.NET 4. Nesse caso, adicione uma referência no projeto da biblioteca de classes ao System.Web.ApplicationServices.dll.
Alterações no Controle de menu	Alterações no controle Menu resultam no seguinte comportamento: * Se MenuRenderingMode for definido como `List` ou se MenuRenderingMode for definido como `Default` e ControlRenderingCompatibilityVersion for definido como `4.0` ou posterior, a propriedade PopOutImageUrl não terá nenhum 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 configurar a propriedade PopOutImageUrl para itens de menu individuais, defina o StaticPopOutImageUrl ou DynamicPopOutImageUrl do controle pai Menu. -ou- Defina MenuRenderingMode como `Table` ou defina MenuRenderingMode como `Default` e defina ControlRenderingCompatibilityVersion como `3.5`. Essas configurações fazem o controle Menu usar 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ê desejar usar tipos desse assembly, adicione uma referência ao assembly no arquivo Web.config raiz ou em um arquivo Web.config do aplicativo.
Cache de saída	No ASP.NET 1.0, um bug fazia com que as páginas em cache que especificavam `Location="ServerAndClient"` como uma configuração de cache de saída emitissem um cabeçalho HTTP `Vary:` na resposta. O efeito disso era informar os navegadores de clientes a nunca armazenar a página em cache localmente. No ASP.NET 1.1, o método SetOmitVaryStar foi adicionado, que poderia ser chamado para suprimir o cabeçalho `Vary:`. No entanto, os relatórios de bugs sugerem que os desenvolvedores não têm conhecimento do comportamento `SetOmitVaryStar` existente. No ASP.NET 4, o cabeçalho HTTP `Vary:` não é mais emitido com base em respostas que especificam a seguinte diretiva: `<%@ OutputCache Location="ServerAndClient" %>` Como resultado, o método SetOmitVaryStar não é mais necessário para suprimir o cabeçalho `Vary:`. Em aplicativos que especificam "ServerAndClient" para o atributo `Location`, as páginas poderão ser armazenadas em cache no navegador sem a necessidade de chamar SetOmitVaryStar.	Se as páginas do aplicativo precisarem emitir `Vary:`, chame o método AppendHeader conforme mostrado no exemplo a seguir: `System.Web.HttpResponse.AppendHeader("Vary","");` Ou é possível alterar o valor do atributo `Location` do cache de saída para "Servidor".
Análise da página	O analisador de página para páginas da Web do ASP.NET (arquivos .aspx) e controles de usuário (arquivos .ascx) é mais rígido no ASP.NET 4 do que em versões anteriores do ASP.NET e ele sinaliza mais marcações como inválidas do que em versões anteriores.	Examine mensagens de erro produzidas quando uma página é executada e corrigem erros resultantes de marcação inválida.
Tipos de Passport	O suporte ao Passport incorporado no ASP.NET 2.0 é obsoleto e não tem mais suporte devido a alterações no Passport (agora SDK do Live ID). Como resultado, agora os tipos relacionados ao Passport no System.Web.Security são marcados com o atributo `ObsoleteAttribute`.	Altere qualquer código que use tipos Passport no namespace System.Web.Security (por exemplo, PassportIdentity) para usar o SDK do Windows Live ID.
Informação PathInfo na propriedade FilePath	O ASP.NET 4 não inclui mais o valor `PathInfo` nos valores de retorno de propriedades como FilePath, AppRelativeCurrentExecutionFilePath e CurrentExecutionFilePath. Em vez disso, as informações `PathInfo` do estão disponíveis em PathInfo. Por exemplo, imagine o fragmento da URL a seguir: `/testapp/Action.mvc/SomeAction` Em versões anteriores do ASP.NET, as propriedades HttpRequest têm os seguintes valores: * 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`	Em seu código, examine os locais nos quais você depende de propriedades da classe HttpRequest para retornar as informações do caminho; altere o código para refletir as alterações na maneira como as informações do caminho são retornadas.
Validação de solicitação	Para melhorar a validação de solicitação, a validação de solicitação do 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 sendo executados no pipeline de processamento da solicitação. Em decorrência dessa alteração, as solicitações de recursos que não sejam arquivos .aspx talvez gerem erros de validação de solicitação. Código personalizado executado no pipeline de solicitação (por exemplo, módulos HTTP personalizados) talvez gerem também erros de validação de solicitação.	Se necessário, é possível reverter para o antigo comportamento de ter apenas páginas .aspx disparando validação de solicitação por meio da seguinte configuração no arquivo de configuração da Web: `<httpRuntime requestValidationMode="2.0" />` Aviso: ao reverter para o comportamento antigo, verifique se todos os códigos em manipuladores, módulos e outros códigos personalizados existentes executam verificações de entradas HTTP potencialmente inseguras que podem ser vetores de ataque XSS.
Roteamento	Se você criar um site da Web do sistema de arquivos no Visual Studio 2010 e ele estiver em uma pasta que contenha um ponto (.) no nome da pasta, o roteamento de URL não funcionará com segurança. Um erro 404 de HTTP é retornado de alguns caminhos virtuais. Isso ocorre porque o Visual Studio 2010 abre o Visual Studio Development Server que usa um caminho incorreto para o diretório virtual raiz.	* Na página Propriedades do site da Web baseado em arquivo, altere o atributo Caminho virtual para "/". -ou- * Crie um projeto de aplicativo Web em vez de um projeto de site da Web. Os projetos de aplicativo Web não apresentam esse problema e o roteamento de URL funcionará mesmo se a pasta de projeto tiver um ponto no nome. -ou- * Crie um site da Web baseado em HTTP hospedado no IIS. Os sites da Web hospedados pelo IIS podem ter pontos do caminho virtual, bem como a pasta do arquivo de projeto.
Sites do SharePoint	Se você tentar executar um site da Web ASP.NET 4 implantado como filho de um site da Web do SharePoint que contém um nível de confiança parcial personalizado nomeado `WSS_Minimal`, você verá o seguinte erro: `Could not find permission set named 'ASP.Net'.`	No momento, nenhuma versão do SharePoint é compatível com o ASP.NET. Como resultado, você não deverá tentar executar um site da Web do ASP.NET 4 como um filho de um site da Web do SharePoint.
Padrões XHTML 1.1	A fim de habilitar a conformidade com XHTML 1.1 para novos sites, os controles do ASP.NET no .NET Framework 4 gerarão um HTML compatível com XHTML 1.1. Essa renderização é habilitada usando a seguinte opção no arquivo Web.config dentro do elemento `<system.Web>`: `<pages controlRenderingCompatibilityVersion="4.0"/>` Essa opção é definida, por padrão, como 4.0. Os projetos da Web atualizados do Visual Studio 2008 têm a configuração 3.5 habilitada para compatibilidade.	Nenhum.

Núcleo