Alterações de runtime para migração para o .NET Framework 4.5.x

Esse artigo lista os problemas de compatibilidade de aplicativo introduzidos no .NET Framework 4.5 , 4.5.1 e 4.5.2.

.NET Framework 4.5

ASP.NET

GridViews com AllowCustomPaging definido como verdadeiro pode acionar o evento PageIndexChanging ao deixar a página final do modo de exibição

Detalhes

Um bug no .NET Framework 4.5 faz com que System.Web.UI.WebControls.GridView.PageIndexChanging, às vezes, não seja acionado para System.Web.UI.WebControls.GridViews com System.Web.UI.WebControls.GridView.AllowCustomPaging habilitado.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework. Como solução alternativa, o aplicativo pode fazer um BindGrid explícito em qualquer Page_Load que respeite essas condições (o System.Web.UI.WebControls.GridView está na última página e LastSystem.Web.UI.WebControls.GridView.PageSize é diferente de System.Web.UI.WebControls.GridView.PageSize). Como alternativa, o aplicativo pode ser modificado para permitir a paginação (em vez da paginação personalizada), uma vez que esse cenário não demonstra o problema.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• GridView.AllowCustomPaging

A propriedade HttpRequest.ContentEncoding proíbe a UTF7

Detalhes

A partir do .NET Framework 4.5, a codificação UTF-7 está proibida nos corpos de System.Web.HttpRequest. Os dados para aplicativos que dependem de dados de entrada UTF-7 não serão decodificados corretamente em alguns casos.

Sugestão

De modo ideal, os aplicativos devem ser atualizados para não usar a codificação UTF-7 em System.Web.HttpRequest. De modo alternativo, o comportamento herdado pode ser restaurado usando o atributo aspnet:AllowUtf7RequestContentEncoding do elemento appSettings.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• HttpRequest.ContentEncoding

HttpUtility.JavaScriptStringEncode escapa o E comercial

Detalhes

A partir do .NET Framework 4.5, System.Web.HttpUtility.JavaScriptStringEncode(String) ignora o caractere E comercial (&).

Sugestão

Se seu aplicativo depende do comportamento anterior desse método, você poderá adicionar uma definição aspnet:JavaScriptDoNotEncodeAmpersand ao elemento appSettings do ASP.NET no seu arquivo de configuração.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• HttpUtility.JavaScriptStringEncode(String)
• HttpUtility.JavaScriptStringEncode(String, Boolean)

IPad não deve ser usado no arquivo de funcionalidades personalizadas, pois agora é uma funcionalidade do navegador

Detalhes

Começando com o .NET Framework 4.5, o iPad é um identificador no arquivo de funcionalidades padrão do navegador ASP.NET, portanto ele não deve ser usado em um arquivo de funcionalidades personalizados

Sugestão

Se forem exigidas funcionalidades específicas do iPad, será preciso modificar o comportamento do iPad configurando funcionalidades na refID "IPad" predefinida do gateway em vez de gerar uma nova ID "IPad" pela correspondência do agente do usuário.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

O evento Page.LoadComplete não faz mais com que o controle System.Web.UI.WebControls.EntityDataSource invoque a associação de dados

Detalhes

O evento LoadComplete não faz mais com que o controle System.Web.UI.WebControls.EntityDataSource chame a associação de dados para alterações par criar/atualizar/excluir parâmetros. Essa alteração elimina um processamento irrelevante para o banco de dados, impede que os valores dos controles sejam redefinidos e gera um comportamento consistente com outros controles de dados, como System.Web.UI.WebControls.SqlDataSource e System.Web.UI.WebControls.ObjectDataSource. Essa alteração gera um comportamento diferente em um evento improvável no qual os aplicativos dependam da associação de dados no evento LoadComplete.

Sugestão

Se houver necessidade de vinculação de dados, invoque manualmente a associação de dados em um evento que seja anterior no post-back.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Aplicativos ASP.NET MVC4 de criação de perfil podem causar um erro fatal do mecanismo de execução

Detalhes

Os criadores de perfil que usam NGEN/assemblies de perfil podem causar pane em aplicativos ASP.NET MVC4 de criação de perfil na inicialização com o "Erro Fatal do Mecanismo de Execução".

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.2. Como alternativa, o criador de perfil pode evitar esse problema especificando COR_PRF_DISABLE_ALL_NGEN_IMAGES em sua máscara de evento.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

O compartilhamento do estado de sessão com o StateServer do ASP.NET exige que todos os servidores do Web farm usem a mesma versão do .NET Framework

Detalhes

Ao habilitar o estado de sessão System.Web.SessionState.SessionStateMode.StateServer, todos os servidores no web farm fornecido devem usar a mesma versão do .NET Framework para o estado ser compartilhado corretamente.

Sugestão

Certifique-se de atualizar as versões do .NET Framework em servidores Web que compartilham o estado ao mesmo tempo.

	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• SessionStateMode.StateServer

WebUtility.HtmlDecode não decodifica mais sequências de entrada inválidas

Detalhes

Por padrão, os métodos de decodificação não decodificam mais uma sequência de entrada válida em uma cadeia de caracteres UTF-16 inválida. Em vez disso, eles retornam a entrada original.

Sugestão

A alteração na saída do decodificador deve importar somente se você armazenar dados binários em vez de dados UTF-16 em cadeias de caracteres. Para controlar explicitamente esse comportamento, defina o atributo aspnet:AllowRelaxedUnicodeDecoding do elemento appSettings como true para habilitar o comportamento herdado ou como false para habilitar o comportamento atual.

	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• WebUtility.HtmlDecode(String)
• WebUtility.HtmlDecode(String, TextWriter)
• WebUtility.UrlDecode(String)

Núcleo

Assemblies compilados com interrupções Regex.CompileToAssembly entre o 4.0 e o 4.5

Detalhes

Se uma assembly de expressões regulares compiladas é trabalhada com o .NET Framework 4.5 mas é destinada ao .NET Framework 4, numa tentativa de usar uma das expressões regulares em que a assembly de um sistema com .NET Framework 4 instalado gera uma exceção.

Sugestão

Para solucionar esse problema, pode-se seguir uma das seguintes alternativas:

• Compilar o assembly que contém as expressões regulares com o .NET Framework 4.
• Use uma expressão regular interpretada.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName)
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[])
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[], String)

BlockingCollection<T>.TryTakeFromAny não é mais gerado

Detalhes

Se uma das coleções de entrada for marcada como concluída, TryTakeFromAny(BlockingCollection<T>[], T) não retornará mais -1 e TakeFromAny(BlockingCollection<T>[], T) não vai mais gerar uma exceção. Essa alteração possibilita trabalhar com coleções quando uma das coleções está vazia ou concluída, mas a outra coleção ainda possui itens que podem ser recuperados.

Sugestão

Se o retorno de -1 de TryTakeFromAny ou a geração de TakeFromAny foram usados para fins de fluxo de controle no caso de conclusão de uma coleção de blocos, tal código agora deverá ser alterado para usar .Any(b => b.IsCompleted) a fim de detectar essa condição.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T, CancellationToken)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, Int32)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)

Mudança no comportamento de métodos Task.WaitAll com argumentos de tempo limite

Detalhes

O comportamento de Task.WaitAll ficou mais consistente no .NET Framework 4.5. No .NET Framework 4, esses métodos se comportavam de forma inconsistente. Quando o tempo limite expirou, se uma ou mais tarefas foram concluídas ou canceladas antes da chamada de método, o método lançou uma exceção System.AggregateException. Quando o tempo limite expirava, se nenhuma tarefa tivesse sido concluída ou cancelada antes da chamada de método, mas uma ou mais tarefas tivessem entrado nesses estados após a chamada de método, o método retornava false.

No .NET Framework 4.5, essas sobrecargas de método agora retornam false se alguma tarefa ainda está em execução quando o intervalo de tempo limite expira e geram uma exceção System.AggregateException somente se uma tarefa de entrada é cancelada (não importa se antes ou depois da chamada de método) e nenhuma outra tarefa ainda está em execução.

Sugestão

Se um System.AggregateException estava sendo capturado como um meio de detectar uma tarefa que foi cancelada antes da chamada WaitAll ser invocada, esse código deve, em vez disso, fazer a mesma detecção por meio da propriedade IsCanceled (por exemplo: .Any(t => t.IsCanceled)) uma vez que o .NET Framework 4.6 só acionará esse caso se todas as tarefas aguardadas forem concluídas antes do tempo limite.

	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• Task.WaitAll(Task[], Int32)
• Task.WaitAll(Task[], Int32, CancellationToken)
• Task.WaitAll(Task[], TimeSpan)

Compilador compatível com encaminhamento de tipos ao destinar várias vezes o mscorlib

Detalhes

Um novo recurso CodeDOM permite a um compilador compilar com a versão de destino do mscorlib.dll em vez da versão do .NET Framework 4.5 de mscorlib.dll.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

ConcurrentQueue<T>.TryPeek pode retornar um nulo errado por meio de seus parâmetros de saída

Detalhes

Em alguns cenários multithread, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) pode retornar true, mas popular o parâmetro de saída com um valor nulo (em vez do valor correto, inspecionado).

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.1. O upgrade para esse Framework resolverá o problema.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

• ConcurrentQueue<T>.TryPeek(T)

EventListeners do ETW não capturam eventos dos provedores com palavras-chave explícitas (como o provedor TPL)

Detalhes

EventListeners do ETW com uma máscara de palavra-chave em branco não capturam eventos corretamente dos provedores com palavras-chave explícitas. No .NET Framework 4.5, o provedor TPL começou a fornecer palavras-chave explícitas e disparou esse problema. No .NET Framework 4.6, EventListeners foram atualizados para não apresentarem mais esse problema.

Sugestão

Para contornar esse problema, substitua as chamadas para EnableEvents(EventSource, EventLevel) por chamadas para a sobrecarga de EnableEvents com especificação explícita da máscara "qualquer palavra-chave" a ser usada: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• EventListener.EnableEvents(EventSource, EventLevel)

Exceções durante o processamento não observado em System.Threading.Tasks.Task não são mais propagadas no thread do finalizador

Detalhes

Como a classe System.Threading.Tasks.Task representa uma operação assíncrona, ela captura todas as exceções não graves que ocorrem durante o processamento assíncrono. No .NET Framework 4.5, se uma exceção não for observada e seu código nunca aguarda a tarefa, a exceção não será mais propagada no thread do finalizador e causará a falha do processo durante a coleta de lixo. Essa alteração melhora a confiabilidade de aplicativos que usam a classe Task para executar processamento assíncrono não observado.

Sugestão

Se um aplicativo depender de exceções assíncronas não observadas que se propagam para o thread do finalizador, o comportamento anterior poderá ser restaurado com o fornecimento de um manipulador apropriado para o evento UnobservedTaskException ou com a definição de um elemento de configuração de runtime.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• Task.Run(Action)
• Task.Run(Action, CancellationToken)
• Task.Run(Func<Task>)
• Task.Run(Func<Task>, CancellationToken)
• Task.Run<TResult>(Func<TResult>)
• Task.Run<TResult>(Func<TResult>, CancellationToken)
• Task.Run<TResult>(Func<Task<TResult>>)
• Task.Run<TResult>(Func<Task<TResult>>, CancellationToken)
• Task.Start()
• Task.Start(TaskScheduler)

O algoritmo List.Sort foi alterado

Detalhes

A partir do .NET Framework 4.5, o algoritmo de classificação de System.Collections.Generic.List<T> foi alterado (para ser uma classificação introspectiva em vez de uma classificação rápida). A classificação de System.Collections.Generic.List<T> nunca foi estável, mas essa alteração pode fazer com que cenários diferentes sejam classificados de maneiras instáveis. Isso significa apenas que itens equivalentes podem ser classificados em ordens diferentes em chamadas posteriores da API.

Sugestão

Como o algoritmo de classificação antigo também era instável (embora de maneiras ligeiramente diferentes), não deve haver nenhum código que dependa de itens equivalentes sempre serem classificados em uma ordem específica. Se houver casos de códigos que dependem disso e que tinham sorte com o comportamento antigo, esses códigos deverão ser atualizados para usar um comparador que classifique de forma determinista os itens na ordem desejada.

Nome	Valor
Escopo	Transparente
Versão	4.5
Tipo	Runtime

APIs afetadas

• List<T>.Sort()
• List<T>.Sort(IComparer<T>)
• List<T>.Sort(Comparison<T>)
• List<T>.Sort(Int32, Int32, IComparer<T>)

Ausência do Moniker da Estrutura de Destino resulta no comportamento da versão 4.0

Detalhes

Os aplicativos sem um System.Runtime.Versioning.TargetFrameworkAttribute aplicado no nível de assembly serão executados automaticamente usando a semântica (quirks) do .NET Framework 4.0. Para garantir a alta qualidade, é recomendável que todos os binários sejam explicitamente atribuídos com um System.Runtime.Versioning.TargetFrameworkAttribute indicando a versão do .NET Framework com a qual eles foram criados. Usar um moniker da estrutura de destino em um arquivo de projeto fará com que o MSBuild aplique automaticamente um System.Runtime.Versioning.TargetFrameworkAttribute.

Sugestão

O System.Runtime.Versioning.TargetFrameworkAttribute deve ser fornecido, seja por meio da adição do atributo diretamente ao assembly ou da especificação de uma estrutura de destino no arquivo de projeto, seja por meio da GUI das propriedades do projeto do Visual Studio.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Algumas APIs .NET causam EntryPointNotFoundExceptions de primeira chance

Detalhes

No .NET Framework 4.5, um pequeno número de métodos .NET começou a gerar System.EntryPointNotFoundExceptions de primeira chance. Essas exceções eram tratadas dentro do .NET Framework, mas podiam interromper a automação de teste que não esperava as exceções de primeira instância. Essas mesmas APIs interrompem alguns cenários ApiVerifier quando HighVersionLie é habilitado.

Sugestão

Esse bug pode ser evitado com a o upgrade para o .NET Framework 4.5.1. Como alternativa, a automação de teste pode ser atualizada para não interromper exceções System.EntryPointNotFoundException de primeira chance.

	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

System.Threading.Tasks.Task não gera mais ObjectDisposedException depois que o objeto é descartado

Detalhes

Exceto por IAsyncResult.AsyncWaitHandle, os métodos System.Threading.Tasks.Tasknão geram mais uma exceção System.ObjectDisposedException após o objeto ser descartado. Essa alteração permite o uso de tarefas em cache. Por exemplo, um método pode retornar uma tarefa em cache para representar uma operação já concluída em vez de alocar uma nova tarefa. Isso era impossível nas versões anteriores do .NET Framework porque qualquer consumidor da tarefa poderia descartá-los, o que a tornava inutilizável.

Sugestão

Lembre-se de que os métodos Task podem não gerar mais System.ObjectDisposedException nos casos em que o objeto é descartado. Se um aplicativo dependia dessa exceção para saber que uma tarefa foi descartada, ele deverá ser atualizado para verificar explicitamente o status da tarefa usando Status.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

O escape de System.Uri agora é compatível com RFC 3986

Detalhes

O escape do URI foi alterado no .NET Framework 4.5 para atender ao RFC 3986. As alterações específicas incluem:

• System.Uri.EscapeDataString(String) escapa caracteres reservados com base na RFC 3986.
• System.Uri.EscapeUriString(String) não escapa caracteres reservados.
• System.Uri.UnescapeDataString(String) não gerará uma exceção se encontrar uma sequência de escape inválida.
• Os caracteres escapados não reservados não são escapados.

Sugestão

• Atualize os aplicativos para não dependerem da geração de System.Uri.UnescapeDataString(String) no caso de uma sequência de escape inválida. Essas sequências devem ser detectadas diretamente agora.
• Da mesma forma, o URI com escape e sem escape, bem como as cadeias de caracteres de dados, podem variar entre o .NET Framework 4.0 e o .NET Framework 4.5 e não devem ser comparados diretamente entre as versões do .NET. Em vez disso, eles devem ser analisados e normalizados em uma única versão do .NET antes que qualquer comparação seja feita.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• Uri.EscapeDataString(String)
• Uri.EscapeUriString(String)
• Uri.UnescapeDataString(String)

Dados

Os dados do Sql_variant usam a ordenação sql_variant em vez da ordenação de banco de dados

Detalhes

Os dados do sql_variant usam a ordenação sql_variant em vez da ordenação de banco de dados.

Sugestão

Essa alteração aborda os possíveis dados corrompidos caso a ordenação do banco de dados seja diferente da ordenação sql_variant. Os aplicativos que dependem de dados corrompidos podem apresentar falhas.

Nome	Valor
Escopo	Transparente
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

SqlBulkCopy usa a codificação de coluna de destino para cadeias de caracteres

Detalhes

Quando dados são inseridos em uma coluna, o System.Data.SqlClient.SqlBulkCopy usa a codificação da coluna de destino em vez da codificação padrão para os tipos VARCHAR e CHAR. Essa alteração elimina a possibilidade de corrompimento de dados causada pelo uso da codificação padrão quando a coluna de destino não usa a codificação padrão. Em casos raros, um aplicativo existente pode gerar uma exceção SqlException quando a mudança na codificação produz dados que são grandes demais para caber na coluna de destino.

Sugestão

Espere que System.Data.SqlClient.SqlBulkCopy não corrompa os dados devido a diferenças de codificação. Se as cadeias de caracteres perto do limite de tamanho da coluna de destino estiverem sendo copiadas, talvez seja necessário codificar previamente os dados (a serem copiados para verificar se os dados serão ajustados na coluna de destino) ou capturar System.Data.SqlClient.SqlExceptions.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Data.SqlClient.SqlBulkCopy
• SqlBulkCopy(SqlConnection)

SqlConnection não pode mais se conectar ao SQL Server 1997 ou a bancos de dados usando o adaptador VIA

Detalhes

Conexões a bancos de dados do SQL Server usando o Protocolo VIA (Virtual Interface Adapter) não têm mais suporte. O protocolo usado para se conectar a um banco de dados do SQL Server fica visível na cadeia de conexão. Uma conexão VIA conterá via:<nomedoservidor>. Se o aplicativo estiver se conectando ao SQL por meio de um protocolo diferente do VIA (tcp: ou np: por exemplo), nenhuma alteração interruptiva será encontrada. Além disso, não há mais suporte para conexões com o SQL Server 7 (1997).

Sugestão

O protocolo VIA foi preterido, de modo que um protocolo alternativo deve ser usado para se conectar a bancos de dados SQL. O protocolo mais usado é o TCP/IP. Para obter mais informações sobre como se conectar por meio de TCP/IP, confira Habilitar o protocolo TCP/IP para uma instância de banco de dados. Se o banco de dados for acessado somente de dentro de uma intranet, o protocolo de pipes compartilhado poderá fornecer um melhor desempenho se a rede estiver lenta.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• SqlConnection(String)
• SqlConnection(String, SqlCredential)

SqlConnection.Open falha no Windows 7 com BSP ou LSP Winsock não IFS presente

Detalhes

Open() e OpenAsync(CancellationToken) falharão no .NET Framework 4.5 se forem executados em um computador com Windows 7 sem a presença de um BSP ou LSP não IFS Winsock. Para determinar se um BSP ou LSP não IFS está instalado, use o comando netsh WinSock Show Catalog e analise cada item Winsock Catalog Provider Entry retornado. Se o valor de Sinalizadores de Serviço tiver o bit 0x20000 definido, o provedor usará os identificadores do IFS e funcionará corretamente. Se o bit 0x20000 estiver limpo (não definido), trata-se de um BSP ou LSP não IFS.

Sugestão

Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework. Como alternativa, ele pode ser evitado com a remoção de qualquer LSP Winsock não IFS instalado.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Depurador

Valores nulos de união não são visíveis no depurador até uma etapa posterior

Detalhes

Um bug no .NET Framework 4.5 faz com que os valores definidos por meio de uma operação de união nula não fiquem visíveis no depurador imediatamente após a operação de atribuição ser executada na versão de 64 bits do Framework.

Sugestão

Colocar um tempo adicional no depurador fará com que o valor do local/campo seja atualizado corretamente. Além disso, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Entity Framework

Mudança de comportamento nas APIs DDL (Linguagem de Definição de Dados)

Detalhes

O comportamento dos APIs DDL quando AttachDBFilename é especificado foi alterado da seguinte forma:

• As cadeias de conexão não precisam especificar um valor de Catálogo Inicial. Anteriormente, AttachDBFilename e Catálogo Inicial eram obrigatórios.
• Se AttachDBFilename e Catálogo Inicial forem especificados e o arquivo MDF especificado existir, o método DatabaseExists retornará true. Anteriormente, o valor retornado era false.
• Se AttachDBFilename e Catálogo Inicial forem especificados e o arquivo MDF especificado existir, chamar o método DeleteDatabase excluirá o arquivo.
• Se DeleteDatabase for chamado quando a cadeia de conexão especificar um valor de AttachDBFilename com um MDF e um Catálogo Inicial que não existam, o método gerará uma exceção InvalidOperationException. Anteriormente, ele gerava uma exceção SqlException.

Sugestão

Essas alterações facilitam a criação de ferramentas e aplicativos que usam APIs de DDL. Essas alterações podem afetar a compatibilidade do aplicativo nas seguintes situações:

• O usuário escreve um código que executará um comando DROP DATABASE diretamente em vez de chamar DeleteDatabase se DatabaseExists retornar true. Isso quebrará o código existente se o banco de dados não estiver anexado, mas um arquivo MDF existir.
• O usuário escreve um código que espera o método DeleteDatabase para gerar uma SqlException em vez de uma InvalidOperationException quando os arquivos de Catálogo Inicial e de MDF não existes.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Tratamento de exceção diferente para os métodos ObjectContext.CreateDatabase e DbProviderServices.CreateDatabase

Detalhes

Começando com o .NET Framework 4.5, se houver falha na criação do banco de dados, os métodos CreateDatabase tentarão remover o banco de dados vazio. Se essa operação for bem-sucedida, a System.Data.SqlClient.SqlException original será propagada (em vez da System.InvalidOperationException que sempre era gerada no .NET Framework 4.0)

Sugestão

Ao capturar um System.InvalidOperationException durante a execução de CreateDatabase() ou CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), agora, SQLExceptions também devem ser capturadas.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• ObjectContext.CreateDatabase()
• DbProviderServices.CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection)

O EntityFramework 6.0 carrega muito lentamente em aplicativos inicializados pelo Visual Studio

Detalhes

A inicialização de um aplicativo no Visual Studio 2013 que usa o EntityFramework 6.0 pode ser muito lenta.

Sugestão

Esse problema foi corrigido no EntityFramework 6.0.2. Atualize o EntityFramework para evitar o problema de desempenho.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

O nome do arquivo de log criado pelo método ObjectContext.CreateDatabase foi alterado para corresponder às especificações do SQL Server

Detalhes

Quando o método System.Data.Objects.ObjectContext.CreateDatabase() é chamado diretamente ou usando Code First com o provedor SqlClient e um valor AttachDBFilename na cadeia de conexão, ele cria um arquivo de log chamado filename_log.ldf em vez de filename.ldf (onde filename é o nome do arquivo especificado pelo valor AttachDBFilename). Essa alteração melhora a depuração ao fornecer um arquivo de log chamado de acordo com especificações do SQL Server.

Sugestão

Se o nome do arquivo de log for importante para um aplicativo, o aplicativo deverá ser atualizado para esperar o formato de nome de arquivo _log.ldf padrão.

	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• ObjectContext.CreateDatabase()

ObjectContext.Translate e ObjectContext.ExecuteStoreQuery agora dão suporte ao tipo de enumeração

Detalhes

No .NET Framework 4.0, o parâmetro genérico T dos métodos ObjectContext.Translate e ObjectContext.ExecuteStoreQuery não pode ser uma enumeração. Agora há suporte para esse cenário.

Sugestão

Quando Translate ou ExecuteStoreQuery era chamado em um tipo de enumeração no .NET Framework 4.0, '0' era retornado. Se esse comportamento fosse desejável, as chamadas deveriam ser substituídas por uma constante 0 (ou o equivalente de enumeração dele).

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• ObjectContext.Translate<TElement>(DbDataReader)
• ObjectContext.Translate<TEntity>(DbDataReader, String, MergeOption)
• ObjectContext.ExecuteStoreQuery<TElement>(String, Object[])
• ObjectContext.ExecuteStoreQuery<TEntity>(String, String, MergeOption, Object[])

LINQ

Enumerable.Empty<TResult> sempre retorna instância em cache

Detalhes

Começando com o .NET Framework 4.5, Empty<TResult>() sempre retorna um IEnumerable<T> de instância interna em cache. Anteriormente, o Empty<TResult>() armazenava em cache um IEnumerable<T> vazio no momento em que a API era chamada, significando que, em algumas condições nas quais Empty<TResult>() era chamado de forma rápida e simultânea, diferentes instâncias do tipo poderiam ser retornadas para diferentes chamadas à API.

Sugestão

Como o comportamento anterior não era determinístico, é improvável que o código dependesse dele. No entanto, na improbabilidade de que enumeráveis vazios estivessem sendo comparados e, às vezes, esperados que fosse diferentes, matrizes vazias explícitas deviam ser criadas (new T[0]) em vez de usar Empty<TResult>().

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• Enumerable.Empty<TResult>()

MEF (Managed Extensibility Framework)

Os catálogos do MEF implementam IEnumerable e, portanto, não podem mais ser usados para criar um serializador

Detalhes

A partir do .NET Framework 4.5, os catálogos do MEF implementam IEnumerable e, portanto, não podem mais ser usados para criar um serializador (objeto System.Xml.Serialization.XmlSerializer). Tentar serializar um catálogo de MEF gera uma exceção.

Sugestão

Não é mais possível usar o MEF para criar um serializador

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Rede

Desserialização de objetos MailMessage serializados no .NET Framework 4.5 pode falhar

Detalhes

A partir do .NET Framework 4.5, os objetos MailMessage podem incluir caracteres não ASCII. No .NET Framework 4, somente caracteres ASCII têm suporte. Os objetos MailMessage que contêm caracteres não ASCII e são serializados no .NET Framework 4.5 ou versões posteriores não podem ser desserializados no .NET Framework 4.

Sugestão

Verifique se o seu código fornece tratamento de exceção ao desserializar um objeto MailMessage.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Web.Mail.MailMessage

System.Net.PeerToPeer.Collaboration não disponível no Windows 8

Detalhes

O namespace System.Net.PeerToPeer.Collaboration não está disponível no Windows 8 ou superior.

Sugestão

Os aplicativos que dão suporte ao Windows 8 ou superior devem ser atualizados para não dependerem desse namespace ou de seus membros.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Net.PeerToPeer.Collaboration

Imprimindo

Dados gravados em PrintSystemJobInfo.JobStream devem estar no formato XPS

Detalhes

A propriedade JobStream expõe o fluxo de um trabalho de impressão. O usuário pode enviar dados brutos para o sistema operacional subjacente que imprime os componentes gravando-os neste fluxo. A partir do .NET Framework 4.5 no Windows 8 e em versões posteriores do sistema operacional Windows, os dados gravados nesse fluxo devem estar no formato XPS como um fluxo de pacote.

Sugestão

Para mostrar o conteúdo impresso, você tem duas opções:

• Use a classe XpsDocumentWriter para produzir conteúdo de impressão. Essa é a alternativa recomendada.
• Garanta que os dados enviados ao fluxo retornado pela propriedade JobStream estão no formato XPS como um fluxo de pacote.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• PrintSystemJobInfo.JobStream

Serialização

BinaryFormatter pode não conseguir localizar o tipo do contexto LoadFrom

Detalhes

A partir do .NET Framework 4.5, várias alterações de System.Xml.Serialization.XmlSerializer podem causar diferenças na desserialização ao usar System.Runtime.Serialization.Formatters.Binary.BinaryFormatter para desserializar tipos que foram carregados no contexto LoadFrom. Essas alterações se devem a novas maneiras como System.Xml.Serialization.XmlSerializer agora carrega um tipo, o que causa um comportamento diferente quando um System.Runtime.Serialization.Formatters.Binary.BinaryFormatter tenta desserializar esse tipo posteriormente. O associador de serialização padrão não pesquisa automaticamente o contexto LoadFrom, embora isso possa ter funcionado em algumas circunstâncias com base no comportamento antigo do XmlSerializer. Devido às alterações, quando um tipo está sendo carregado de um assembly carregado em um contexto diferente, um System.IO.FileNotFoundException pode ser acionado.

Aviso

A serialização binária com BinaryFormatter pode ser perigosa. Para obter mais informações, confira o Guia de segurança do BinaryFormatter.

Sugestão

Se essa exceção for observada, a propriedade Binder do System.Runtime.Serialization.Formatters.Binary.BinaryFormatter poderá ser definida como um associador personalizado que encontrará o tipo correto.

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

E, em seguida, o associador personalizado:

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
• BinaryFormatter.Deserialize(Stream)
• BinaryFormatter.Deserialize(Stream, HeaderHandler)

SoapFormatter não pode desserializar Hashtable e objetos de coleção ordenados semelhantes

Detalhes

O System.Runtime.Serialization.Formatters.Soap.SoapFormatter não garante que objetos serializados em uma versão do .NET Framework serão desserializados com êxito em uma versão diferente. Especificamente, algumas coleções ordenadas (como System.Collections.Hashtable) tiveram membros adicionados entre a 4.0 e a 4.5, portanto, os objetos desses tipos não poderão ser desserializados com o .NET Framework 4.0 se tiverem sido serializados com o .NET Framework 4.5. Observe que se os dados serializados forem serializados e desserializados com a mesma versão do .NET Framework, nenhum problema ocorrerá.

Sugestão

A serialização System.Runtime.Serialization.Formatters.Soap.SoapFormatter deve ser substituída pela serialização System.Runtime.Serialization.Formatters.Binary.BinaryFormatter ou System.Runtime.Serialization.NetDataContractSerializer para resistir às alterações do .NET Framework.

Aviso

A serialização binária com BinaryFormatter pode ser perigosa. Para obter mais informações, confira o Guia de segurança do BinaryFormatter.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• SoapFormatter.Serialize(Stream, Object)
• SoapFormatter.Serialize(Stream, Object, Header[])
• SoapFormatter.Deserialize(Stream)
• SoapFormatter.Deserialize(Stream, HeaderHandler)

XmlSerializer falha durante a serialização de um tipo que oculta um membro acessível com um inacessível

Detalhes

Ao serializar um tipo derivado, o System.Xml.Serialization.XmlSerializer pode falhar se o tipo contiver um campo ou propriedade inacessível que oculta (por meio da palavra-chave "new") um campo ou propriedade do mesmo nome que estava acessível anteriormente (público, por exemplo) no tipo base.

Sugestão

Esse problema pode ser resolvido tornando o novo membro oculto acessível ao System.Xml.Serialization.XmlSerializer (marcando-o como público, por exemplo). Como alternativa, a seguinte configuração reverterá para o comportamento System.Xml.Serialization.XmlSerializer 4.0, que corrigirá o problema:

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• XmlSerializer.Serialize(Stream, Object)
• XmlSerializer.Serialize(TextWriter, Object)
• XmlSerializer.Serialize(Object, XmlSerializationWriter)
• XmlSerializer.Serialize(XmlWriter, Object)
• XmlSerializer.Serialize(Stream, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(TextWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String, String)

Aplicativos Web

Controles de host do navegador gerenciado do .NET Framework 1.1 e 2.0 estão bloqueados

Detalhes

Hospedar esses controles é bloqueado no Internet Explorer.

Sugestão

O Internet Explorer falhará ao iniciar um aplicativo que usa o navegador gerenciado que hospeda controles. O comportamento anterior pode ser restaurado definindo o valor EnableIEHosting da subchave do registro HKLM/SOFTWARE/MICROSOFT/.NETFramework para 1 para sistemas x86 e para processos de 32 bits em sistemas de x64, e definindo o valor EnableIEHosting da subchave do registro HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework para 1 para processos de 64 bits em sistemas de x64.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Communication Foundation (WCF)

Códigos de erro de maxRequestLength ou maxReceivedMessageSize são diferentes

Detalhes

Mensagens nos serviços Web WCF hospedadas no IIS (Serviços de Informações da Internet) ou no ASP.NET Development Server que excedam maxRequestLength (no ASP.NET) ou maxReceivedMessageSize (no WCF) têm códigos de erro diferentes. O código de status HTTP foi alterado de 400 (Solicitação Incorreta) para 413 (Entidade de Solicitação Muito Longa), e as mensagens que excederam as configurações de maxRequestLength ou maxReceivedMessageSize lançarão uma exceção System.ServiceModel.ProtocolException. Isso inclui os casos em que o modo de transferência é Streamed.

Sugestão

Essa alteração facilita a depuração nos casos em que o comprimento da mensagem excede os limites permitidos pelo ASP.NET ou WCF. É necessário modificar os códigos que executam o processamento baseado em um código de status HTTP 400.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

O objeto System.ServiceModel.Web.WebServiceHost não adiciona mais um ponto de extremidade padrão

Detalhes

O objeto WebServiceHost não adicionará um ponto de extremidade padrão se um ponto de extremidade explícito tiver sido adicionado pelo código do aplicativo.

Sugestão

Se os usuários forem esperar para poderem se conectar a um ponto de extremidade padrão e outros pontos de extremidade explícitos forem adicionados ao System.ServiceModel.Web.WebServiceHost, os pontos de extremidade padrão também deverão ser explicitamente adicionados (usando System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()).

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• ServiceHost.AddServiceEndpoint(Type, Binding, String)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, String, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHostBase.AddServiceEndpoint(ServiceEndpoint)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri, Uri)

O método Replace nas URLs do OData é desabilitado por padrão

Detalhes

A partir do .NET Framework 4.5, o método Replace em URLs do OData é desabilitado por padrão. Quando o Replace do OData está desabilitado (agora por padrão), qualquer solicitação de usuário, incluindo funções de substituição (que são incomuns), falha.

Sugestão

Se o método de substituição for necessário (o que é incomum), ele poderá ser reabilitado por meio das configurações (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction). No entanto, um método de substituição habilitado pode dar abertura para vulnerabilidades de segurança, devendo ser usado somente depois de análise cuidadosa.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Data.Services.DataService<T>

Windows Forms

PreviewLostKeyboardFocus será chamado repetidamente se seu manipulador mostrar uma caixa de mensagem do Windows Forms

Detalhes

A partir do .NET Framework 4.5, chamar MessageBox.Show de um manipulador PreviewLostKeyboardFocus fará com que o manipulador seja acionado novamente quando a caixa de mensagem for fechada, possivelmente resultando em um loop infinito de caixas de mensagem.

Sugestão

Há duas opções para contornar esse problema:

• Ele pode ser evitado chamando MessageBox.Show em vez de MessageBox.Show.
• Ele pode ser evitado mostrando a caixa de mensagem de um manipulador de eventos LostKeyboardFocus (em oposição a um manipulador de eventos System.Windows.UIElement.PreviewLostKeyboardFocus).

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

A propriedade CheckForOverflowUnderflow do WinForm agora é true para System.Drawing

Detalhes

A propriedade CheckForOverflowUnderflow do o assembly System.Drawing.dll está definida como true.

Sugestão

Anteriormente, quando os estouros ocorriam, o resultado teria sido truncado silenciosamente. Agora, uma exceção System.OverflowException é gerada.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Presentation Foundation (WPF)

Acessar os itens selecionados de um DataGrid do WPF em um manipulador do evento UnloadingRow do DataGrid pode gerar NullReferenceException

Detalhes

Por causa de um bug no .NET Framework 4.5, os manipuladores de eventos DataGrid que envolvem a remoção de uma linha podem gerar System.NullReferenceException se acessarem as propriedades System.Windows.Controls.Primitives.Selector.SelectedItem ou System.Windows.Controls.Primitives.MultiSelector.SelectedItems de DataGrid.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

Chamar DataGrid.CommitEdit de um manipulador CellEditEnding descarta o foco

Detalhes

Chamar CommitEdit() de um dos manipuladores de eventos System.Windows.Controls.DataGrid do System.Windows.Controls.DataGrid.CellEditEnding faz com que System.Windows.Controls.DataGrid perca o foco.

Sugestão

Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework. Como alternativa, ele pode ser evitado com a nova seleção explícita de System.Windows.Controls.DataGrid após chamada de System.Windows.Controls.DataGrid.CommitEdit().

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Chamar Items.Refresh em uma ListBox, ListView ou DataGrid do WPF com itens selecionados pode exibir itens duplicados no elemento

Detalhes

No .NET Framework 4.5, chamar ListBox.Items.Refresh do código enquanto itens estiverem selecionados em uma System.Windows.Controls.ListBox pode fazer com que os itens selecionados sejam duplicados na lista. Ocorre um problema semelhante com System.Windows.Controls.ListView e System.Windows.Controls.DataGrid. Isso foi corrigido no .NET Framework 4.6.

Sugestão

Esse problema pode ser contornado de forma programática cancelando a seleção dos itens antes de chamar System.Windows.Data.CollectionView.Refresh() e selecionando-os novamente após a conclusão da chamada. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• CollectionView.Refresh()

FlowDocument pode mostrar uma linha extra de texto

Detalhes

Em alguns casos, um elemento FlowDocument exibirá uma linha de texto extra ao ser executado no .NET Framework 4.5, em comparação a como ele foi exibido quando executado no .NET Framework 4.0. Não conhecemos casos em que a alteração fez com que qualquer texto fosse exibido de forma inadequada ou ilegível, mas textos omitidos de uma exibição de FlowDocument podem aparecer.

Sugestão

Em alguns casos, diminuir a propriedade PageHeight do elemento de exibição em 1 pode restaurar o número anterior de linhas exibidas.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• FlowDocument()
• FlowDocument(Block)
• FlowDocumentReader()
• FlowDocumentPageViewer()
• DocumentPageView()

GlyphRun.ComputeInkBoundingBox() e FormattedText.Extent retornam valores diferentes começando no .NET Framework 4.5

Detalhes

Foram feitas melhorias em ComputeInkBoundingBox() e Extent do .NET Framework 4.5 para resolver problemas em que as caixas eram muito pequenas para o glifos contidos em alguns casos no .NET Framework 4.0. Como resultado, algumas caixas delimitadoras serão maiores a partir do .NET Framework 4.5, resultando em diferenças sutis no layout da interface do usuário.

Sugestão

Lembre-se de que alguns tamanhos de caixa delimitadora do glifo aumentaram. Essas alterações geralmente aprimorarão a apresentação e os testes de caixa de clique, mas se o comportamento anterior (anterior ao .NET 4.5) for desejado, ele poderá ser aceito com a adição da seguinte entrada ao arquivo app.config:

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• GlyphRun.ComputeInkBoundingBox()
• FormattedText.Extent

Não é possível rolar intermitentemente para o item na parte inferior em ItemsControls (como ListBox e DataGrid) ao usar DataTemplates personalizados

Detalhes

Em alguns casos, um bug no .NET Framework 4.5 está fazendo com que ItemsControls (como System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid etc.) não rolem para o item na parte inferior ao usar DataTemplates personalizados. Se houver uma tentativa de rolagem pela segunda vez (depois da rolagem de volta), ela funcionará.

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.2 e pode ser solucionado com o upgrade para essa versão (ou uma versão posterior) do .NET Framework. Como alternativa, os usuários ainda podem arrastar as barras de rolagem para os itens finais nessas coleções, mas pode ser necessário tentar duas vezes para obter êxito.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Items.Clear não remove duplicatas de SelectedItems

Detalhes

Suponha que um Seletor (com seleção múltipla habilitada) tenha duplicatas em sua coleção System.Windows.Controls.Primitives.MultiSelector.SelectedItems – o mesmo item é exibido mais de uma vez. A remoção desses itens da fonte de dados (por exemplo, chamando Items.Clear) falha ao removê-los de System.Windows.Controls.Primitives.MultiSelector.SelectedItems; somente a primeira instância é removida. Além disso, o uso subsequente de System.Windows.Controls.Primitives.MultiSelector.SelectedItems (por exemplo, SelectedItems.Clear()) pode encontrar problemas, como System.ArgumentException, pois System.Windows.Controls.Primitives.MultiSelector.SelectedItems contém itens que não estão mais na fonte de dados.

Sugestão

Atualize se possível para o .NET Framework 4.6.2.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• MultiSelector.SelectedItems

Problema de associação de ListBoxItem IsSelected com ObservableCollection<T>.Move

Detalhes

Chamar Move(Int32, Int32) ou MoveItem(Int32, Int32) em uma coleção associada a um System.Windows.Controls.ListBox com itens selecionados pode gerar comportamento imprevisível em seleções ou cancelamentos de seleção futuros de itens System.Windows.Controls.ListBox.

Sugestão

Chamar System.Collections.ObjectModel.Collection<T>.Remove(T) e System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) em vez de Move(Int32, Int32) é uma solução alternativa para esse problema. Como alternativa, esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

Novos valores de enumeração em PageRangeSelection do WPF

Detalhes

Os dois novos membros (System.Windows.Controls.PageRangeSelection.CurrentPage e System.Windows.Controls.PageRangeSelection.SelectedPages) foram adicionados à enumeração System.Windows.Controls.PageRangeSelection.

Sugestão

Na maioria das vezes, essas mudanças não afetarão o código do usuário. O código que depende de um número específico de elementos existentes nas chamadas GetNames(Type) ou GetValues(Type) no tipo System.Windows.Controls.PageRangeSelection deve ser modificado.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.PageRangeSelection

PreviewLostKeyboardFocus será chamado repetidamente se seu manipulador mostrar uma caixa de mensagem do Windows Forms

Detalhes

A partir do .NET Framework 4.5, chamar MessageBox.Show de um manipulador PreviewLostKeyboardFocus fará com que o manipulador seja acionado novamente quando a caixa de mensagem for fechada, possivelmente resultando em um loop infinito de caixas de mensagem.

Sugestão

Há duas opções para contornar esse problema:

• Ele pode ser evitado chamando MessageBox.Show em vez de MessageBox.Show.
• Ele pode ser evitado mostrando a caixa de mensagem de um manipulador de eventos LostKeyboardFocus (em oposição a um manipulador de eventos System.Windows.UIElement.PreviewLostKeyboardFocus).

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

Clicar com o botão direito do mouse em um cabeçalho de linha do DataGrid do WPF altera a seleção de DataGrid

Detalhes

Clicar com o botão direito do mouse em um cabeçalho de linha System.Windows.Controls.DataGrid enquanto várias linhas estão selecionadas altera a seleção de System.Windows.Controls.DataGrid para somente a linha em questão.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid()

A rolagem em uma TreeView ou uma ListBox agrupada do WPF em um VirtualizingStackPanel pode causar travamentos em um aplicativo

Detalhes

No .NET Framework v4.5, rolar em uma System.Windows.Controls.TreeView do WPF em um painel de pilha virtualizado poderá causar travamentos se houver margens no visor (entre os itens na System.Windows.Controls.TreeView, por exemplo, ou em um elemento ItemsPresenter). Além disso, em alguns casos, itens de tamanhos diferentes no modo de exibição podem causar instabilidade, mesmo se não houver margens.

Sugestão

Esse bug pode ser evitado com a o upgrade para o .NET Framework 4.5.1. Como alternativa, as margens poderão ser removidas das coleções de exibições (como System.Windows.Controls.TreeViews) em painéis de pilha virtualizados se todos os itens contidos forem do mesmo tamanho.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

Elementos DataTemplate do WPF agora são visíveis à UIA

Detalhes

Anteriormente, os elementos System.Windows.DataTemplate eram invisíveis à Automação da Interface do Usuário. A partir da versão 4.5, a Automação da Interface do Usuário detectar esses elementos. Isso é útil em muitos casos, mas pode arruinar os testes que dependem das árvores UIA que não contêm elementos System.Windows.DataTemplate.

Sugestão

Os testes de Automação da Interface do Usuário para esse aplicativo talvez precisem ser atualizados para contabilizar a árvore UIA agora, incluindo elementos System.Windows.DataTemplate anteriormente invisíveis. Por exemplo, os testes que esperam que alguns elementos fiquem próximos uns dos outros agora podem precisar esperar elementos UIA anteriormente invisíveis entre eles. Ou os testes que dependem de determinadas contagens ou de índices para elementos UIA talvez precisem ser atualizados com novos valores.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataTemplate()
• DataTemplate(Object)

DispatcherSynchronizationContext.CreateCopy do WPF agora retorna uma nova cópia em vez da instância atual

Detalhes

No .NET Framework 4, CreateCopy() retornava uma referência à instância atual, basicamente como uma otimização de desempenho. No .NET Framework 4.5, ele retorna uma nova instância que possibilita, pela primeira vez, concluir que referências iguais indicam que o thread em execução está no contexto de sincronização correto. É provável que o código que verifica a identidade dessas referências seja afetado, mas, por causa da alteração, o código que chama CreateCopy() deve ser testado como parte da migração para o .NET Framework 4.5 ou mais recente.

Sugestão

Lembre-se de que CreateCopy() agora retornará um novo objeto System.Threading.SynchronizationContext. Anteriormente, o código que usava a equivalência de referências gerada dessa maneira não estava de fato verificado se ela estava no contexto apropriado, mas isso foi corrigido no .NET Framework 4.5 ou posteriores. Embora não haja probabilidade de causar problemas, praticar os caminhos de código afetados deve ser suficiente para determinar se isso impõe algum problema.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• DispatcherSynchronizationContext.CreateCopy()

O padrão da Caixa de Texto do WPF é o limite de 100 na ação desfazer

Detalhes

No .NET Framework 4.5, o limite padrão de desfazer para uma caixa de texto do WPF é 100 (em vez de ser ilimitado como no .NET Framework 4.0)

Sugestão

Se um limite de 100 da ação desfazer for muito baixo, o limite poderá ser definido explicitamente com UndoLimit.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.TextBox

O texto selecionado TextBox do WPF aparece em cor diferente quando a caixa de texto está inativa

Detalhes

No .NET Framework 4.5, quando um controle de caixa de texto do WPF estiver inativo (não tem o foco), o texto selecionado dentro da caixa terá uma cor diferente de quando o controle estiver ativo.

Sugestão

O comportamento anterior (.NET Framework 4.0) poderá ser restaurado definindo a propriedade AreInactiveSelectionHighlightBrushKeysSupported como false.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Windows.Controls.TextBox

TreeViewItem do WPF deve ser usado em um TreeView

Detalhes

Foi introduzida na versão 4.5 uma alteração que restringe o uso de elementos System.Windows.Controls.TreeViewItem fora de um System.Windows.Controls.TreeView. Isso se manifesta sob as seguintes condições:

• O pai visual de System.Windows.Controls.TreeViewItem não é um painel. (Um System.Windows.Controls.TreeViewItem gerado para um System.Windows.Controls.TreeView terá um painel como pai)
• O System.Windows.Controls.TreeViewItem é descendente de um System.Windows.Controls.VirtualizingStackPanel que funciona como o "host de itens" de um controle de lista (ListBox, DataGrid, ListView etc.). A virtualização não precisa ser habilitada.
• O System.Windows.Controls.VirtualizingStackPanel é a rolagem de itens (ScrollUnit="Item").
• Alguém chama VirtualizingStackPanel.MakeVisible(v) para rolar um elemento v no modo de exibição. Isso pode ser feito explícita ou implicitamente de várias maneiras; talvez a maneira mais comum seja simplesmente clicar em v para fornecer a ele o foco do teclado.
• A cadeia de pais visuais de v para o System.Windows.Controls.VirtualizingStackPanel passa pelo System.Windows.Controls.TreeViewItem.

Em outras palavras, isso é visto quando um System.Windows.Controls.TreeViewItem é usado fora de um System.Windows.Controls.TreeView e o usuário clica em um descendente do System.Windows.Controls.TreeViewItem para colocá-lo no modo de exibição. Se o System.Windows.Controls.TreeViewItem não tiver descendentes focalizáveis, você nunca verá esse problema. Um exemplo de situação em que isso acontece é quando um System.Windows.Controls.TreeViewItem é a raiz de um DataTemplate. Quando esse problema for atingido, haverá uma InvalidCastException que ocorrerá dentro da estrutura do WPF.

Sugestão

Um hotfix será disponibilizado para isso.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Workflow Foundation (WF)

System.Activities agora é APTCA

Detalhes

O assembly é marcado com o atributo System.Security.AllowPartiallyTrustedCallersAttribute.

Sugestão

Classes derivadas não podem ser marcadas com System.Security.SecurityCriticalAttribute. Anteriormente, os tipos derivados precisavam ser marcados com o System.Security.SecurityCriticalAttribute. No entanto, essa mudança não deve ter um impacto real.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

O WF agora serializa Expressions.Literal<T> DateTimes de modo diferente (interrompe analisadores XAML personalizados)

Detalhes

O objeto ValueSerializer associado converterá um objeto System.DateTime ou System.DateTimeOffset cujos componentes Second e System.DateTime.Millisecond são diferentes de zero e (para um valor de System.DateTime) cuja propriedade Kind não é Unspecified para a sintaxe de elemento de propriedade em vez de uma cadeia de caracteres. Essa alteração permite que os valores System.DateTime e System.DateTimeOffset completem um ciclo. Os analisadores XAML personalizados que assumem que a entrada XAML está na sintaxe de atributo não funcionará corretamente.

Sugestão

Essa alteração permite que os valores System.DateTime e System.DateTimeOffset completem um ciclo. Os analisadores XAML personalizados que assumem que a entrada XAML está na sintaxe de atributo não funcionará corretamente.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

XML, XSLT

XmlSchemaException agora define posições de linhas corretamente

Detalhes

Se o valor SetLineInfo é passado para o método Load e um erro de validação ocorre, as propriedades LineNumber e LinePosition contêm agora a linha de informações.

Sugestão

O código de tratamento de exceção que supõe que LineNumber e LinePosition não serão definidas deverá ser atualizado, uma vez que essas propriedades agora serão definidas corretamente quando SetLineInfo for usado durante o carregamento de XML.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• LoadOptions.SetLineInfo

Expansão da entidade DTD de XmlTextReader é limitada a 10.000.000 caracteres

Detalhes

A expansão da entidade DTD agora é limitada a 10.000.000 de caracteres. O carregamento de arquivos XML sem expansão de entidade DTD ou com expansão de entidade DTD limitada não é afetado. Arquivos com entidades DTD que se expandem para mais de 10.000.000 caracteres falham ao carregar e geram uma exceção.

Sugestão

Se o limite da expansão da entidade DTD for muito inferior a 10.000.000, o valor poderá ser substituído pela propriedade MaxCharactersFromEntities. Um System.Xml.XmlReaderSettings com o valor System.Xml.XmlReaderSettings.MaxCharactersFromEntities correto pode ser transmitido para XmlReader.Create que usa System.Xml.XmlReaderSettings (ou seja, Create(String, XmlReaderSettings))

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Xml.XmlTextReader
• XmlTextReader()
• XmlTextReader(Stream)
• XmlTextReader(Stream, XmlNameTable)
• XmlTextReader(Stream, XmlNodeType, XmlParserContext)
• XmlTextReader(TextReader)
• XmlTextReader(TextReader, XmlNameTable)
• XmlTextReader(String)
• XmlTextReader(String, Stream)
• XmlTextReader(String, Stream, XmlNameTable)
• XmlTextReader(String, TextReader)
• XmlTextReader(String, TextReader, XmlNameTable)
• XmlTextReader(String, XmlNameTable)
• XmlTextReader(String, XmlNodeType, XmlParserContext)
• XmlTextReader(XmlNameTable)

Compatibilidade com versões posteriores do XSLT agora funciona

Detalhes

No .NET Framework 4, a compatibilidade com versões posteriores do XSLT 1.0 tinha os seguintes problemas:

• O carregamento de uma folha de estilos falhava se sua versão era definida como 2.0 e o analisador encontrava uma compilação XSLT 1.0 não reconhecida.
• O constructo xsl:sort não conseguia classificar os dados se a versão da folha de estilos fosse definida como 1.1. No .NET Framework 4.5, esses problemas foram corrigidos, e o modo de compatibilidade com versões posteriores do XSLT 1.0 funciona corretamente.

Sugestão

A maioria dos aplicativos não deve ser afetada, mas os dados serão classificados diferentemente em alguns casos agora que xsl:sort é respeitado. Se xsl:sort for usado em folhas de estilo 1.1, verifique se os aplicativos dependem da ordem sem classificação dos dados. Se os aplicativos dependerem do comportamento de classificação de 4.0, remova xsl:sort da folha de estilos.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• System.Xml.Xsl.XslCompiledTransform

Mensagem de exceção da folha de estilos XSLT alterada

Detalhes

No .NET Framework 4.5, o texto da mensagem de erro quando um arquivo XSLT é muito complexo é "A folha de estilos é muito complexa". Em versões anteriores, a mensagem de erro era "Erro de compilação XSLT". O código do aplicativo que depende do texto da mensagem de erro não funcionará mais. No entanto, os tipos de exceção permanecem os mesmos, de modo que essa modificação não deve ter um impacto real.

Sugestão

Atualize qualquer código de aplicativo, dependendo da mensagem de exceção dessa condição de erro, para esperar a nova mensagem ou (ainda melhor) atualize o código para depender somente do tipo de exceção (System.Xml.Xsl.XsltException), que não foi alterado.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• XslCompiledTransform.Load(String)
• XslCompiledTransform.Load(Type)
• XslCompiledTransform.Load(XmlReader)
• XslCompiledTransform.Load(IXPathNavigable)
• XslCompiledTransform.Load(MethodInfo, Byte[], Type[])
• XslCompiledTransform.Load(String, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(XmlReader, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(IXPathNavigable, XsltSettings, XmlResolver)

.NET Framework 4.5.1

ADO.NET

Agora, ADO.NET tentará reconectar automaticamente conexões SQL interrompidas

Detalhes

A partir do .NET Framework 4.5.1, o .NET Framework tentará reconectar automaticamente conexões SQL interrompidas. Embora, normalmente, isso torne os aplicativos mais confiáveis, há casos de borda em que um aplicativo precisa saber que a conexão foi perdida para tomar medidas sobre a reconexão.

Sugestão

Se esse recurso for indesejável devido a preocupações de compatibilidade, ele poderá ser desabilitado por meio da configuração da propriedade System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount de uma cadeia de conexão (ou System.Data.SqlClient.SqlConnectionStringBuilder) para 0.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.1
Tipo	Runtime

APIs afetadas

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Núcleo

Um ConcurrentDictionary serializado no .NET Framework 4.5 com NetDataContractSerializer não pode ser desserializado pelo .NET Framework 4.5.1 ou 4.5.2

Detalhes

Devido a alterações internas no tipo, objetos ConcurrentDictionary<TKey,TValue> serializados com o .NET Framework 4.5 usando o System.Runtime.Serialization.NetDataContractSerializer não podem ser desserializados no .NET Framework 4.5.1 ou no .NET Framework 4.5.2. Observe que mover-se no outro sentido (serializar com o .NET Framework 4.5.x e desserializar com o .NET Framework 4.5) funciona. Da mesma forma, todas as serializações entre versões 4. x funcionam com o .NET Framework 4.6. A possibilidade de serializar e desserializar com uma única versão do .NET Framework não é afetada.

Sugestão

Se for necessário serializar e desserializar um System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> entre o .NET Framework 4.5 e o .NET Framework 4.5.1/4.5.2, um serializador diferente, como o System.Runtime.Serialization.DataContractSerializer, deverá ser usado em vez do System.Runtime.Serialization.NetDataContractSerializer. Como alternativa, uma vez que esse problema foi resolvido no .NET Framework 4.6, ele pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

ConcurrentQueue<T>.TryPeek pode retornar um nulo errado por meio de seus parâmetros de saída

Detalhes

Em alguns cenários multithread, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) pode retornar true, mas popular o parâmetro de saída com um valor nulo (em vez do valor correto, inspecionado).

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.1. O upgrade para esse Framework resolverá o problema.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

• ConcurrentQueue<T>.TryPeek(T)

COR_PRF_GC_ROOT_HANDLEs não estão sendo enumerados por criadores de perfil

Detalhes

No .NET Framework v4.5.1, a API de criação de perfil RootReferences2(), de maneira incorreta, nunca retorna COR_PRF_GC_ROOT_HANDLE (que, em vez disso, é retornada como COR_PRF_GC_ROOT_OTHER). Esse problema foi corrigido a partir do .NET Framework 4.6.

Sugestão

Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Desserialização de objetos em domínios de aplicativo podem falhar

Detalhes

Em alguns casos, quando um aplicativo usa dois ou mais domínios de aplicativo com bases de aplicativo diferentes, a tentativa de desserializar objetos no contexto da chamada lógica nos domínios de aplicativo aciona uma exceção.

Sugestão

Consulte Mitigação: desserialização de objetos em domínios de aplicativos.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

EventListener trunca cadeias de caracteres com nulos inseridos

Detalhes

System.Diagnostics.Tracing.EventListener trunca cadeias de caracteres com nulos inseridos. Os caracteres nulos não são compatíveis com a classe System.Diagnostics.Tracing.EventSource. A alteração afeta apenas os aplicativos que usam System.Diagnostics.Tracing.EventListener para ler dados System.Diagnostics.Tracing.EventSource no processo e que usam caracteres nulos como delimitadores.

Sugestão

Os dados System.Diagnostics.Tracing.EventSource devem ser atualizados, se possível, para não usar caracteres nulos inseridos.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.1
Tipo	Runtime

APIs afetadas

• EventListener()
• EventListener.EnableEvents(EventSource, EventLevel)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)

EventSource.WriteEvent deve passar a WriteEvent os mesmos parâmetros que recebeu (mais ID)

Detalhes

O runtime agora impõe o contrato que especifica o seguinte: uma classe derivada de System.Diagnostics.Tracing.EventSource que define um método de evento ETW deve chamar o método de classe base EventSource.WriteEvent com a ID do evento seguido dos mesmos argumentos que o método de evento ETW passou.

Sugestão

Uma exceção System.IndexOutOfRangeException será acionada se um System.Diagnostics.Tracing.EventListener ler dados System.Diagnostics.Tracing.EventSource no processo de uma origem de evento que viola esse contrato.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

As sobrecargas Marshal.SizeOf e Marshal.PtrToStructure interrompem o código dinâmico

Detalhes

A partir do .NET Framework 4.5.1, a associação dinâmica aos métodos SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr) ou PtrToStructure<T>(IntPtr, T) (por meio do Windows PowerShell, IronPython ou da palavra-chave dinâmica do C#, por exemplo) pode resultar em MethodInvocationExceptions, pois novas sobrecargas desses métodos que foram adicionadas podem ser ambíguas para os mecanismos de script.

Sugestão

Atualize os scripts para indicar claramente qual sobrecarga deve ser usada. Normalmente, isso pode ser feito convertendo explicitamente os parâmetros de tipo dos métodos como Type. Clique neste link para obter mais detalhes e exemplos de como contornar o problema.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Algumas APIs .NET causam EntryPointNotFoundExceptions de primeira chance

Detalhes

No .NET Framework 4.5, um pequeno número de métodos .NET começou a gerar System.EntryPointNotFoundExceptions de primeira chance. Essas exceções eram tratadas dentro do .NET Framework, mas podiam interromper a automação de teste que não esperava as exceções de primeira instância. Essas mesmas APIs interrompem alguns cenários ApiVerifier quando HighVersionLie é habilitado.

Sugestão

Esse bug pode ser evitado com a o upgrade para o .NET Framework 4.5.1. Como alternativa, a automação de teste pode ser atualizada para não interromper exceções System.EntryPointNotFoundException de primeira chance.

	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

Adaptadores de fluxo do WinRT não chamam mais FlushAsync automaticamente ao fechar

Detalhes

Em aplicativos da Windows Store, os adaptadores de fluxo do Windows Runtime não chamam mais o método de FlushAsync do método Dispose.

Sugestão

Essa alteração deve ser transparente. Os desenvolvedores podem restaurar o comportamento anterior gravando um código como este:

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

Nome	Valor
Escopo	Transparente
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Dados

Agora, ADO.NET tentará reconectar automaticamente conexões SQL interrompidas

Detalhes

A partir do .NET Framework 4.5.1, o .NET Framework tentará reconectar automaticamente conexões SQL interrompidas. Embora, normalmente, isso torne os aplicativos mais confiáveis, há casos de borda em que um aplicativo precisa saber que a conexão foi perdida para tomar medidas sobre a reconexão.

Sugestão

Se esse recurso for indesejável devido a preocupações de compatibilidade, ele poderá ser desabilitado por meio da configuração da propriedade System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount de uma cadeia de conexão (ou System.Data.SqlClient.SqlConnectionStringBuilder) para 0.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.1
Tipo	Runtime

APIs afetadas

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Serialização

NetDataContractSerializer falha ao desserializar um ConcurrentDictionary serializado com uma versão diferente do .NET

Detalhes

Por design, o System.Runtime.Serialization.NetDataContractSerializer poderá ser usado somente se as extremidades de serialização e desserialização compartilharem os mesmos tipos CLR. Portanto, não há garantia de que um objeto serializado com uma versão do .NET Framework possa ser desserializado por uma versão diferente. System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> é um tipo conhecido por não ser desserializado corretamente se serializado com o .NET Framework 4.5 ou anterior e desserializado com o .NET Framework 4.5.1 ou posterior.

Sugestão

Há uma série de possíveis soluções alternativas para esse problema:

• Atualizar o computador de serialização para usar o .NET Framework 4.5.1 também.
• Usar System.Runtime.Serialization.DataContractSerializer em vez de System.Runtime.Serialization.NetDataContractSerializer, pois ele não espera os mesmos tipos CLR nas extremidades de serialização e desserialização.
• Usar System.Collections.Generic.Dictionary<TKey,TValue> em vez de System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>, uma vez que ele não apresenta essa quebra específica entre 4.5 e >4.5.1.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

• NetDataContractSerializer.Deserialize(Stream)

Windows Communication Foundation (WCF)

MinFreeMemoryPercentageToActiveService agora é respeitado

Detalhes

Essa configuração estabelece a memória mínima que deve estar disponível no servidor para que um serviço WCF possa ser ativado. Ela foi projetada para evitar exceções System.OutOfMemoryException. No .NET Framework 4.5, essa configuração não tinha nenhum efeito. No .NET Framework 4.5.1, essa configuração é observada.

Sugestão

Ocorrerá uma exceção se a memória livre disponível no servidor Web for menor que a porcentagem definida pela definição de configuração. Alguns serviços WCF iniciados com êxito e executados em um ambiente de memória restrito agora podem falhar.

Nome	Valor
Escopo	Secundária
Versão	4.5.1
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Presentation Foundation (WPF)

Rolar em um TreeView no WPF ou ListBox agrupado em um VirtualizingStackPanel pode fazer com que o aplicativo pare de responder

Detalhes

No .NET Framework v4.5, rolar em uma System.Windows.Controls.TreeView do WPF em um painel de pilha virtualizado poderá causar travamentos se houver margens no visor (entre os itens na System.Windows.Controls.TreeView, por exemplo, ou em um elemento ItemsPresenter). Além disso, em alguns casos, itens de tamanhos diferentes no modo de exibição podem causar instabilidade, mesmo se não houver margens.

Sugestão

Esse bug pode ser evitado com a o upgrade para o .NET Framework 4.5.1. Como alternativa, as margens poderão ser removidas das coleções de exibições (como System.Windows.Controls.TreeViews) em painéis de pilha virtualizados se todos os itens contidos forem do mesmo tamanho.

Nome	Valor
Escopo	Principal
Versão	4.5
Tipo	Runtime

APIs afetadas

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

.NET Framework 4.5.2

ASP.NET

O MVC do ASP.NET agora escapa espaços em cadeias de caracteres passadas por meio dos parâmetros de rota

Detalhes

Para estar em conformidade com a RFC 2396, os espaços nos caminhos de rota agora são escapados na população dos parâmetros de ação usando uma rota. Portanto, /controller/action/some data que, antes correspondia à rota /controller/action/{data} e fornecia some data como o parâmetro de dados, agora fornecerá some%20data.

Sugestão

O código deve ser atualizado para não escapar parâmetros de cadeia de caracteres de uma rota. Se o URI original for necessário, ele poderá ser acessado com a API RequestUri.OriginalString.

Nome	Valor
Escopo	Secundária
Versão	4.5.2
Tipo	Runtime

APIs afetadas

• RouteAttribute(String)

Não é mais possível definir EnableViewStateMac como false

Detalhes

O ASP.NET não permite mais que os desenvolvedores especifiquem <pages enableViewStateMac=&quot;false&quot;/> ou <@Page EnableViewStateMac=&quot;false&quot; %>. O MAC (Message Authentication Code) de estado da exibição agora é obrigatório em todas as solicitações com estado de exibição embutido. Apenas aplicativos que definiram explicitamente a propriedade EnableViewStateMac como false são afetados.

Sugestão

EnableViewStateMac deve ser considerada true e qualquer erro MAC resultante deverá ser resolvido (conforme explicado nestas diretrizes, que contêm várias resoluções que variam de acordo com as características do que está causando os erros MAC).

Nome	Valor
Escopo	Principal
Versão	4.5.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Aplicativos ASP.NET MVC4 de criação de perfil podem causar um erro fatal do mecanismo de execução

Detalhes

Os criadores de perfil que usam NGEN/assemblies de perfil podem causar pane em aplicativos ASP.NET MVC4 de criação de perfil na inicialização com o "Erro Fatal do Mecanismo de Execução".

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.2. Como alternativa, o criador de perfil pode evitar esse problema especificando COR_PRF_DISABLE_ALL_NGEN_IMAGES em sua máscara de evento.

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Dados

SqlConnection.Open falha no Windows 7 com BSP ou LSP Winsock não IFS presente

Detalhes

Open() e OpenAsync(CancellationToken) falharão no .NET Framework 4.5 se forem executados em um computador com Windows 7 sem a presença de um BSP ou LSP não IFS Winsock. Para determinar se um BSP ou LSP não IFS está instalado, use o comando netsh WinSock Show Catalog e analise cada item Winsock Catalog Provider Entry retornado. Se o valor de Sinalizadores de Serviço tiver o bit 0x20000 definido, o provedor usará os identificadores do IFS e funcionará corretamente. Se o bit 0x20000 estiver limpo (não definido), trata-se de um BSP ou LSP não IFS.

Sugestão

Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework. Como alternativa, ele pode ser evitado com a remoção de qualquer LSP Winsock não IFS instalado.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Entity Framework

EF não gera mais para QueryViews com características específicas

Detalhes

O Entity Framework já não gera uma exceção System.StackOverflowException quando um aplicativo executa uma consulta que envolve QueryView com uma propriedade de navegação de 0..1 que tenta incluir as entidades relacionadas como parte da consulta. Por exemplo, chamando .Include(e => e.RelatedNavProp).

Sugestão

Essa alteração afeta apenas o código que usa relacionamentos de QueryViews com 1-0..1 ao executar consultas que chamam .Include. Isso melhora a confiabilidade e deve ser transparente para quase todos os aplicativos. No entanto, se causa um comportamento inesperado, é possível desabilitá-lo adicionando a seguinte entrada à seção <appSettings> do arquivo de configuração do aplicativo:

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Interrupção de aceitação será revertida de geração de SQL 4.5 diferente para geração de SQL 4.0 mais simples

Detalhes

As consultas que produzem instruções JOIN e contêm uma chamada para uma operação de limitação sem usar primeiro o OrderBy agora produzem um SQL mais simples. Após a atualização para o .NET Framework 4.5, essas consultas produziram SQLs mais complicados do que as versões anteriores.

Sugestão

Por padrão, esse recurso está desabilitado. Se Entity Framework gera instruções JOIN adicionais que causam a degradação do desempenho, pode-se habilitar esse recurso adicionando a seguinte entrada à seção <appSettings> do arquivo (app.config) de configuração da aplicação:

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

Nome	Valor
Escopo	Transparente
Versão	4.5.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

Windows Presentation Foundation (WPF)

Chamar DataGrid.CommitEdit de um manipulador CellEditEnding descarta o foco

Detalhes

Chamar CommitEdit() de um dos manipuladores de eventos System.Windows.Controls.DataGrid do System.Windows.Controls.DataGrid.CellEditEnding faz com que System.Windows.Controls.DataGrid perca o foco.

Sugestão

Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework. Como alternativa, ele pode ser evitado com a nova seleção explícita de System.Windows.Controls.DataGrid após chamada de System.Windows.Controls.DataGrid.CommitEdit().

Nome	Valor
Escopo	Microsoft Edge
Versão	4.5
Tipo	Runtime

APIs afetadas

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Não é possível rolar intermitentemente para o item na parte inferior em ItemsControls (como ListBox e DataGrid) ao usar DataTemplates personalizados

Detalhes

Em alguns casos, um bug no .NET Framework 4.5 está fazendo com que ItemsControls (como System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid etc.) não rolem para o item na parte inferior ao usar DataTemplates personalizados. Se houver uma tentativa de rolagem pela segunda vez (depois da rolagem de volta), ela funcionará.

Sugestão

Esse problema foi corrigido no .NET Framework 4.5.2 e pode ser solucionado com o upgrade para essa versão (ou uma versão posterior) do .NET Framework. Como alternativa, os usuários ainda podem arrastar as barras de rolagem para os itens finais nessas coleções, mas pode ser necessário tentar duas vezes para obter êxito.

Nome	Valor
Escopo	Secundária
Versão	4.5
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

WPF gera um processo wisptis.exe que pode congelar o mouse

Detalhes

Um problema foi introduzido na versão 4.5.2 que faz com que wisptis.exe seja gerado e possa congelar a entrada do mouse.

Sugestão

A correção desse problema está disponível em uma versão de serviço do .NET Framework 4.5.2 (hotfix de rollup 3026376) ou por meio da atualização para o .NET Framework 4.6.

Nome	Valor
Escopo	Principal
Versão	4.5.2
Tipo	Runtime

APIs afetadas

Não detectáveis com a análise de API.

XML

Alterações de análise XML

Nome	Valor
Escopo	Secundária
Versão	4.5.2
Tipo	Runtime

Detalhes

Por motivos de segurança, as seguintes alterações foram introduzidas em APIs de análise XML:

• XmlReaderSettings.MaxCharactersFromEntities é definido como dez milhões quando XmlReaderSettings é inicializado.
• XmlReaderSettings.XmlResolver é definido como null por padrão.

Observação

XmlReaderSettings é usado por todos os analisadores XML e, portanto, embora essa alteração ajude no caso XmlReader, ela também afeta outros cenários.

Sugestão

Para voltar ao comportamento anterior, você pode definir um valor no Registro. Adicione um valor DWORD chamado EnableLegacyXmlSettings à chave do Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML e defina o valor dele como 1. Adicione também o valor do Registro no hive HKEY_CURRENT_USER.

APIs afetadas

• System.Xml.XmlReaderSettings.MaxCharactersFromEntities
• System.Xml.XmlReaderSettings.XmlResolver

Além disso, qualquer API XML que dependa direta ou indiretamente de XmlResolver é afetada.