Problemas de migração do .NET Framework 4

Artigo
10/04/2023

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 dos clientes. A maioria dessas alterações não requer nenhuma modificação de programação em seus aplicativos. Para aqueles que podem envolver modificações, consulte a coluna Alterações recomendadas da tabela. Alterações notáveis são divididas por área, por exemplo, ASP.NET e Windows Presentation Foundation (WPF).

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

Para obter informações sobre novos recursos, consulte O que há de novo no .NET Framework 4.

ASP.NET e Web

Espaços para nomes: System.Web, System.Web.Mobile, System.Web.Security, , System.Web.UI.WebControls

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

Caraterística	Diferenças do 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 seu aplicativo contiver definições de navegador personalizadas que herdam de uma das definições de navegador que foram removidas, você verá um erro. O HttpBrowserCapabilities objeto (que é exposto pela propriedade da `Request.Browse` página) é conduzido pelos arquivos de definição do navegador. Portanto, as informações que são retornadas acessando uma propriedade deste objeto no ASP.NET 4 podem ser diferentes das informações que foram retornadas em uma versão anterior do ASP.NET.	Se o seu aplicativo depende dos arquivos de definição do navegador antigos, você pode copiá-los da seguinte pasta: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Navegadores 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 executados 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ê deve fazer, consulte a seção "ASP.NET 4 Aplicativos filho falharem ao iniciar quando sob ASP.NET 2.0 ou ASP.NET 3.5 Aplicativos" no documento ASP.NET 4 Alterações de quebra no site ASP.NET.
Alterações de ID do Cliente	A nova `clientIDMode` configuração no ASP.NET 4 permite especificar como ASP.NET gera o `id` atributo para elementos HTML. Em versões anteriores do ASP.NET, o comportamento padrão era equivalente à `AutoID` configuração de `clientIDMode`. A configuração padrão agora `Predictable`é . Para obter mais informações, consulte ASP.NET identificação de controle de 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 desativar o novo modo de ID do cliente, adicione a seguinte configuração ao arquivo Web.config: `<pages clientIDMode="AutoID" />`
Segurança de acesso ao código (CAS)	ASP.NET recursos do 2.0 NET que foram adicionados no ASP.NET 3.5 usam o modelo CAS (segurança de acesso ao código) do .NET Framework 1.1 e do .NET Framework 2.0. No entanto, a aplicação do CAS no ASP.NET 4 foi substancialmente revista. Como resultado, os aplicativos de confiança parcial ASP.NET que dependem de código confiável em execução no cache de assembly global podem falhar com várias exceções de segurança. Aplicativos de confiança parcial que dependem de extensas modificações na política CAS da máquina também podem falhar e lançar exceções de segurança.	Você pode reverter a confiança parcial ASP.NET 4 aplicativos para o comportamento do ASP.NET 1.1 e 2.0 usando o novo `legacyCasModel` atributo no `trust` elemento configuration, 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 ao código do ASP.NET 4, consulte Segurança de acesso ao código em aplicativos do 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 clichê encontradas nos arquivos Web.config do aplicativo no ASP.NET 3.5. Devido à complexidade dos sistemas de configuração gerenciados do IIS 7 e do IIS 7.5, a execução de aplicativos ASP.NET 3.5 no ASP.NET 4 e no IIS 7 e no IIS 7.5 pode resultar em erros de ASP.NET ou erros do IIS.	Atualize ASP.NET aplicativos 3.5 para o 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 para o ASP.NET 4. No entanto, você pode 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 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 a qual você está trabalhando, incluindo versões do Service Pack (SP). Para obter informações sobre as possíveis combinações de software que são 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 no site ASP.NET.
Renderização de controle	Em versões anteriores do ASP.NET, alguns controles emitiam marcações que você não podia desativar. 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 `Image` controles e `ImageButton` não renderizam mais um `border="0"` atributo. * Os `BaseValidator` controles de classe e validação que derivam dele não renderizam mais 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 são projetados para entrada do usuário (por exemplo, o `Label` controle) não renderizam mais o `disabled="disabled"` atributo se sua `Enabled` propriedade 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 desativar 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 `action` atributo do elemento HTML `form` 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, um pedido para `http://contoso.com` resultaria em um pedido para Default.aspx. Nesse documento, a tag 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 fazer com que as páginas de .aspx gerenciadas parem de funcionar corretamente durante a solicitação filho. Se as seguintes condições ocorrerem, a solicitação filho para um documento de .aspx padrão resultará em um erro ou em um comportamento inesperado: * Uma página .aspx é enviada para o navegador com o `form` atributo do `action` elemento definido como "". * O formulário é enviado 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 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. * O objeto IIS `DefaultDocumentModule` eventualmente é executado e cria uma solicitação filho para o documento Default.aspx. 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. * Quando o pipeline HTTP é executado para a solicitação filho, o manipulador para arquivos .aspx é executado durante a fase handler-execute. Como não há 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 determinar qual evento (se houver) deve ser gerado. Como resultado, nenhum dos manipuladores de eventos de postback para a página de .aspx afetada é executado.	Para obter informações sobre maneiras de contornar problemas que podem surgir como resultado dessa alteração, consulte "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 Alterações recentes no site da ASP.NET.
Algoritmo de hash	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 padrão, o ASP.NET 4 usa o HMACSHA256 algoritmo para operações de hash em cookies e estado de exibição. As versões anteriores do ASP.NET usavam o algoritmo mais antigo HMACSHA1 .	Se você executar aplicativos que misturam ASP.NET 2.0 e ASP.NET 4, onde 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 hospedagem no Internet Explorer	Você não pode mais 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.	Você pode usar as seguintes tecnologias para 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 Suporte fora do navegador. * Você pode criar um aplicativo de navegador XAML (XBAP) para aproveitar os recursos do WPF (requer o .NET Framework em máquinas cliente). Para obter mais informações, consulte Visão geral de aplicativos de navegador WPF XAML.
Métodos HtmlEncode e UrlEncode	Os `HtmlEncode` métodos e `UrlEncode` das HttpUtility classes e foram atualizados para codificar o caractere HttpServerUtility de aspas simples (') da seguinte maneira: * O `HtmlEncode` método codifica instâncias das aspas simples como `'` * O `UrlEncode` método codifica instâncias das aspas simples como `%27`	Examine seu código para locais onde você usa os `HtmlEncode` métodos e `UrlEncode` e certifique-se de que a alteração na codificação não resulte em uma alteração que afetaria 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 no Windows Server 2003 R2) podem gerar erros como os seguintes: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Se o ASP.NET 4 não for necessário para executar o site, remapeie o site para usar o ASP.NET 2.0. -ou- * Se o ASP.NET 4 for necessário para executar o site, mova qualquer diretório virtual filho ASP.NET 2.0 para um site diferente que esteja mapeado para ASP.NET 2.0. -ou- * Desative URLs sem extensão. Para obter mais informações, consulte "ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd" no documento ASP.NET 4 Breaking Changes no site ASP.NET.
Tipos de associação	Alguns tipos (por exemplo, MembershipProvider) que são usados em ASP.NET associação foram movidos de System.Web.dll para o 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.	As bibliotecas de classes que foram atualizadas de versões anteriores do ASP.NET e que usam tipos de associação que foram movidos podem falhar na compilação quando usadas em um projeto do ASP.NET 4. Em caso afirmativo, adicione uma referência no projeto de biblioteca de classes ao 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 PopOutImageUrl propriedade não terá efeito. * Se o caminho definido nas StaticPopOutImageUrl propriedades e DynamicPopOutImageUrl contiver uma barra invertida (\), as imagens não serão renderizadas. (Em 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- Defina MenuRenderingMode como `Table`, ou defina MenuRenderingMode como `Default` e defina ControlRenderingCompatibilityVersion como `3.5`. Essas configurações fazem com que o Menu controle use o layout baseado em tabela HTML que ele usou em versões anteriores do ASP.NET. * Se o caminho na StaticPopOutImageUrl propriedade ou DynamicPopOutImageUrl contiver uma barra invertida (\), substitua um caractere de barra (/).
Assembly móvel no arquivo Web.config	Em versões anteriores do ASP.NET, uma referência ao assembly System.Web.Mobile.dll foi incluída no arquivo Web.config raiz na `assemblies` seção em/`system.webcompilation` . Para melhorar o desempenho, a referência a este assembly foi removida. Nota: O conjunto System.Web.Mobile.dll e os controles móveis ASP.NET estão incluídos no ASP.NET 4, mas foram preteridos.	Se você quiser 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 fez com que páginas armazenadas em cache que especificavam `Location="ServerAndClient"` como uma 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 SetOmitVaryStar método, que poderia ser chamado para suprimir o `Vary:` cabeçalho. No entanto, os 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 a partir 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 devem emitir `Vary:`, chame o AppendHeader método como mostrado no exemplo a seguir: `System.Web.HttpResponse.AppendHeader("Vary","");` Como alternativa, você pode alterar o valor do atributo de cache `Location` de saída para "Server".
Análise de páginas	O analisador de página para páginas da Web ASP.NET (arquivos .aspx) e controles de usuário (arquivos .ascx) é mais rigoroso no 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 que são 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 está obsoleto e não é suportado devido a alterações no Passport (agora Live ID SDK). Como resultado, os tipos relacionados ao Passport in System.Web.Security agora são marcados com o `ObsoleteAttribute` atributo.	Altere qualquer código que use tipos do System.Web.Security Passport no namespace (por exemplo, PassportIdentity) para usar o SDK do Windows Live ID.
Informações PathInfo na propriedade FilePath	ASP.NET 4 não inclui mais o `PathInfo` valor nos valores de retorno 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` Em 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, HttpRequest as propriedades têm os seguintes valores: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Examine seu código em busca de locais onde você confia nas propriedades da classe para retornar informações de caminho, altere o código para refletir as alterações em como as informações de HttpRequest caminho são retornadas.
Solicitar validaçã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 manipuladores personalizados. A validação de solicitação também estará ativa quando módulos HTTP personalizados estiverem em execução no pipeline de processamento de solicitações. 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 acionando 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, certifique-se de que todo o código em manipuladores, módulos e outros códigos personalizados existentes execute verificações de entradas HTTP potencialmente inseguras que possam ser vetores de ataque XSS.
Encaminhamento	Se você criar um site de sistema de arquivos no Visual Studio 2010 e o site estiver em uma pasta que contém 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 Visual Studio Development Server 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 aplicação 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 se a pasta do projeto tiver um ponto em seu nome. -ou- * Crie um site baseado em HTTP que esteja hospedado no IIS. Os sites hospedados no IIS podem ter pontos no caminho virtual, bem como na pasta do arquivo do projeto.
Sites do SharePoint	Se você tentar executar um site do ASP.NET 4 que é implantado como 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 o ASP.NET. Como resultado, você não deve tentar executar um site do ASP.NET 4 como filho de um site do SharePoint.
Padrões XHTML 1.1	Para habilitar a conformidade com XHTML 1.1 para novos sites, os controles ASP.NET no .NET Framework 4 gerarão HTML compatível com XHTML 1.1. Essa renderização é habilitada usando a seguinte opção no arquivo Web.config dentro do `<system.Web>` elemento : `<pages controlRenderingCompatibilityVersion="4.0"/>` Esta opção é definida por padrão como 4.0. Projetos da Web que são atualizados do Visual Studio 2008 têm a configuração 3.5 habilitada para compatibilidade.	Nenhum.

Principal

Características gerais

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Espaço CardSpace	O Windows CardSpace não está mais incluído no .NET Framework; é fornecido separadamente.	Transfira o Windows CardSpace a partir do Centro de Transferências da Microsoft.
Arquivos de configuração	Foram feitas correções na forma como o .NET Framework acessa os arquivos de configuração do aplicativo.	Se o arquivo de configuração do aplicativo for chamado application-name.config, renomeie-o para application-name.exe.config. Por exemplo, renomeie MyApp.config para MyApp.exe.config.
Compilador de código C#	As `Compiler`classes , `CompilerError`e `ErrorLevel` que estavam no Microsoft.CSharp namespace não estão mais disponíveis e seu assembly (cscompmgd.dll) não está mais incluído no .NET Framework.	Use a CodeDomProvider classe e outras classes no System.CodeDom.Compiler namespace. Para obter mais informações, consulte Usando o CodeDOM.
Hospedagem (API não gerenciada)	Para melhorar os recursos de hospedagem, algumas das APIs de ativação de hospedagem foram preteridas. Os recursos de execução lado a lado em processo permitem que um aplicativo carregue e inicie várias versões do .NET Framework no mesmo processo. Por exemplo, você pode executar aplicativos que carregam suplementos (ou componentes) baseados no .NET Framework 2.0 SP1 e suplementos baseados no .NET Framework 4 no mesmo processo. Os componentes mais antigos continuam a usar a versão mais antiga do .NET Framework e os novos componentes usam a nova versão do .NET Framework.	Use as configurações descritas em Execução lado a lado em processo.
Novo modelo de segurança	A diretiva de segurança de acesso ao código (CAS) foi desativada e substituída por um modelo simplificado, conforme descrito em Alterações de segurança no .NET Framework 4.	Modificações podem ser necessárias se você depender do CAS em seus aplicativos. Para obter mais informações, consulte Compatibilidade e migração da política de segurança de acesso ao código.

Data e hora

Espaço de nomes: System

Montagem: mscorlib (em mscorlib.dll)

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Horário de verão	Para ser consistente com o relógio do sistema, as propriedades de hora (como Local e Now) agora usam regras do sistema operacional em vez de outros dados do .NET Framework para operações de horário de verão.	Nenhum.
Formatando cadeias de caracteres	Para suportar a `ToString`formatação sensível à cultura, a TimeSpan estrutura inclui novas sobrecargas do , e `TryParse` métodos, `Parse`além de novos `ParseExact` e `TryParseExact` métodos.	Nenhum.

Globalização

Para obter uma lista de novas culturas neutras e específicas, consulte O que há de novo na globalização e localização.

Espaço de nomes: System.Globalization

Montagem: mscorlib (em mscorlib.dll)

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Nomes de culturas	As seguintes alterações de nome afetam as culturas alemã, divehi e africana: * CurrencyEnglishName: O nome da moeda para a cultura alemã (Suíça) (de-CH) mudou de "sFr." para "Fr.". * LongDatePattern: O padrão de data longa para a cultura Divehi (Maldivas) (dv-MV) mudou de "dd/MMMM/aaaa" para "dd/MM/aaaa". * PMDesignator: O designador P.M. da cultura africâner (África do Sul) (af-ZA) mudou de "nm" para "PM".	Observe as alterações de nome da cultura.
Parâmetro LCID	Para ser consistente com o comportamento esperado nas configurações do servidor de automação, o CLR não passa mais a cultura atual do parâmetro para `LCID` aplicativos baseados em COM não gerenciados. Em vez disso, passa de 1033 (en-us) para a cultura.	Nenhuma modificação necessária, exceto para aplicativos nativos que exigem uma cultura especificada.
Tipos de cultura obsoletos	Os CultureTypes tipos e CultureTypes cultura estão agora obsoletos. Para compatibilidade com versões anteriores, CultureTypes agora retorna culturas neutras e específicas que foram incluídas com o .NET Framework anterior e CultureTypes agora retorna uma lista vazia.	Use outros valores da CultureTypes enumeração.
Recuperando a cultura	A partir do Windows 7, o .NET Framework 4 recupera informações de cultura do sistema operacional em vez de armazenar os próprios dados. Além disso, o .NET Framework sincroniza com o Windows para classificar e invólucro de dados.	Nenhum.
Padrões Unicode 5.1	O .NET Framework agora suporta todos os caracteres Unicode 5.1 -- uma adição de aproximadamente 1400 caracteres. Os caracteres adicionais incluem novos símbolos, setas, diacríticos, pontuação, símbolos matemáticos, traços CJK e ideógrafos, caracteres numéricos adicionais malaiala e telugu, e vários caracteres de Mianmar, latim, árabe, grego, mongol e cirílico. Os seguintes novos scripts são suportados com Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu, e Malayalam caracteres e Cham.	Nenhum.

Exceções

Espaços para nomes: System, System.Runtime.ExceptionServices

Montagem: mscorlib (em mscorlib.dll)

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Exceções para o estado do processo corrompido	O CLR não fornece mais exceções para o estado do processo corrompido para manipuladores de exceção no código gerenciado.	Essas exceções indicam que o estado de um processo foi corrompido. Não recomendamos que você execute seu aplicativo nesse estado. Para obter mais informações, consulte a HandleProcessCorruptedStateExceptionsAttribute entrada e Manipulando exceções de estado corrompido na revista MSDN.
Exceções do mecanismo de execução	ExecutionEngineException está agora obsoleta, porque uma exceção que pode ser capturada permitirá que um processo instável continue a ser executado. Essa alteração melhora a previsibilidade e a confiabilidade no tempo de execução.	Use um InvalidOperationException para sinalizar a condição.

Reflexão

Espaço de nomes: System.Reflection

Montagem: mscorlib (em mscorlib.dll)

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Algoritmos de hash de montagem	A HashAlgorithm propriedade agora retorna AssemblyHashAlgorithm, porque o tempo de execução não conhece o algoritmo de hash do assembly referenciado quando o assembly não é carregado. (Isso se refere ao uso da propriedade em um assembly referenciado, como o GetReferencedAssemblies retornado pelo método.)	Nenhum.
Carregamento da montagem	Para evitar o carregamento redundante de assemblies e economizar espaço de endereço virtual, o CLR agora carrega assemblies usando apenas a função Win32 `MapViewOfFile` . Já não chama também a `LoadLibrary` função. Essa alteração afeta os aplicativos de diagnóstico das seguintes maneiras: * A ProcessModuleCollection não conterá mais módulos de uma biblioteca de classes (arquivo .dll), conforme obtido a partir de uma chamada para `Process.GetCurrentProcess().Modules`. * Os aplicativos Win32 que usam a `EnumProcessModules` função não verão todos os módulos gerenciados listados.	Nenhum.
Declarando o tipo	A DeclaringType propriedade agora retorna corretamente null quando o tipo não tem um tipo de declaração.	Nenhum.
Delegados	Um delegado agora lança um ArgumentNullException em vez de um NullReferenceException quando um valor nulo é passado para o construtor do delegado.	Certifique-se de que qualquer tratamento de exceção captura.ArgumentNullException
Alteração do local do cache de assembly global	Para assemblies do .NET Framework 4, o cache de assembly global foi movido do diretório do Windows (%WINDIR%) para o subdiretório Microsoft.Net (%WINDIR%\Microsoft.Net). Os assemblies de versões anteriores permanecem no diretório mais antigo. A enumeração ASM_CACHE_FLAGS não gerenciada contém o novo `ASM_CACHE_ROOT_EX` sinalizador. Esse sinalizador obtém o local do cache para assemblies do .NET Framework 4, que pode ser obtido pela função GetCachePath .	Nenhum, supondo que os aplicativos não usem caminhos explícitos para assemblies, o que não é uma prática recomendada.
Ferramenta de cache de montagem global	O Gacutil.exe (Global Assembly Cache Tool) não suporta mais o visualizador de plug-ins do shell.	Nenhum.

Interoperabilidade

Espaço de nomes: System.Runtime.InteropServices

Montagem: mscorlib (em mscorlib.dll)

Caraterística	Diferenças do 3.5 SP1	Alterações recomendadas
Comprimento do buffer (API não gerenciada)	Para economizar memória, a funcionalidade para o `pBufferLengthOffset` parâmetro para o ICorProfilerInfo2::GetStringLayout método foi alterada para corresponder ao `pStringLengthOffset` parâmetro. Ambos os parâmetros agora apontam para o local de deslocamento do comprimento da cadeia de caracteres. O comprimento do buffer foi removido da representação da classe string.	Remova qualquer dependência no comprimento do buffer.
Depuração JIT	Para simplificar o registro para depuração just-in-time (JIT), o depurador do .NET Framework agora usa apenas a chave do Registro AeDebug, que controla o comportamento de depuração JIT para código nativo. Esta alteração resulta no seguinte: * Você não pode mais registrar dois depuradores diferentes para código gerenciado e nativo. * Você não pode mais iniciar o depurador automaticamente para um processo não interativo, mas você pode solicitar ao usuário um processo interativo. * Você não será mais notificado quando o depurador falhar ao iniciar, ou quando não houver nenhum depurador registrado que deva ser iniciado. * Políticas de inicialização automática que dependem da interatividade do aplicativo não são mais suportadas.	Ajuste as operações de depuração conforme necessário.
Invocação da plataforma	Para melhorar o desempenho na interoperabilidade com código não gerenciado, convenções de chamada incorretas em uma plataforma invocam agora fazem com que o aplicativo falhe. Em versões anteriores, a camada de empacotamento resolvia esses erros até a pilha.	A depuração de seus aplicativos no Microsoft Visual Studio alerta você sobre esses erros para que você possa corrigi-los. Se você tiver binários que não podem ser atualizados, poderá incluir o <elemento NetFx40_PInvokeStackResilience> no arquivo de configuração do aplicativo para permitir que erros de chamada sejam resolvidos na pilha como em versões anteriores. No entanto, isso pode afetar o desempenho do seu aplicativo.
Interfaces removidas (API não gerenciada)	Para evitar confusão do desenvolvedor, as seguintes interfaces foram removidas, porque não forneciam cenários de tempo de execução úteis e o CLR não fornecia nem aceitava nenhuma implementação: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Nenhum.

Dados

Esta seção descreve problemas de migração para o uso de conjuntos de dados e clientes SQL, o Entity Framework, LINQ to SQL e WCF Data Servers (anteriormente conhecidos como ADO.NET Data Services).