Problemas de migração do .NET Framework 4

Artigo
08/01/2011

Este tópico 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 alterações, correções e alterações para conformidade com padrões e segurança, com base no feedback do cliente . A maioria dessas alterações não requerem qualquer programação modificações em seus aplicativos. Para aqueles que pode envolver modificações, consulte a coluna de alterações recomendadas da tabela.

Este tópico descreve alterações importantes nas seguintes áreas:

ASP.NET e Web
Núcleo
Data
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

Para obter uma maior visão de nível-dos problemas neste tópico, consulte o Guia de migração do .NET Framework 4.

Para problemas de migração após Beta 2, consulte problemas de migração para.NET Applications da Framework 4: Beta 2 para a RTM.

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

ASP.NET e Web

Namespaces: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; oassembly: Sistema.Web (no sistema.. Dll daWeb)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Browser definition files	Os arquivos de definição do navegador foram atualizados para incluir informações sobre novos e atualizados de navegadores e dispositivos. Mais antigas de navegadores e dispositivos, como o Netscape Navigator, foram removidos e versões mais recentes de navegadores e dispositivos como o iPhone cromo do Google e Apple foram adicionados. Se seu aplicativo contém definições de navegador personalizado que herdam de uma das definições de navegador que tenham sido removidas, você verá um erro. O HttpBrowserCapabilities objeto (que é exposta pela página de Request.Browser propriedade) é impulsionado por arquivos de definição de navegador. Portanto, as informações que são retornadas por acessar uma propriedade desse objeto em ASP.NET 4 podem ser diferentes das informações que foi retornadas em uma versão anterior de ASP.NET.	Se seu aplicativo depende dos arquivos antigos de definição de navegador, você pode copiá-los da seguinte pasta: \V2.0.50727\CONFIG\Browsers deFrameworkde Windows\Microsoft.NET\ Copiar os arquivos na pasta \CONFIG\Browsers correspondente para ASP.NET 4. Depois de copiar os arquivos, execute o Aspnet_regbrowsers.exe a ferramenta delinha comando. Para obter mais informações, consulte o https://www.asp.net/mobilesiteWeb .
Aplicativos de filhos que executam versões mistas de ASP.NET	ASP.NET 4 aplicativos são configurados como filhos de aplicativos que executam versões anteriores do ASP.NET pode falhar ao iniciar devido a erros de configuração ou compilação. O erro específico que ocorre depende do aplicativo executa o IIS 6.0, ou sob o IIS 7 ou o IIS 7.5.	Você pode fazer alterações aos arquivos de configuração dos aplicativos afetados do que o sistema de configuração corretamente reconheça o ASP.NET 4 de aplicativo. Para obter informações sobre as alterações que você deve fazer, consulte a seção "ASP.NET 4 filho aplicativos Falha ao iniciar sob ASP\ de ASP.NET 2.0 ou ASP.NET aplicativos de 3,5 " no documento ASP.NET alterações mais recentes de 4 sobre o ASP.NETsiteWeb .
Alterações de ClientID	O novo ClientIDModedeconfiguração em ASP.NET 4 permite que você especifique como ASP.NET gera a iddeatributo para elementos HTML . Em versões anteriores do ASP.NET, o comportamento padrão era equivalente a AutoIDaconfiguração de ClientIDMode. Agora, a configuração do padrão é Predictable. For more information, see Identificação de controle do servidor Web ASP.NET.	Se você usar Visual Studio 2010 para atualizar seu aplicativo de ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adiciona 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 aplicativo no IIS para o destino do.NET Framework 4, ASP.NET usa o novo modo por padrão. Para desabilitar o novo modo de identificação do cliente, adicione a seguinte configuração ao arquivo Web. config: <pages ClientIDMode="AutoID" / >
Código access segurança (CAS)	ASP.NET recursos de rede 2.0 que foram adicionados em ASP.NET uso de 3,5 a.NET Framework 1.1 e.NET Framework 2.0 modelo de segurança de acesso do código (CAS). No entanto, a implementação do CAS em ASP.NET 4 foi substancialmente revisadas. Como resultado, parcial- ASP.NET aplicativos que dependem de código confiável em execução no global assembly cache podem falhar com várias exceções de segurança . Aplicativos de confiança parcial-que dependem de grandes modificações e a diretiva de computador CAS também podem falhar e lançar exceções de segurança .	Você pode reverterparcial- ASP.NET 4 aplicativos para o comportamento de ASP.NET 1.1 e 2.0 usando o novo legacyCasModelatributo o trustelemento deconfiguração , conforme mostrado no exemplo a seguir: <trust level= "Medium" legacyCasModel="true" /> Observação Revertendo para o antigo modelo de CAS pode segurançareduzida de representar. Para obter mais informações sobre o novo ASP.NET modelo de segurança de acesso do código 4, consulte Segurança de acesso a código em aplicativos ASP.NET 4.
Arquivos de configuração	Arquivos deconfiguração raiz(arquivo computador. config e o arquivo raizWeb. config) para o.ASP\ de NET Framework e ASP.NET 4 foram atualizadas para incluir a maioria das informações de configuração clichê foi encontradas no aplicativoWeb, arquivos. config em ASP.NET 3.5. Por causa da complexidade dos IIS 7 e o IIS 7.5 configuração sistemas gerenciado , executando ASP.NET aplicativos de 3,5 em ASP.NET 4 e em IIS 7 e o IIS 7.5 pode resultar em um dos ASP.NET erros ou IIS.	Atualizar ASP.NET aplicativos de 3,5 para ASP.NET 4 usando o projeto atualizar ferramentas no Visual Studio 2010. Visual Studio 2010 modifica automaticamente o ASP.NET 3,5 aplicativoda Web. config arquivo para conter as configurações apropriadas para ASP.NET 4. No entanto, você pode executar o ASP.NET 3.5 aplicativos usando o.NET Framework 4 sem recompilação. Nesse caso, talvez seja necessário modificar manualmente o arquivo. config do aplicativo Webantes de executar o aplicativo sob o.NET Framework 4 e no IIS 7 ou no IIS 7.5. A alteração específica, que você deve fazer depende da combinação de software que você está trabalhando, incluindo versões de Service Pack (SP). Para obter informações sobre as combinações possíveis de software que são afetados por essa alteração e como resolver problemas com combinações específicas, consulte a seção Erros de configuração relacionados para o Novo ASP.NET a configuração de raiz 4 " no documento ASP.NET alterações mais recentes de 4 sobre o ASP.NETsiteWeb .
Controle de renderização	Em versões anteriores do ASP.NET, alguns controles emitida a marcação que você poderia não desabilitar. Por padrão, esse tipo de marcação não é gerado em ASP.NET 4. As alterações de renderização afetam os seguintes controles: O Image e ImageButton controles não processam uma border="0" atributo. O controles de validação e aclasseBaseValidatorque derivam dele não processarão mais texto vermelho por padrão. O HtmlForm controle não processa um name atributo. O Table não há mais controle processa um border="0" atributo. Controles que não são projetados para entrada do usuário (por exemplo, o Label control) não processará mais o disabled="disabled" atributo se seus Enabled propriedade estiver definida como false (ou se eles herdam essa configuração de um controle de contêiner ).	Se você usar o Visual Studio 2010 para atualizar seu aplicativo de ASP.NET 2.0 ou ASP.NET 3.5, a ferramenta adiciona automaticamente uma configuração ao arquivo Web. config que preserva o renderizaçãode legado. No entanto, se você atualizar um aplicativo alterando o pool de aplicativo no IIS para o destino do.NET Framework 4, ASP.NET por padrão, usa o novo modo de renderização . Para desabilitar o novo modo de renderização , adicione a seguinte configuração ao arquivo Web. config: <pages controlRenderingCompatibilityVersion="3.5" />
Os manipuladores de evento padrão de documentos	ASP.NET 4 processa o HTMLform do elemento actiono valor doatributo como uma seqüência vazia quando uma solicitação é feita para um sem extensão URL que tenha um documento padrão mapeado para o proprietário. Em versões anteriores do ASP.NET, uma solicitação para https://contoso.com resultaria em uma solicitação para Padrão. aspx. Nesse documento, a abertura form marca seria processada como no exemplo a seguir: <form action="Default.aspx" /> Em ASP.NET 4, uma solicitação para https://contoso.com também resulta em uma solicitação aspx Padrão, mas ASP.NET agora processa a abertura de HTML form marca como no exemplo a seguir: <form action="" /> Quando o actionatributo é uma seqüência vazia, o IIS DefaultDocumentModuleobjeto cria umasolicitação do filhopara Padrão. aspx. Na maioria das condições, estasolicitação de filhoé transparente para o código do aplicativo e página Padrão. aspx é executado normalmente. No entanto, uma interação de potencial entre código gerenciado e o IIS 7 ou o IIS 7.5 modo Integrado pode causar gerenciado páginas. aspx parar de funcionar corretamente durante asolicitaçãodo filho. Se as seguintes condições ocorrerem, asolicitação do filhoa um documento. aspx padrão resultará em um erro ou comportamento inesperado: Uma página. aspx é enviada ao navegador com o form do elemento action atributo definido como "". O formulário é remetida de volta para o ASP.NET. Um gerenciado módulo HTTP 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 ser lida no gerenciadodememória. Como resultado, o corpo da entidade não está mais disponível para quaisquer módulos de código nativo que estão executando no IIS 7 ou no IIS 7.5 modo Integrado. O IIS DefaultDocumentModuleobjeto eventualmente é executado e cria umasolicitação do filhoao documento Padrão. 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íveis para enviar asolicitaçãodo filho. Quando o pipeline HTTP é executado para asolicitaçãodo filho, o manipulador de arquivos. aspx é executado durante o manipuladorexecutarfase. Porque 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 determinar qual evento (se houver) deve ser gerado. Como resultado, nenhum dos manipuladores deevento de postbackda página aspx afetado execute.	Para obter informações sobre maneiras de contornar problemas que possam surgir como resultado da alteração, consulte "manipuladores de eventos não podem ser aumentados não em um documento Padrão no IIS 7 ou o IIS 7.5 modo integrado" no documento ASP.NET alterações mais recentes de 4 sobre o ASP.NETsiteWeb .
algoritmode hash	ASP.NET usa a criptografia e algoritmos de hash para ajudar a proteger os cookies de autenticação de dados como, por exemplo, formulários e estado de exibição. Por padrão, ASP.NET 4 usa o HMACSHA256oalgoritmo para operações de hash em cookies e o estado de exibição. Versões anteriores do ASP.NET usado o antigo HMACSHA1 algoritmo.	Se você executar aplicativos misturar ASP.NET 2.0 e ASP.NET 4, onde os dados como, por exemplo, os cookies de autenticação de formulários devem funcionar em.NET Framework versões, configurar um ASP.NET 4aplicativo da Webpara usar o antigo HMACSHA1oalgoritmo , adicionando a seguinte configuração no arquivo Web. config: <machineKey validation="SHA1" />
Hospedagem de controles no Internet Explorer	Você não poderá mais controles deWindows Forms hostno Internet Explorer, porque existem soluções melhores para controles de hospedagem na Web. Portanto, os assemblies IEHost.dll e IEExec.exe foram removidos da.NET Framework.	Você pode usar as seguintes tecnologias para o desenvolvimento de controle personalizado em aplicativos Web : Você pode criar umaplicativo do Silverlighte configurá-lo para ser executado fora do navegador. For more information, see Out-of-Browser Support. Você pode construir um de navegador XAML aplicativo XBAP () para tirar proveito dos recursos do WPF (requer o.NET Framework nas máquinas cliente). For more information, see Visão geral sobre WPF XAML Browser Applications.
Métodos de HtmlEncode e UrlEncode	O HtmlEncode e UrlEncode métodos para a HttpUtility e HttpServerUtility classes foram atualizadas para codificar o caractere de aspas simples (') da seguinte maneira: O HtmlEncode método codifica ocorrências de aspas simples como' O UrlEncode método codifica ocorrências de aspas simples como%27	Examine o seu código para os locais onde você usar o HtmlEncode e UrlEncode métodos e certifique-se de que a alteração na codificação não resulta em uma alteração que afeta o seu aplicativo.
Erros de HttpException em ASP.NET 2.0 aplicativos	Depois de ASP.NET 4 foi habilitada no IIS 6, ASP.NET 2.0 aplicativos executados no IIS 6 (no Windows Server 2003 ou Windows Server 2003 R2) podem gerar erros, como a seguir: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	Se ASP.NET 4 não é necessária para executar Web , remapear o site para usar o ASP.NET 2.0 em vez disso. - ou - Se ASP.NET 4 é necessário para executar Web mover qualquer filho ASP.NET 2.0 diretórios virtuais em uma diferente do Web site que faz mapeado para ASP.NET 2.0. - ou - Desative URLs sem extensões. Para obter mais informações, consulte "ASP.NET de HttpException Erros que fazem referência a eurl.axd poderão ser gerados por 2.0 aplicativos " no documento ASP.NET alterações mais recentes de 4 sobre o ASP.NETsiteWeb .
Tipos de associação	Alguns tipos (por exemplo, System.Web.Security.MembershipProvider) que são usados em ASP.NET associação foram movidos do sistema.Web. dll no sistema.Web.ApplicationServices.dll de assembly. Os tipos foram movidos na ordem para resolver dependências de arquitetura de camadas entre tipos no cliente e no estendido.SKUs do NET Framework .	Bibliotecas de classes que foram atualizadas a partir de versões anteriores do ASP.NET e que tipos de associação de uso que foram movidos podem falhar para compilar quando usado em um ASP.NET 4 projeto. Em caso afirmativo, adicione uma referência noprojeto debibliotecade classeao sistema.Web.ApplicationServices.dll.
Alterações de controle de menu	Altera para o Menu a controlar o resultado no seguinte comportamento: Se System.Web.UI.WebControls.MenuRenderingMode for definido como List, ou se System.Web.UI.WebControls.MenuRenderingMode é definida como Default e PagesSection.ControlRenderingCompatibilityVersion é definida como 4.0 ou posterior, o MenuItem.PopOutImageUrl propriedade tem nenhum efeito. Se o caminho definido o Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl Propriedades contém uma barra de invertida (\), as imagens não render. (Em versões anteriores do ASP.NET, o caminho pode incluir uma barra invertida.)	Ao invés de configuração o MenuItem.PopOutImageUrldepropriedade individuais itens de menu , definir o Menu.StaticPopOutImageUrl ou Menu.DynamicPopOutImageUrl do pai System.Web.UI.WebControls.Menu de controle. - ou - Set System.Web.UI.WebControls.MenuRenderingMode to Table, or set System.Web.UI.WebControls.MenuRenderingMode to Default and set PagesSection.ControlRenderingCompatibilityVersion to 3.5. Essas configurações fazem com que o Menu o controle para usar o layout da tabela-com base em HTML que é usado em versões anteriores do ASP.NET. Se o caminho do Menu.StaticPopOutImageUrl ou Menu.DynamicPopOutImageUrl propriedade contém uma barra de invertida (\), substitua a um caractere de barra (/).
assembly de móveis no Web. config file	Em versões anteriores do ASP.NET, uma referência para o sistema.Web.Mobile.dll assembly foi incluída no arquivo raiz Web. config no assemblies seção em system.web/compilation. Para melhorar o desempenho, a referência a este assembly foi removida. Observação O sistema.Web.Mobile.dll de assembly e o ASP.NET controles móveis estão incluídos no ASP.NET 4, mas eles são preterido.	Se você desejar usar tipos neste assembly, adicione uma referência ao assembly no raiz Web. config arquivo ou em um arquivo. config do aplicativo Web.
Cache de saída	Em ASP.NET 1.0, um bug causadas em cache páginas especificado Location="ServerAndClient" como uma output–cache de configuração para emitir um Vary:* HTTP cabeçalho na resposta. Isso teve o efeito de dizer a navegadores de cliente para a página localmente em cache nunca. Em ASP.NET 1.1, o HttpCachePolicy.SetOmitVaryStar método foi adicionado, o que poderia ser chamado para suprimir a Vary:* cabeçalho. No entanto, a relatórios de bug sugerem que os desenvolvedores são insensíveis a existente SetOmitVaryStar comportamento. Em ASP.NET 4, o Vary:* HTTP cabeçalho não é emitida de respostas de especificar a diretiva a seguir: <%@ OutputCache Location="ServerAndClient" %> Como resultado, o HttpCachePolicy.SetOmitVaryStar método não é mais necessária para suprimir a Vary:* cabeçalho. Em aplicativos que especificar "serverandclient" para o Location atributo, páginas serão armazenáveis em cache no navegador sem exigir que você chamar HttpCachePolicy.SetOmitVaryStar.	Se as páginas no aplicativo devem emitir Vary:, chame o HttpResponse.AppendHeader método conforme mostrado no exemplo a seguir: HttpResponse.AppendHeader("Vary",""); Como alternativa, você pode alterar o valor do cache de saída Location atributo para "Server".
Análise daPágina	O analisador de página ASP.NET(arquivos. aspx) de páginasWeb e controles de usuário (arquivos. ascx) é mais rígidas nas ASP.NET 4 que em versões anteriores do ASP.NET, e ele sinaliza mais a marcação como inválido que em versões anteriores.	Examine as mensagens de erro que são produzidas quando uma página é executada e corrigir os erros resultantes damarcaçãode inválido.
Tipos de Passport	O suporte de Passport foi incorporado no ASP.NET 2.0 é obsoleto e não é suportada devido a alterações no Passport (agora Live ID SDK). Como resultado, os tipos relacionados ao Passport em System.Web.Security agora são marcados com o ObsoleteAttribute atributo.	Alterar qualquer código que você tem que usa o Passport digita o System.Web.Security namespace (por exemplo, System.Web.Security.PassportIdentity) para usar o SDK do Windows Live ID.
Informações de PathInfo na FilePath propriedade	ASP.NET 4 não inclui mais o PathInfo valor em valores de retorno de propriedades, como HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath, e HttpRequest.CurrentExecutionFilePath. Em vez disso, o PathInfo informações estão disponíveis em HttpRequest.PathInfo. Por exemplo, imagine o fragmento de URL a seguir: /testapp/Action.mvc/SomeAction Em versões anteriores do ASP.NET, System.Web.HttpRequest propriedades têm os seguintes valores: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (vazio) Em ASP.NET 4, System.Web.HttpRequest Propriedades em vez disso, tem os seguintes valores: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Examine o seu código para os locais onde você depende de propriedades do deSystem.Web.HttpRequestclasse para retornar informações de caminho; Altere o código para refletir as alterações em como as informações de caminho são retornadas.
validaçãode solicitação	Para melhorar a solicitaçãovalidação, o ASP.NETdesolicitaçãovalidação é chamada anteriormente na solicitação,ciclo de vida. Como resultado, avalidação de solicitaçãoé executado para solicitações que não são arquivos. aspx, como para chamadas de serviço da Web e manipuladores personalizados. Solicitação de validação também estará ativa quando estiver executando o módulo HTTP personalizado no pipeline de processamento de solicitação . Como resultado da alteração, solicitações de recursos, além de arquivos. aspx podem lançar solicitaçãoerros devalidação . CódigoPersonalizar que executa o pipeline de solicitação (por exemplo, módulos personalizados de HTTP ) também pode lançar solicitaçãoerros devalidação .	Se necessário, você pode reverter para o comportamento antigo de ter apenas as páginas. aspx disparar a solicitaçãodevalidação usando a seguinte configuração no arquivo deconfiguração da Web: <httpRuntime requestValidationMode="2.0" /> Observação Se você reverter para o comportamento antigo, certifique-se de que todo o código existentes manipuladores, módulos e outros códigos personalizados executa verificações para entradas HTTP potencialmente não seguras que podem ser vetores de ataque XSS.
Roteamento	Se você criar um site daWeb sistema de arquivosem 2010 de Visual Studio e Web estiver em uma pasta que contém um ponto (.) no nome da pasta, roteamento de URL não funcionará com confiança. Um HTTP 404 erro é retornado da alguns caminhos virtuais. Isso ocorre porque o Visual Studio 2010 inicia o servidor de desenvolvimento de Visual Studio (Cassini) usando um caminho incorreto para o diretório raiz virtual.	No Propriedades Web baseado em página para o arquivo-, altere o Virtual Caminhoatributo para "/". - ou - Create a Webaplicativoprojeto em vez de um projetode site de Web . Webprojetos deaplicativo não tem esse problema e funciona de roteamento de URL , mesmo se a pasta do projeto tem um ponto no seu nome. - ou - Crie um HTTP-baseado em Web site que está hospedado no IIS. O IIS-hospedado Web sites que podem ter pontos no caminho virtual , bem como a pasta do arquivo de projeto .
Sites do SharePoint	Se você tentar executar um ASP.NET Web site do SharePoint que contém um personalizado parcial- chamado emnível de confiança</c5> WSS_Minimal, você verá o seguinte erro: Could not find permission set named 'ASP.Net'.	Atualmente, a nenhuma versão do SharePoint é compatível com ASP.NET. Como resultado, você não deve tentar executar um ASP.NET 4 Web site como um filho de um site da Web do SharePoint.
Padrões XHTML 1.1	Para permitir a conformidade XHTML 1.1 para Web o ASP.NET controles de .NET Framework 4 irá gerar de XHTML 1.1 compatível com HTML. Esse renderização está ativado, usando a opção a seguir no arquivo Web. config: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> Essa opção é definida por padrão, 4.0. ProjetosWeb que são atualizados para Visual Studio de Visual Studio 2008 será a configuração de 3,5 ativado para a compatibilidade.	Nenhum.

Núcleo

Geral Recursos

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
CardSpace	O Windows CardSpace não está mais incluído na.NET Framework; ele é fornecido separadamente.	Baixe o Windows CardSpace a partir do Microsoft Download Centralizado.
Arquivos de configuração	Correções foram feitas em como o .NET Framework acessa arquivos deconfiguração do aplicativo.	Se o seu arquivo deconfiguração do aplicativoé denominado aplicativo-nome. config, renomeá-lo para aplicativo-nome. exe. Por exemplo, renomeie MyApp.config para MyApp.exe.config.
Compilador de código C#	O Compiler, CompilerError, e ErrorLevel classes que estavam na Microsoft.CSharp namespace não estão mais disponíveis e seus assembly (cscompmgd.dll) não está mais incluída na.NET Framework.	Use o CodeDomProvider classe System.CodeDom.Compiler namespace. For more information, see Usando o CodeDOM..
Hosting (API não gerenciada)	Para melhorar os recursos de hospedagem , alguns da ativação de hospedagem APIs foram preterido. No-recursos doexecução lado a lado deprocessopermitem que um aplicativo carregar e iniciar várias versões do.NET Framework no mesmo processo. Por exemplo, você pode executar aplicativos carga add ins-(ou componentes) que se baseiam o .NET Framework 2.0 SP1 e adicionar-ins que se baseiam o .NET Framework 4 no mesmo processo. Componentes antigos continuam a usar o antigo.NET Framework versãoe novos componentes de usam o novo.NET Framework versão.	Use as configurações descritas na Execução de lado a lado no processo.
Novomodelo desegurança	A diretiva segurança de acesso do código (CAS) foi desativada e substituída com um modelo simplificado, conforme descrito em Alterações de segurança na.NET Framework 4.	Modificações podem ser necessárias para se depender CAS em seus aplicativos. For more information, see Compatibilidade de diretiva de segurança de acesso e a migração de código.

Date and Time

Namespace: System; oassembly: mscorlib (in mscorlib.dll)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Horário de verão	Para ser consistente com o relógio do sistema, propriedades de tempo (como TimeZoneInfo.Local e DateTime.Now) agora usar as regras do sistema operacional em vez dos outros.NET Framework dados operações de horário de verão.	Nenhum.
Seqüências de caracteres deFormatação	Para oferecer suporte a cultura-formatação confidenciais, o TimeSpan estrutura inclui novas sobrecargas da ToString, Parse, e TryParse métodos além dos novos ParseExact e TryParseExact métodos.	Nenhum.

Globalization

Para obter uma lista das novas culturas neutras e específicas, consulte Novidades sobre globalização e localização.

Namespace: System.Globalization; oassembly: mscorlib (in mscorlib.dll)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Nomes de cultura	As seguintes alterações de nome afetam as culturas alemão, Divehi e Centro-Africana: CurrencyEnglishName: O nome da moeda para o alemão (Switizerland) (de-CH) cultura foi alterado de "sFr". para "fr"... LongDatePattern: O padrão de data por extenso para o Divehi (Maldivas) (dv-MV) cultura foi alterado de "MMMM/dd/yyyy" para "dd/MM/yyyy". PMDesignator: O P.M. designador do Africâner (África do Sul) (af-ZA) cultura foi alterado de "nm" para "PM".	Observe as alterações de nome de cultura .
LCID de parâmetro	Para ser consistente com o comportamento esperado nas configurações do servidor de automação, o CLR não passa a cultura atual para o LCID parâmetro para não gerenciado COM-com base em aplicativos. Em vez disso, ele passa 1033 (en-dos EUA) para a cultura.	ModificaçõesNão necessárias, exceto para aplicativos nativo que exigem uma culturade especificado.
Tipos de cultura de obsoleto	O FrameworkCultures e WindowsOnlyCulturestipos decultura agora estão obsoleto. Para compatibilidade com versões anteriores, FrameworkCultures agora retorna culturas neutras e específicas que foram incluídas com o anterior.NET Framework, e WindowsOnlyCultures agora retorna uma lista vazia.	Usar outros valores da CultureTypes enumeração.
Recuperando a cultura	Começando com Windows 7, o .NET Framework 4 recupera informações de cultura do sistema operacional em vez de armazenar os dados propriamente ditos. Além disso, o.NET Framework sincroniza com o Windows para classificação e casing dados.	Nenhum.
Padrões deUnicode 5.1	A.NET Framework agora suporta todos os caracteres do Unicode 5.1 – um acréscimo de cerca de 1400 caracteres. Os caracteres adicionais incluem novos símbolos, setas, sinais diacríticos, pontuação, símbolos matemáticos, traçados CJK e ideogramas, malaiala adicional e Telugu caracteres numéricos e vários caracteres Myanmar, latim, árabe, grego, mongol e cirílico. Novos scripts a seguintes são compatíveis com Unicode 5.1: Sundanese, Lepcha, Ol Chiki, variável, Saurashtra, Kayah Li, Rejang, Gurmukhi, oriá, tâmil, télugo e malaiala caracteres e Cham.	Nenhum.

Exceptions

Namespaces: System, System.Runtime.ExceptionServices; oassembly: mscorlib (in mscorlib.dll)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Exceções para o estado do processo de corrompido	O CLR não mais oferece exceções para o estado do processo de corrompido 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 aplicativo nesse estado. Para obter mais informações, consulte o HandleProcessCorruptedStateExceptionsAttribute e a entrada Tratamento exceções de estado corrompido no blog CLR Inside Out.
Exceções do mecanismo de execução	ExecutionEngineExceptionAgora é obsoleto, porque uma exceção de capturável permitirá que um processo de instável continuar a executar. Esta alteração melhora a previsibilidade e confiabilidade no tempo de execução.	Use um InvalidOperationException para sinalizar a condição.

Exceções para o estado do processo de corrompido

O CLR não mais oferece exceções para o estado do processo de corrompido 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 aplicativo nesse estado.

Para obter mais informações, consulte o HandleProcessCorruptedStateExceptionsAttribute e a entrada Tratamento exceções de estado corrompido no blog CLR Inside Out.

Exceções do mecanismo de execução

ExecutionEngineExceptionAgora é obsoleto, porque uma exceção de capturável permitirá que um processo de instável continuar a executar. Esta alteração melhora a previsibilidade e confiabilidade no tempo de execução.

Use um InvalidOperationException para sinalizar a condição.

Reflection

Namespace: System.Reflection; oassembly: mscorlib (in mscorlib.dll)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Algoritmos de hash do assembly	O AssemblyName.HashAlgorithmapropriedade agora retorna AssemblyHashAlgorithm.None, porque o tempo de execução não sabe o algoritmo de hash do assembly referenciado quando o assembly não está carregado. (Isso se refere ao usar a propriedade em um assembly referenciado, como retornado pelo Assembly.GetReferencedAssemblies método.)	Nenhum.
Carregamento de assembly	Para evitar redundantes de carregamento de módulos (assemblies) e para economizar espaço de endereço virtual, o CLR agora carrega os assemblies usando somente o Win32 MapViewOfFile função. Ele não é mais também chama o LoadLibrarydefunção. Essa alteração afeta os aplicativos de diagnóstico das seguintes maneiras: A ProcessModuleCollection deixará de conter quaisquer módulos de uma classe biblioteca (arquivo. dll), como obtidas em uma chamada para Process.GetCurrentProcess().Modules. Aplicativos do Win32 que usam o EnumProcessModulesdefunção não verá todos os módulos gerenciado listados.	Nenhum.
A declaração de tipo	O Type.DeclaringType propriedade agora corretamente retorna null quando o tipo não tem um tipo declarativo.	Nenhum.
Delegates	Um delegado agora lança um ArgumentNullException em vez de um NullReferenceException quando um valor null é passado ao construtordo delegado.	Certifique-se de que qualquer exceção tratamento detectando ArgumentNullException.
Alteração do local global assembly cache	Para .NET Framework 4 assemblies, global assembly cache foi movido do diretório Windows (% WINDIR %) para o subdiretório Microsoft.Net (% WINDIR%\Microsoft.Net) (em inglês). Assemblies de versões anteriores permanecem no diretório mais antigo. O não gerenciado ASM_CACHE_FLAGS enumeração contém o novo ASM_CACHE_ROOT_EX sinalizar. Esse sinalizar obtém o local do cache de .NET Framework 4 assemblies, que podem ser obtidos com o GetCachePath função.	Nenhum, assumindo que os aplicativos não usam caminhos explícitos a assemblies, que não é uma prática recomendada.
O global assembly cache tool	O Gacutil. exe (ferramenta de Cache de Assembly Global) não suporta mais o Visualizador de plug-in de shell .	Nenhum.

Interoperability

Namespace: System.Runtime.InteropServices; oassembly: mscorlib (in mscorlib.dll)

Feature	Diferenças de 3.5 SP1	Alterações recomendadas
Comprimento do buffer (API não gerenciada)	Para economizar memória, a funcionalidade para o pBufferLengthOffsetdeparâmetro para o ICorProfilerInfo2::GetStringLayout método foi alterado para coincidir com o pStringLengthOffsetparâmetro. Ambos os parâmetros a apontar para o local de deslocamento do comprimento da seqüência de caracteres. Comprimento do buffer foi removido da representação da string classe.	Remover qualquer dependência em que o comprimento do buffer.
JIT depuração	Para simplificar o registro Just-In-Time (JIT), depuração, o.Agora, o depurador do NET Framework usa apenas o registro AeDebug chave, que controla o comportamento dedepuração JITpara código nativo . Essa alteração resulta no seguinte: Você não pode registrar duas depuradores diferentes para código gerenciado e nativo . Você não poderá mais iniciar o depurador automaticamente para um processodo interativo de não-, mas você pode solicitar ao usuário um processode interativo. Não, você será notificado quando o depurador não for iniciado ou quando não há nenhum depurador registrado que deve ser iniciado. Automático- diretivas deinicialização que dependem da interatividade do aplicativo não são mais suportados.	Ajuste as operações de depuração , conforme necessário.
Platform invoke	Para melhorar o desempenho na interoperabilidade com código não gerenciado, convenções de chamada incorretas em uma plataforma de invocar a causa de agora o aplicativo falhe. Nas versões anteriores, a camada de marshaling resolvido esses erros na pilha.	Depuração de seus aplicativos em Microsoft Visual Studio 2010 irá alertá-lo para esses erros para que você poderá corrigi-los. Se você tiver os binários não podem ser atualizados, você pode incluir o <NetFx40_PInvokeStackResilience> elemento no arquivo de configuração do seu aplicativopara permitir que os erros de chamada ser resolvido na pilha, como nas versões anteriores. No entanto, isso pode afetar o desempenho do seu aplicativo.
Interfaces removidos (API não gerenciada)	Para evitar confusão de desenvolvedor, as seguintes interfaces foram removidas, porque eles não forneceu qualquer execução útil-situações de tempo e o CLR não fornecer ou aceitar quaisquer implementações: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Nenhum.

Data

Esta seção descreve os problemas de migração para o uso de conjuntos de dados e SQL de clientes, a Entity Framework, LINQ SQLe servidores de dados do WCF (antes conhecida como ADO.NET serviços de dados).