Alterações de tempo de execução para a migração do .NET Framework 4.0 para 4.5.1Runtime Changes for Migration from .NET Framework 4.0 to 4.5.1

Introduction

Runtime changes affect all apps that are running under a .NET Framework it was not compiled against and that use a particular feature.

In the topics that describe runtime changes, we have classified individual items by their expected impact, as follows:

Major This is a significant change that affects a large number of apps or that requires substantial modification of code.

Minor This is a change that affects a small number of apps or that requires minor modification of code.

Edge case This is a change that affects apps under very specific scenarios that are not common.

Transparent This is a change that has no noticeable effect on the app's developer or user. The app should not require modification because of this change.

Se você estiver migrando do .NET Framework 4.0 para 4.5.1, examine os seguintes tópicos sobre problemas de compatibilidade do aplicativo que podem afetar seu aplicativo:If you are migrating from the .NET Framework 4.0 to 4.5.1, review the following topics for application compatibility issues that may affect your app:

ADO.NETADO.NET

Agora, ADO.NET tentará reconectar automaticamente conexões SQL interrompidasADO.NET now attempts to automatically reconnect broken SQL connections

DetalhesDetails A partir do .NET Framework 4.5.1, o .NET Framework tentará reconectar automaticamente conexões SQL interrompidas.Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 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.Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.
SugestãoSuggestion Se esse recurso for indesejável devido a preocupações de compatibilidade, ele poderá ser desabilitado por meio da configuração da propriedade ConnectRetryCount de uma cadeia de conexão (ou SqlConnectionStringBuilder) para 0.If this feature is undesirable due to compatibility concerns, it can be disabled by setting the ConnectRetryCount property of a connection string (or SqlConnectionStringBuilder) to 0.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

ASP.NETASP.NET

GridViews com AllowCustomPaging definido como verdadeiro pode acionar o evento PageIndexChanging ao deixar a página final do modo de exibiçãoGridViews with AllowCustomPaging set to true may fire the PageIndexChanging event when leaving the final page of the view

DetalhesDetails Um bug no .NET Framework 4.5 faz com que PageIndexChanging, às vezes, não seja acionado para GridViews com AllowCustomPaging habilitado.A bug in the .NET Framework 4.5 causes PageIndexChanging to sometimes not fire for GridViews that have enabled AllowCustomPaging.
SugestãoSuggestion Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework. Como solução alternativa, o aplicativo pode fazer um BindGrid explícito em qualquer Page_Load que respeite essas condições (o GridView está na última página e LastPageSize é diferente de PageSize).As a work-around, the app can do an explicit BindGrid on any Page_Load that would hit these conditions (the GridView is on the last page and LastPageSize is different from 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.Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

A propriedade HttpRequest.ContentEncoding proíbe a UTF7HttpRequest.ContentEncoding property prohibits UTF7

DetalhesDetails A partir do .NET Framework 4.5, a codificação UTF-7 está proibida nos corpos de HttpRequest.Beginning in .NET Framework 4.5, UTF-7 encoding is prohibited in HttpRequests' bodies. Os dados para aplicativos que dependem de dados de entrada UTF-7 não serão decodificados corretamente em alguns casos.Data for applications that depend on incoming UTF-7 data will not decode properly in some cases.
SugestãoSuggestion De modo ideal, os aplicativos devem ser atualizados para não usar a codificação UTF-7 em HttpRequest.Ideally, applications should be updated to not use UTF-7 encoding in HttpRequests. De modo alternativo, o comportamento herdado pode ser restaurado usando o atributo aspnet:AllowUtf7RequestContentEncoding do elemento appSettings.Alternatively, legacy behavior can be restored by using the aspnet:AllowUtf7RequestContentEncoding attribute of the appSettings element.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

HttpUtility.JavaScriptStringEncode escapa o E comercialHttpUtility.JavaScriptStringEncode escapes ampersand

DetalhesDetails A partir do .NET Framework 4.5, JavaScriptStringEncode(String) ignora o caractere E comercial (&).Starting with the .NET Framework 4.5, JavaScriptStringEncode(String) escapes the ampersand (&) character.
SugestãoSuggestion 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.If your app depends on the previous behavior of this method, you can add an aspnet:JavaScriptDoNotEncodeAmpersand setting to the ASP.NET appSettings element in your configuration file.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

IPad não deve ser usado no arquivo de funcionalidades personalizadas, pois agora é uma funcionalidade do navegadorIPad should not be used in custom capabilities file because it is now a browser capability

DetalhesDetails 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 personalizadosBeginning in .NET Framework 4.5, iPad is an identifier in the default ASP.NET browser capabilities file, so it should not be used in a custom capabilities file
SugestãoSuggestion Se funcionalidades específicas do iPad forem exigidas, será necessário modificar o comportamento dele configurando funcionalidades na refID do gateway predefinido "IPad" em vez de gerar uma nova ID "IPad" pela correspondência do agente do usuário.If iPad-specific capabilities are required, it is necessary to modify iPad behavior by setting capabilities on the pre-defined gateway refID "IPad" instead of by generating a new "IPad" ID by user agent matching.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

O evento Page.LoadComplete não faz mais com que o controle System.Web.UI.WebControls.EntityDataSource invoque a associação de dadosPage.LoadComplete event no longer causes System.Web.UI.WebControls.EntityDataSource control to invoke data binding

DetalhesDetails O evento LoadComplete não faz mais com que o controle EntityDataSource chame a associação de dados para alterações par criar/atualizar/excluir parâmetros.The LoadComplete event no longer causes the EntityDataSource control to invoke data binding for changes to create/update/delete parameters. 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 SqlDataSource e ObjectDataSource.This change eliminates an extraneous trip to the database, prevents the values of controls from being reset, and produces behavior that is consistent with other data controls, such as SqlDataSource and 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.This change produces different behavior in the unlikely event that applications rely on invoking data binding in the LoadComplete event.
SugestãoSuggestion Se houver necessidade de vinculação de dados, invoque manualmente a associação de dados em um evento que seja anterior no post-back.If there is a need for databinding, manually invoke databind in an event that is earlier in the post-back.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Aplicativos ASP.NET MVC4 de criação de perfil podem causar Erro Fatal do Mecanismo de ExecuçãoProfiling ASP.Net MVC4 apps can lead to Fatal Execution Engine Error

DetalhesDetails 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".Profilers using NGEN /Profile assemblies may crash profiled ASP.NET MVC4 applications on startup with a 'Fatal Execution Engine Exception'
SugestãoSuggestion Esse problema foi corrigido no .NET Framework 4.5.2.This issue is fixed in the .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.Alternatively, the profiler may avoid this issue by specifying COR_PRF_DISABLE_ALL_NGEN_IMAGES in its event mask.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Compartilhamento de estado de sessão com StateServer Asp.Net exige que todos os servidores no web farm usem a mesma versão do .NET FrameworkSharing session state with Asp.Net StateServer requires all servers in the web farm to use the same .NET Framework version

DetalhesDetails Ao habilitar o estado de sessão StateServer, todos os servidores no web farm fornecido devem usar a mesma versão do .NET Framework para o estado ser compartilhado corretamente.When enabling StateServer session state, all of the servers in the given web farm must use the same version of the .NET Framework in order for state to be properly shared.
SugestãoSuggestion Certifique-se de atualizar as versões do .NET Framework em servidores Web que compartilham o estado ao mesmo tempo.Be sure to upgrade .NET Framework versions on web servers that share state at the same time.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

WebUtility.HtmlDecode não decodifica mais sequências de entrada inválidasWebUtility.HtmlDecode no longer decodes invalid input sequences

DetalhesDetails 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.By default, decoding methods no longer decode an invalid input sequence into an invalid UTF-16 string. Em vez disso, eles retornam a entrada original.Instead, they return the original input.
SugestãoSuggestion 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.The change in decoder output should matter only if you store binary data instead of UTF-16 data in strings. 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.To explicitly control this behavior, set the aspnet:AllowRelaxedUnicodeDecoding attribute of the appSettings element to true to enable legacy behavior or to false to enable the current behavior.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

NúcleoCore

Um ConcurrentDictionary serializado no .NET Framework 4.5 com NetDataContractSerializer não pode ser desserializado pelo .NET Framework 4.5.1 ou 4.5.2A ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2

DetalhesDetails Devido a alterações internas no tipo, objetos ConcurrentDictionary<TKey,TValue> serializados com o .NET Framework 4.5 usando o 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.Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the NetDataContractSerializer cannot be deserialized in the .NET Framework 4.5.1 or in the .NET Framework 4.5.2.Note that moving in the other direction (serializing with the .NET Framework 4.5.x and deserializing with the .NET Framework 4.5) works. 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.Similarly, all 4.x cross-version serialization works with the .NET Framework 4.6.Serializing and deserializing with a single version of the .NET Framework is not affected.
SugestãoSuggestion Se for necessário serializar e desserializar um ConcurrentDictionary<TKey,TValue> entre o .NET Framework 4.5 e o .NET Framework 4.5.1/4.5.2, um serializador alternativo como o serializador DataContractSerializer ou BinaryFormatter deve ser usado em vez do NetDataContractSerializer. Como alternativa, uma vez que esse problema é resolvido no .NET Framework 4.6, isso pode ser solucionado com a atualização para essa versão do .NET Framework.If it is necessary to serialize and deserialize a ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, an alternate serializer like the DataContractSerializer or BinaryFormatter serializer should be used instead of the NetDataContractSerializer.Alternatively, because this issue is addressed in the .NET Framework 4.6, it may be solved by upgrading to that version of the .NET Framework.
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

Assemblies compilados com interrupções Regex.CompileToAssembly entre o 4.0 e o 4.5Assemblies compiled with Regex.CompileToAssembly breaks between 4.0 and 4.5

DetalhesDetails 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.If an assembly of compiled regular expressions is built with the .NET Framework 4.5 but targets the .NET Framework 4, attempting to use one of the regular expressions in that assembly on a system with .NET Framework 4 installed throws an exception.
SugestãoSuggestion Para solucionar esse problema, pode-se seguir uma das seguintes alternativas:To work around this problem, you can do either of the following:
  • Compilar o assembly que contém as expressões regulares com o .NET Framework 4.Build the assembly that contains the regular expressions with the .NET Framework 4.
  • Use uma expressão regular interpretada.Use an interpreted regular expression.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

BlockingCollection<T>.TryTakeFromAny não é mais geradoBlockingCollection<T>.TryTakeFromAny does not throw anymore

DetalhesDetails 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.If one of the input collections is marked completed, TryTakeFromAny(BlockingCollection<T>[], T) no longer returns -1 and TakeFromAny(BlockingCollection<T>[], T) no longer throws an exception. 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.This change makes it possible to work with collections when one of the collections is either empty or completed, but the other collection still has items that can be retrieved.
SugestãoSuggestion 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.If TryTakeFromAny returning -1 or TakeFromAny throwing were used for control-flow purposes in cases of a blocking collection being completed, such code should now be changed to use .Any(b => b.IsCompleted) to detect that condition.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Mudança no comportamento de métodos Task.WaitAll com argumentos de tempo limiteChange in behavior for Task.WaitAll methods with time-out arguments

DetalhesDetails 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.Task.WaitAll behavior was made more consistent in .NET Framework 4.5.In the .NET Framework 4, these methods behaved inconsistently. 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 AggregateException.When the time-out expired, if one or more tasks were completed or canceled before the method call, the method threw an AggregateException exception. 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.When the time-out expired, if no tasks were completed or canceled before the method call, but one or more tasks entered these states after the method call, the method returned 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 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.In the .NET Framework 4.5, these method overloads now return false if any tasks are still running when the time-out interval expired, and they throw an AggregateException exception only if an input task was cancelled (regardless of whether it was before or after the method call) and no other tasks are still running.
SugestãoSuggestion Se um AggregateException era capturado como um meio de detectar uma tarefa cancelada antes da invocação da chamada de WaitAll, esse código deverá fazer a mesma detecção por meio da propriedade IsCanceled [por exemplo: .Any(t => t.IsCanceled)], porque o .NET Framework 4.6 acionará esse caso apenas se todas as tarefas esperadas forem concluídas antes do tempo limite.If an AggregateException was being caught as a means of detecting a task that was cancelled prior to the WaitAll call being invoked, that code should instead do the same detection via the IsCanceled property (for example: .Any(t => t.IsCanceled)) since .NET Framework 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Compilador compatível com encaminhamento de tipos ao destinar várias vezes o mscorlibCompiler support for type forwarding when multi-targeting mscorlib

DetalhesDetails 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.A new CodeDOM feature allows a compiler to compile against the targeted version of mscorlib.dll instead of the .NET Framework 4.5 version of mscorlib.dll.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

COR_PRF_GC_ROOT_HANDLEs não estão sendo enumerados por criadores de perfilCOR_PRF_GC_ROOT_HANDLEs are not being enumerated by profilers

DetalhesDetails 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).In the .NET Framework v4.5.1, the profiling API RootReferences2() is incorrectly never returning COR_PRF_GC_ROOT_HANDLE (they are returned as COR_PRF_GC_ROOT_OTHER instead). Esse problema foi corrigido a partir do .NET Framework 4.6.This issue is fixed beginning in the .NET Framework 4.6.
SugestãoSuggestion Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

Desserialização de objetos em domínios de aplicativo podem falharDeserialization of objects across appdomains can fail

DetalhesDetails 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.In some cases, when an app uses two or more app domains with different application bases, trying to deserialize objects in the logical call context across app domains throws an exception.
SugestãoSuggestion Confira Mitigação: Desserialização de objetos em domínios do aplicativoSee Mitigation: Deserialization of Objects Across App Domains
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

EventListeners do ETW não capturam eventos dos provedores com palavras-chave explícitas (como o provedor TPL)ETW EventListeners do not capture events from providers with explicit keywords (like the TPL provider)

DetalhesDetails EventListeners do ETW com uma máscara de palavra-chave em branco não capturam eventos corretamente dos provedores com palavras-chave explícitas.ETW EventListeners with a blank keyword mask do not properly capture events from providers with explicit keywords. No .NET Framework 4.5, o provedor TPL começou a fornecer palavras-chave explícitas e disparou esse problema.In the .NET Framework 4.5, the TPL provider began providing explicit keywords and triggered this issue. No .NET Framework 4.6, EventListeners foram atualizados para não apresentarem mais esse problema.In the .NET Framework 4.6, EventListeners have been updated to no longer have this issue.
SugestãoSuggestion Para contornar esse problema, substitua as chamadas para EnableEvents(EventSource, EventLevel) com chamadas para a sobrecarga EnableEvents que especifica explicitamente a máscara "quaisquer palavras-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.To work around this problem, replace calls to EnableEvents(EventSource, EventLevel) with calls to the EnableEvents overload that explicitly specifies the "any keywords" mask to use: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

EventListener trunca cadeias de caracteres com nulos inseridosEventListener truncates strings with embedded nulls

DetalhesDetails EventListener trunca cadeias de caracteres com nulos inseridos.EventListener truncates strings with embedded nulls. Os caracteres nulos não são compatíveis com a classe EventSource.Null characters are not supported by the EventSource class. A alteração afeta apenas os aplicativos que usam EventListener para ler dados EventSource no processo e que usam caracteres nulos como delimitadores.The change only affects apps that use EventListener to read EventSource data in process and that use null characters as delimiters.
SugestãoSuggestion Os dados EventSource devem ser atualizados, se possível, para não usar caracteres nulos inseridos.EventSource data should be updated, if possible, to not use embedded null characters.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

EventSource.WriteEvent deve passar a WriteEvent os mesmos parâmetros que recebeu (mais ID)EventSource.WriteEvent impls must pass WriteEvent the same parameters that it received (plus ID)

DetalhesDetails O tempo de execução agora aplica o contrato que especifica o seguinte: Uma classe derivada de 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.The runtime now enforces the contract that specifies the following: A class derived from EventSource that defines an ETW event method must call the base class EventSource.WriteEvent method with the event ID followed by the same arguments that the ETW event method was passed.
SugestãoSuggestion Uma exceção IndexOutOfRangeException será acionada se um EventListener ler dados EventSource no processo de uma origem de evento que viola esse contrato.An IndexOutOfRangeException exception is thrown if an EventListener reads EventSource data in process for an event source that violates this contract.
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

Exceções durante o processamento não observado em System.Threading.Tasks.Task não são mais propagadas no thread do finalizadorExceptions during unobserved processing in System.Threading.Tasks.Task no longer propagate on finalizer thread

DetalhesDetails Como a classe Task representa uma operação assíncrona, ela captura todas as exceções não graves que ocorrem durante o processamento assíncrono.Because the Task class represents an asynchronous operation, it catches all non-severe exceptions that occur during asynchronous processing. 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.In the .NET Framework 4.5, if an exception is not observed and your code never waits on the task, the exception will no longer propagate on the finalizer thread and crash the process during garbage collection. Essa alteração melhora a confiabilidade de aplicativos que usam a classe Task para executar processamento assíncrono não observado.This change enhances the reliability of applications that use the Task class to perform unobserved asynchronous processing.
SugestãoSuggestion 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 tempo de execução.If an app depends on unobserved asynchronous exceptions propagating to the finalizer thread, the previous behavior can be restored by providing an appropriate handler for the UnobservedTaskException event, or by setting a runtime configuration element.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

O algoritmo List.Sort foi alteradoList.Sort algorithm changed

DetalhesDetails A partir do .NET Framework 4.5, o algoritmo de classificação de List<T> foi alterado (para ser uma classificação introspectiva em vez de uma classificação rápida).Beginning in .NET Framework 4.5, List<T>'s sort algorithm has changed (to be an introspective sort instead of a quick sort). A classificação de List<T> nunca foi estável, mas essa alteração pode fazer com que cenários diferentes sejam classificados de maneiras instáveis.List<T>'s sort has never been stable, but this change may cause different scenarios to sort in unstable ways. Isso significa apenas que itens equivalentes podem ser classificados em ordens diferentes em chamadas posteriores da API.That simply means that equivalent items may sort in different orders in subsequent calls of the API.
SugestãoSuggestion 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.Because the old sort algorithm was also unstable (though in slightly different ways), there should be no code that depends on equivalent items always sorting in a particular order. 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.If there are instances of code depending upon that and being lucky with the old behavior, that code should be updated to use a comparer that will deterministically sort the items in the desired order.
EscopoScope TransparenteTransparent
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

As sobrecargas Marshal.SizeOf e Marshal.PtrToStructure interrompem o código dinâmicoMarshal.SizeOf and Marshal.PtrToStructure overloads break dynamic code

DetalhesDetails 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.Beginning in the .NET Framework 4.5.1, dynamically binding to the methods SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr), or PtrToStructure<T>(IntPtr, T), (via Windows PowerShell, IronPython, or the C# dynamic keyword, for example) can result in MethodInvocationExceptions because new overloads of these methods have been added that may be ambiguous to the scripting engines.
SugestãoSuggestion Atualize os scripts para indicar claramente qual sobrecarga deve ser usada.Update scripts to clearly indicate which overload should be used. Normalmente, isso pode ser feito convertendo explicitamente os parâmetros de tipo dos métodos como Type.This can typically done by explicitly casting the methods' type parameters as Type. Clique neste link para obter mais detalhes e exemplos de como contornar o problema.See this link for more detail and examples of how to workaround the issue.
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

Ausência do Moniker da Estrutura de Destino resulta no comportamento da versão 4.0Missing Target Framework Moniker results in 4.0 behavior

DetalhesDetails Os aplicativos sem um TargetFrameworkAttribute aplicado no nível de assembly serão executados automaticamente usando a semântica (quirks) do .NET Framework 4.0.Applications without a TargetFrameworkAttribute applied at the assembly level will automatically run using the semantics (quirks) of the .NET Framework 4.0. Para garantir a alta qualidade, é recomendável que todos os binários sejam explicitamente atribuídos com um TargetFrameworkAttribute indicando a versão do .NET Framework com a qual eles foram criados.To ensure high quality, it is recommended that all binaries be explicitly attributed with a TargetFrameworkAttribute indicating the version of the .NET Framework they were built with. Usar um moniker da estrutura de destino em um arquivo de projeto fará com que o MSBuild aplique automaticamente um TargetFrameworkAttribute.Note that using a target framework moniker in a project file will cause MSBuild to automatically apply a TargetFrameworkAttribute.
SugestãoSuggestion O 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.A TargetFrameworkAttribute should be supplied, either through adding the attribute directly to the assembly or by specifying a target framework in the project file or through Visual Studio's project properties GUI.
EscopoScope PrincipalMajor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

System.Threading.Tasks.Task não gera mais ObjectDisposedException depois que o objeto é descartadoSystem.Threading.Tasks.Task no longer throw ObjectDisposedException after object is disposed

DetalhesDetails Exceto por IAsyncResult.AsyncWaitHandle, os métodos Tasknão geram mais uma exceção ObjectDisposedException após o objeto ser descartado. Essa alteração permite o uso de tarefas em cache.Except for IAsyncResult.AsyncWaitHandle, Task methods no longer throw an ObjectDisposedException exception after the object is disposed.This change supports the use of cached tasks. 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.For example, a method can return a cached task to represent an already completed operation instead of allocating a new task. 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.This was impossible in previous .NET Framework versions, because any consumer of the task could dispose of it, which rendered it unusable.
SugestãoSuggestion Lembre-se de que os métodos Task podem não gerar mais ObjectDisposedException nos casos em que o objeto é descartado.Be aware that Task methods may no longer throw ObjectDisposedException in cases when the object is disposed. 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.If an app was depending on this exception to know that a task was disposed, it should be updated to explicitly check the task's status using Status.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

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

DetalhesDetails O escape do URI foi alterado no .NET Framework 4.5 para atender ao RFC 3986.URI escaping has changed in .NET Framework 4.5 to support RFC 3986. As alterações específicas incluem:Specific changes include:
SugestãoSuggestion
  • Atualize os aplicativos para não dependerem da geração de UnescapeDataString(String) no caso de uma sequência de escape inválida.Update applications to not rely on UnescapeDataString(String) to throw in the case of an invalid escape sequence. Essas sequências devem ser detectadas diretamente agora.Such sequences must be detected directly now.
  • 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.Similarly, expect that Escaped and Unescaped URI and Data strings may vary from .NET Framework 4.0 and .NET Framework 4.5 and should not be compared across .NET versions directly. Em vez disso, eles devem ser analisados e normalizados em uma única versão do .NET antes que qualquer comparação seja feita.Instead, they should be parsed and normalized in a single .NET version before any comparisons are made.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Adaptadores de fluxo do WinRT não chamam mais FlushAsync automaticamente ao fecharWinRT stream adapters no long call FlushAsync automatically on close

DetalhesDetails 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.In Windows Store apps, Windows Runtime stream adapters no longer call the FlushAsync method from the Dispose method.
SugestãoSuggestion Essa alteração deve ser transparente.This change should be transparent. Os desenvolvedores podem restaurar o comportamento anterior gravando um código como este:Developers can restore the previous behavior by writing code like this:
using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}
EscopoScope TransparenteTransparent
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

DadosData

Agora, ADO.NET tentará reconectar automaticamente conexões SQL interrompidasADO.NET now attempts to automatically reconnect broken SQL connections

DetalhesDetails A partir do .NET Framework 4.5.1, o .NET Framework tentará reconectar automaticamente conexões SQL interrompidas.Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 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.Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.
SugestãoSuggestion Se esse recurso for indesejável devido a preocupações de compatibilidade, ele poderá ser desabilitado por meio da configuração da propriedade ConnectRetryCount de uma cadeia de conexão (ou SqlConnectionStringBuilder) para 0.If this feature is undesirable due to compatibility concerns, it can be disabled by setting the ConnectRetryCount property of a connection string (or SqlConnectionStringBuilder) to 0.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Os dados do Sql_variant usam a ordenação sql_variant em vez da ordenação de banco de dadosSql_variant data uses sql_variant collation rather than database collation

DetalhesDetails Os dados do sql_variant usam a ordenação sql_variant em vez da ordenação de banco de dados.sql_variant data uses sql_variant collation rather than database collation.
SugestãoSuggestion Essa alteração aborda os possíveis dados corrompidos caso a ordenação do banco de dados seja diferente da ordenação sql_variant.This change addresses possible data corruption if the database collation differs from the sql_variant collation. Os aplicativos que dependem de dados corrompidos podem apresentar falhas.Applications that rely on the corrupted data may experience failure.
EscopoScope TransparenteTransparent
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

SqlBulkCopy usa a codificação de coluna de destino para cadeias de caracteresSqlBulkCopy uses destination column encoding for strings

DetalhesDetails Quando dados são inseridos em uma coluna, o SqlBulkCopy usa a codificação da coluna de destino em vez da codificação padrão para os tipos VARCHAR e CHAR.When inserting data into a column, SqlBulkCopy uses the encoding of the destination column rather than the default encoding for VARCHAR and CHAR types. 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.This change eliminates the possibility of data corruption caused by using the default encoding when the destination column does not use the default encoding. 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.In rare cases, an existing application may throw a SqlException exception if the change in encoding produces data that is too big to fit into the destination column.
SugestãoSuggestion Espere que SqlBulkCopy não corrompa os dados devido a diferenças de codificação.Expect that SqlBulkCopy will no longer corrupt data due to encoding differences. 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 SqlExceptions.If strings near the destination column's size limit are being copied, it may be necessary to either pre-encode data (to be copied to check that the data will fit in the destination column) or catch SqlExceptions.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

SqlConnection não pode mais se conectar ao SQL Server 1997 ou a bancos de dados usando o adaptador VIASqlConnection can no longer connect to SQL Server 1997 or databases using the VIA adapter

DetalhesDetails Conexões a bancos de dados do SQL Server usando o Protocolo VIA (Virtual Interface Adapter) não têm mais suporte.Connections to SQL Server databases using the Virtual Interface Adapter (VIA) protocol are no longer supported. O protocolo usado para se conectar a um banco de dados do SQL Server fica visível na cadeia de conexão.The protocol used to connect to a SQL Server database is visible in the connection string. Uma conexão VIA conterá via:<nomedoservidor>.A VIA connection will contain via:<servername>. Se o aplicativo estiver se conectando ao SQL usando um protocolo diferente do VIA (tcp: ou np:, por exemplo), nenhuma alteração da falha será encontrada. Além disso, não há suporte para conexões com o SQL Server 7 (1997).If this app is connecting to SQL via a protocol other than VIA (tcp: or np: for example), then no breaking change will be encountered.Also, connections to SQL Server 7 (1997) are no longer supported.
SugestãoSuggestion O protocolo VIA foi preterido, de modo que um protocolo alternativo deve ser usado para se conectar a bancos de dados SQL.The VIA protocol is deprecated, so an alternative protocol should be used to connect to SQL databases. O protocolo mais usado é o TCP/IP.The most common protocol used is 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.For more information about connecting through TCP/IP, see Enable the TCP/IP protocol for a database instance. 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.If the database is only accessed from within an intranet, the shared pipes protocol may provide better performance if the network is slow.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

SqlConnection.Open falha no Windows 7 com BSP ou LSP Winsock não IFS presenteSqlConnection.Open fails on Windows 7 with non-IFS Winsock BSP or LSP present

DetalhesDetails 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.Open() and OpenAsync(CancellationToken) fail in the .NET Framework 4.5 if running on a Windows 7 machine with a non-IFS Winsock BSP or LSP are present on the computer.To determine whether a non-IFS BSP or LSP is installed, use the netsh WinSock Show Catalog command, and examine every Winsock Catalog Provider Entry item that is returned. Se o valor de Sinalizadores de Serviço tiver o bit 0x20000 definido, o provedor usará os identificadores do IFS e funcionará corretamente.If the Service Flags value has the 0x20000 bit set, the provider uses IFS handles and will work correctly. Se o bit 0x20000 estiver limpo (não definido), trata-se de um BSP ou LSP não IFS.If the 0x20000 bit is clear (not set), it is a non-IFS BSP or LSP.
SugestãoSuggestion Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework.This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. Como alternativa, ele pode ser evitado com a remoção de qualquer LSP Winsock não IFS instalado.Alternatively, it can be avoided by removing any installed non-IFS Winsock LSPs.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

DepuradorDebugger

Valores nulos de união não são visíveis no depurador até uma etapa posteriorNull coalescer values are not visible in debugger until one step later

DetalhesDetails 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.A bug in the .NET Framework 4.5 causes values set via a null coalescing operation to not be visible in the debugger immediately after the assignment operation is executed when running on the 64-bit version of the Framework.
SugestãoSuggestion Colocar um tempo adicional no depurador fará com que o valor do local/campo seja atualizado corretamente.Stepping one additional time in the debugger will cause the local/field's value to be correctly updated. 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.Also, this issue has been fixed in the .NET Framework 4.6; upgrading to that version of the Framework should solve the issue.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Entity FrameworkEntity Framework

Mudança de comportamento nas APIs DDL (Linguagem de Definição de Dados)Change in behavior in Data Definition Language (DDL) APIs

DetalhesDetails O comportamento dos APIs DDL quando AttachDBFilename é especificado foi alterado da seguinte forma:The behavior of DDL APIs when AttachDBFilename is specified has changed as follows:
  • As cadeias de conexão não precisam especificar um valor de Catálogo Inicial.Connection strings need not specify an Initial Catalog value. Anteriormente, AttachDBFilename e Catálogo Inicial eram obrigatórios.Previously, both AttachDBFilename and Initial Catalog were required.
  • Se AttachDBFilename e Catálogo Inicial forem especificados e o arquivo MDF especificado existir, o método DatabaseExists retornará true.If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, the DatabaseExists method returns true. Anteriormente, o valor retornado era false.Previously, it returned false.
  • Se AttachDBFilename e Catálogo Inicial forem especificados e o arquivo MDF especificado existir, chamar o método DeleteDatabase excluirá o arquivo.If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, calling the DeleteDatabase method deletes the files.
  • 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.If DeleteDatabase is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an InvalidOperationException exception. Anteriormente, ele gerava uma exceção SqlException.Previously, it threw a SqlException exception.
SugestãoSuggestion Essas alterações facilitam a criação de ferramentas e aplicativos que usam APIs de DDL.These changes make it easier to build tools and applications that use the DDL APIs. Essas alterações podem afetar a compatibilidade do aplicativo nas seguintes situações:These changes can affect application compatibility in the following scenarios:
  • O usuário escreve um código que executará um comando DROP DATABASE diretamente em vez de chamar DeleteDatabase se DatabaseExists retornar true.The user writes code that executes a DROP DATABASE command directly instead of calling DeleteDatabase if DatabaseExists returns true. Isso quebrará o código existente se o banco de dados não estiver anexado, mas um arquivo MDF existir.This breaks existing code If the database is not attached but the MDF file exists.
  • 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.The user writes code that expects the DeleteDatabase method to throw a SqlException rather than an InvalidOperationException when the Initial Catalog and MDF file don't exist.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Tratamento de exceção diferente para os métodos ObjectContext.CreateDatabase e DbProviderServices.CreateDatabaseDifferent exception handling for ObjectContext.CreateDatabase and DbProviderServices.CreateDatabase methods

DetalhesDetails 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.Beginning in .NET Framework 4.5, if database creation fails, CreateDatabase methods will attempt to drop the empty database. Se essa operação for bem-sucedida, a SqlException original será propagada (em vez da InvalidOperationException que sempre era gerada no .NET Framework 4.0)If that operation succeeds, the original SqlException will be propagated (instead of the InvalidOperationException that was always thrown in .NET Framework 4.0)
SugestãoSuggestion Ao capturar um InvalidOperationException durante a execução de CreateDatabase() ou CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), agora, SQLExceptions também devem ser capturadas.When catching an InvalidOperationException while executing CreateDatabase() or CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), SQLExceptions should now also be caught.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

O EntityFramework 6.0 carrega muito lentamente em aplicativos inicializados pelo Visual StudioEntityFramework 6.0 loads very slowly in apps launched from Visual Studio

DetalhesDetails A inicialização de um aplicativo no Visual Studio 2013 que usa o EntityFramework 6.0 pode ser muito lenta.Launching an app from Visual Studio 2013 that uses EntityFramework 6.0 can be very slow.
SugestãoSuggestion Esse problema foi corrigido no EntityFramework 6.0.2.This issue is fixed in EntityFramework 6.0.2. Atualize o EntityFramework para evitar o problema de desempenho.Update EntityFramework to avoid the performance issue.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

O nome do arquivo de log criado pelo método ObjectContext.CreateDatabase foi alterado para corresponder às especificações do SQL ServerLog file name created by the ObjectContext.CreateDatabase method has changed to match SQL Server specifications

DetalhesDetails Quando o método 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).When the CreateDatabase() method is called either directly or by using Code First with the SqlClient provider and an AttachDBFilename value in the connection string, it creates a log file named filename_log.ldf instead of filename.ldf (where filename is the name of the file specified by the AttachDBFilename value). Essa alteração melhora a depuração ao fornecer um arquivo de log chamado de acordo com especificações do SQL Server.This change improves debugging by providing a log file named according to SQL Server specifications.
SugestãoSuggestion 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.If the log file name is important for an app, the app should be updated to expect the standard _log.ldf file name format.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

ObjectContext.Translate e ObjectContext.ExecuteStoreQuery agora dão suporte ao tipo de enumeraçãoObjectContext.Translate and ObjectContext.ExecuteStoreQuery now support enum type

DetalhesDetails 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.In .NET Framework 4.0, the generic parameter T of ObjectContext.Translate and ObjectContext.ExecuteStoreQuery methods could not be an enum. Agora há suporte para esse cenário.That scenario is now supported.
SugestãoSuggestion Quando Translate ou ExecuteStoreQuery era chamado em um tipo de enumeração no .NET Framework 4.0, '0' era retornado.If Translate or ExecuteStoreQuery was called on an enum type in .NET Framework 4.0, '0' was returned. Se esse comportamento fosse desejável, as chamadas deveriam ser substituídas por uma constante 0 (ou o equivalente de enumeração dele).If that behavior was desirable, the calls should be replaced with a constant 0 (or the enum equivalent of it).
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

LINQLINQ

Enumerable.Empty<TResult> sempre retorna instância em cacheEnumerable.Empty<TResult> always returns cached instance

DetalhesDetails 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.Beginning in .NET Framework 4.5, Empty<TResult>() always returns a cached internal instance IEnumerable<T>.Previously, Empty<TResult>() would cache an empty IEnumerable<T> at the time the API was called, meaning that in some conditions in which Empty<TResult>() was called rapidly and concurrently, different instances of the type could be returned for different calls to the API.
SugestãoSuggestion Como o comportamento anterior não era determinístico, é improvável que o código dependesse dele.Because the previous behavior was non-deterministic, code is unlikely to depend on it. 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>().However, in the unlikely case that empty enumerables are being compared and expected to sometimes be unequal, explicit empty arrays should be created (new T[0]) instead of using Empty<TResult>().
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

MEF (Managed Extensibility Framework)Managed Extensibility Framework (MEF)

Os catálogos do MEF implementam IEnumerable e, portanto, não podem mais ser usados para criar um serializadorMEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer

DetalhesDetails 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 XmlSerializer).Starting with the .NET Framework 4.5, MEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer (XmlSerializer object). Tentar serializar um catálogo de MEF gera uma exceção.Trying to serialize a MEF catalog throws an exception.
SugestãoSuggestion Não é mais possível usar o MEF para criar um serializadorCan no longer use MEF to create a serializer
EscopoScope PrincipalMajor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

RedeNetworking

Desserialização de objetos MailMessage serializados no .NET Framework 4.5 pode falharDeserialization of MailMessage objects serialized under the .NET Framework 4.5 may fail

DetalhesDetails A partir do .NET Framework 4.5, os objetos MailMessage podem incluir caracteres não ASCII.Starting with the .NET Framework 4.5, MailMessage objects can include non-ASCII characters. No .NET Framework 4, somente caracteres ASCII têm suporte.In the .NET Framework 4, only ASCII characters are supported. 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.MailMessage objects that contain non-ASCII characters and that are serialized under the .NET Framework 4.5 or later cannot be deserialized under the .NET Framework 4.
SugestãoSuggestion Verifique se o seu código fornece tratamento de exceção ao desserializar um objeto MailMessage.Ensure that your code provides exception handling when deserializing a MailMessage object.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

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

DetalhesDetails O namespace System.Net.PeerToPeer.Collaboration não está disponível no Windows 8 ou superior.The System.Net.PeerToPeer.Collaboration namespace is unavailable on Windows 8 or above.
SugestãoSuggestion Os aplicativos que dão suporte ao Windows 8 ou superior devem ser atualizados para não dependerem desse namespace ou de seus membros.Apps that support Windows 8 or above must be updated to not depend on this namespace or its members.
EscopoScope PrincipalMajor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

ImprimindoPrinting

Dados gravados em PrintSystemJobInfo.JobStream devem estar no formato XPSData written to PrintSystemJobInfo.JobStream must be in XPS format

DetalhesDetails A propriedade JobStream expõe o fluxo de um trabalho de impressão.The JobStream property exposes the stream of a print job. 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.The user can send raw data to the underlying operating system printing components by writing to this stream.Starting with the .NET Framework 4.5 on Windows 8 and later versions of the Windows operating system, data written to this stream must be in XPS format as a package stream.
SugestãoSuggestion Para mostrar o conteúdo impresso, você tem duas opções:To output print content, you can do either of the following:
  • Use a classe XpsDocumentWriter para produzir conteúdo de impressão.Use the XpsDocumentWriter class to output print content. Essa é a alternativa recomendada.This is the recommended alternative.
  • Garanta que os dados enviados ao fluxo retornado pela propriedade JobStream estão no formato XPS como um fluxo de pacote.Ensure that the data sent to the stream returned by the JobStream property is in XPS format as a package stream.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

SerializaçãoSerialization

BinaryFormatter pode não conseguir localizar o tipo do contexto LoadFromBinaryFormatter can fail to find type from LoadFrom context

DetalhesDetails A partir do .NET Framework 4.5, várias alterações de XmlSerializer podem causar diferenças na desserialização ao usar BinaryFormatter para desserializar tipos que foram carregados no contexto LoadFrom.As of .NET Framework 4.5, a number of XmlSerializer changes may cause differences in deserialization when using BinaryFormatter to deserialize types that had been loaded in the LoadFrom context. Essas alterações se devem a novas maneiras como XmlSerializer agora carrega um tipo, o que causa um comportamento diferente quando um BinaryFormatter tenta desserializar esse tipo posteriormente.These changes are due to the new ways XmlSerializer now loads a type which causes different behavior when a BinaryFormatter attempts to deserialize to that type later on. 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.The default serialization binder does not automatically search the LoadFrom context, although it may have worked in some circumstances based on the old behavior of XmlSerializer. Devido às alterações, quando um tipo está sendo carregado de um assembly carregado em um contexto diferente, um FileNotFoundException pode ser acionado.Due to the changes, when a type is being loaded from an assembly loaded in a different context, a FileNotFoundException may be thrown.
SugestãoSuggestion Se essa exceção for observada, a propriedade Binder do BinaryFormatter poderá ser definida como um associador personalizado que encontrará o tipo correto.If this exception is seen, the Binder property of the BinaryFormatter can be set to a custom binder that will find the correct type.
var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }
E, em seguida, o associador personalizado:And then the custom binder:
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));
}
}
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

NetDataContractSerializer falha ao desserializar um ConcurrentDictionary serializado com uma versão diferente do .NETNetDataContractSerializer fails to deserialize a ConcurrentDictionary serialized with a different .NET version

DetalhesDetails Por design, o NetDataContractSerializer poderá ser usado somente se as extremidades de serialização e desserialização compartilharem os mesmos tipos CLR.By design, the NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types. Portanto, não há garantia de que um objeto serializado com uma versão do .NET Framework poderá ser desserializado com uma versão diferente.ConcurrentDictionary<TKey,TValue>Therefore, it is not guaranteed that an object serialized with one version of the .NET Framework can be deserialized by a different version.ConcurrentDictionary<TKey,TValue> é um tipo que não será desserializado corretamente se for serializado com o .NET Framework 4.5 ou anterior e for desserializado com o .NET Framework 4.5.1 ou posterior.is a type that is known to not to deserialize correctly if serialized with the .NET Framework 4.5 or earlier and deserialized with the .NET Framework 4.5.1 or later.
SugestãoSuggestion Há uma série de possíveis soluções alternativas para esse problema:There are a number of possible work-arounds for this issue:
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

SoapFormatter não pode desserializar Hashtable e objetos de coleção ordenados semelhantesSoapFormatter cannot deserialize Hashtable and similar ordered collection objects

DetalhesDetails O SoapFormatter não garante que objetos serializados em uma versão do .NET Framework serão desserializados com êxito em uma versão diferente.The SoapFormatter does not guarantee that objects serialized under one .NET Framework version will successfully deserialize under a different version. Especificamente, algumas coleções ordenadas (como 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.Specifically, some ordered collections (like Hashtable) added members between 4.0 and 4.5 such that objects of these types cannot deserialize with .NET Framework 4.0 if they were serialized with .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á.Note that if the serialized data is both serialized and deserialized with the same .NET Framework version, no issue will occur.
SugestãoSuggestion A serialização SoapFormatter deve ser substituída pela serialização BinaryFormatter ou NetDataContractSerializer para resistir às alterações do .NET Framework.SoapFormatter serialization should be replaced with BinaryFormatter serialization or NetDataContractSerializer to be resilient to .NET Framework changes.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

XmlSerializer falha durante a serialização de um tipo que oculta um membro acessível com um inacessívelXmlSerializer fails while serializing a type that hides an accessible member with an inaccessible one

DetalhesDetails Ao serializar um tipo derivado, o 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.When serializing a derived type, the XmlSerializer can fail if the type contains an inaccessible field or property that hides (via the 'new' keyword) a field or property of the same name that was previously accessible (public, for example) on the base type.
SugestãoSuggestion Esse problema pode ser resolvido tornando o novo membro oculto acessível para o XmlSerializer (marcando-o como público, por exemplo). Como alternativa, a seguinte configuração será revertida para o comportamento XmlSerializer no 4.0, o que corrigirá o problema:This problem can be solved by making the new, hiding member accessible to the XmlSerializer (by marking it public, for example).Alternatively, the following config setting will revert to 4.0 XmlSerializer behavior, which will fix the problem:
<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Aplicativos WebWeb Applications

Controles de host do navegador gerenciado do .NET Framework 1.1 e 2.0 estão bloqueadosManaged browser hosting controls from the .NET Framework 1.1 and 2.0 are blocked

DetalhesDetails Hospedar esses controles é bloqueado no Internet Explorer.Hosting these controls is blocked in Internet Explorer.
SugestãoSuggestion O Internet Explorer falhará ao iniciar um aplicativo que usa o navegador gerenciado que hospeda controles.Internet Explorer will fail to launch an application that uses managed browser hosting controls. 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.The previous behavior can be restored by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/MICROSOFT/.NETFramework to 1 for x86 systems and for 32-bit processes on x64 systems, and by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework to 1 for 64-bit processes on x64 systems.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

Códigos de erro de maxRequestLength ou maxReceivedMessageSize são diferentesError codes for maxRequestLength or maxReceivedMessageSize are different

DetalhesDetails 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 ProtocolException.Messages in WCF web services hosted in Internet Information Services (IIS) or ASP.NET Development Server that exceed maxRequestLength (in ASP.NET) or maxReceivedMessageSize (in WCF) have different error codeThe HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large), and messages that exceed either the maxRequestLength or the maxReceivedMessageSize setting throw a ProtocolException exception. Isso inclui os casos em que o modo de transferência é Streamed.This includes cases in which the transfer mode is Streamed.
SugestãoSuggestion 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.This change facilitates debugging in cases where the message length exceeds the limits allowed by ASP.NET or WCF.You must modify any code that performs processing based on an HTTP 400 status code.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

MinFreeMemoryPercentageToActiveService agora é respeitadoMinFreeMemoryPercentageToActiveService is now respected

DetalhesDetails 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.This setting establishes the minimum memory that must be available on the server before a WCF service can be activated. Ela foi projetada para evitar exceções OutOfMemoryException.It is designed to prevent OutOfMemoryException exceptions. No .NET Framework 4.5, essa configuração não tinha nenhum efeito.In the .NET Framework 4.5, this setting had no effect. No .NET Framework 4.5.1, essa configuração é observada.In the .NET Framework 4.5.1, the setting is observed.
SugestãoSuggestion 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.An exception occurs if the free memory available on the web server is less than the percentage defined by the configuration setting. Alguns serviços WCF iniciados com êxito e executados em um ambiente de memória restrito agora podem falhar.Some WCF services that successfully started and ran in a constrained memory environment may now fail.
EscopoScope SecundárioMinor
VersãoVersion 4.5.14.5.1
TipoType Tempo de execuçãoRuntime

O objeto System.ServiceModel.Web.WebServiceHost não adiciona mais um ponto de extremidade padrãoSystem.ServiceModel.Web.WebServiceHost object no longer adds a default endpoint

DetalhesDetails 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.The WebServiceHost object no longer adds a default endpoint if an explicit endpoint has been added by application code.
SugestãoSuggestion 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 WebServiceHost, os pontos de extremidade padrão também deverão ser explicitamente adicionados (usando AddDefaultEndpoints()).If users will expect to be able to connect to a default endpoint and other explicit endpoints have been added to the WebServiceHost, default endpoints should also be added explicitly (using AddDefaultEndpoints()).
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

O método Replace nas URLs do OData é desabilitado por padrãoThe Replace method in OData URLs is disabled by default

DetalhesDetails A partir do .NET Framework 4.5, o método Replace em URLs do OData é desabilitado por padrão.Beginning in the .NET Framework 4.5, the Replace method in OData URLs is disabled by default. 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.When OData Replace is disabled (now by default), any user requests including replace functions (which are uncommon) will fail.
SugestãoSuggestion Se o método de substituição for necessário (o que é incomum), ele poderá ser reabilitado por meio das configurações (ReplaceFunction).If the replace method is required (which is uncommon), it can be re-enabled through a config settings (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.However, an enabled replace method can open security vulnerabilities and should only be used after careful review.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Windows FormsWindows Forms

PreviewLostKeyboardFocus será chamado repetidamente se seu manipulador mostrar uma caixa de mensagem do Windows FormsPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

DetalhesDetails 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.Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.
SugestãoSuggestion Há duas opções para contornar esse problema:There are two options to work around this issue:
  1. Ele pode ser evitado chamando MessageBox.Show em vez de MessageBox.Show.It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. Ele pode ser evitado mostrando a caixa de mensagem de um manipulador de eventos UIElement.LostKeyboardFocus (em oposição a um manipulador de eventos PreviewLostKeyboardFocus).It may be avoided by showing the message box from a UIElement.LostKeyboardFocus event handler (as opposed to a PreviewLostKeyboardFocus event handler).
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

A propriedade CheckForOverflowUnderflow do WinForm agora é true para System.DrawingWinForm's CheckForOverflowUnderflow property is now true for System.Drawing

DetalhesDetails A propriedade CheckForOverflowUnderflow do o assembly System.Drawing.dll está definida como true.The CheckForOverflowUnderflow property for the System.Drawing.dll assembly is set to true.
SugestãoSuggestion Anteriormente, quando os estouros ocorriam, o resultado teria sido truncado silenciosamente.Previously when overflows occurred, the result would be silently truncated. Agora, uma exceção OverflowException é gerada.Now an OverflowException exception is thrown.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

Acessar os itens selecionados de um DataGrid do WPF em um manipulador do evento UnloadingRow do DataGrid pode gerar NullReferenceExceptionAccessing a WPF DataGrid's selected items from a handler of the DataGrid's UnloadingRow event can cause a NullReferenceException

DetalhesDetails 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 NullReferenceException se acessarem as propriedades SelectedItem ou SelectedItems de DataGrid.Due to a bug in the .NET Framework 4.5, event handlers for DataGrid events involving the removal of a row can cause a NullReferenceException to be thrown if they access the DataGrid's SelectedItem or SelectedItems properties.
SugestãoSuggestion Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Chamar DataGrid.CommitEdit de um manipulador CellEditEnding descarta o focoCalling DataGrid.CommitEdit from a CellEditEnding handler drops focus

DetalhesDetails Chamar CommitEdit() de um dos manipuladores de eventos DataGrid do CellEditEnding faz com que DataGrid perca o foco.Calling CommitEdit() from one of the DataGrid's CellEditEnding event handlers causes the DataGrid to lose focus.
SugestãoSuggestion Esse bug foi corrigido no .NET Framework 4.5.2, portanto, ele pode ser evitado com a atualização do .NET Framework.This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. Como alternativa, ele pode ser evitado com a nova seleção explícita de DataGrid após chamada de CommitEdit().Alternatively, it can be avoided by explicitly re-selecting the DataGrid after calling CommitEdit().
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Chamar Items.Refresh em uma ListBox, ListView ou DataGrid do WPF com itens selecionados pode exibir itens duplicados no elementoCalling Items.Refresh on a WPF ListBox, ListView, or DataGrid with items selected can cause duplicate items to appear in the element

DetalhesDetails No .NET Framework 4.5, chamar ListBox.Items.Refresh do código enquanto itens estiverem selecionados em uma ListBox pode fazer com que os itens selecionados sejam duplicados na lista.In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a ListBox can cause the selected items to be duplicated in the list. Ocorre um problema semelhante com ListView e DataGrid.A similar issue occurs with ListView and DataGrid. Isso foi corrigido no .NET Framework 4.6.This is fixed in the .NET Framework 4.6.
SugestãoSuggestion Esse problema pode ser contornado de forma programática cancelando a seleção dos itens antes de chamar Refresh() e selecionando-os novamente após a conclusão da chamada.This issue may be worked around by programatically unselecting items before Refresh() is called and then re-selecting them after the call is completed. 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.Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

FlowDocument pode mostrar uma linha extra de textoFlowDocument may show an extra line of text

DetalhesDetails 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.In some cases, a FlowDocument element will display an extra line of text when running on the .NET Framework 4.5 compared to how it displayed when run on the .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.There are no known cases of the change causing any text to be displayed poorly or illegibly, but it could cause text to appear that previously was omitted from a FlowDocument's view.
SugestãoSuggestion Em alguns casos, diminuir a propriedade PageHeight do elemento de exibição em 1 pode restaurar o número anterior de linhas exibidas.In some cases, decreasing the display element's PageHeight property by one can restore the previous number of displayed lines.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

GlyphRun.ComputeInkBoundingBox() e FormattedText.Extent retornam valores diferentes começando no .NET Framework 4.5GlyphRun.ComputeInkBoundingBox() and FormattedText.Extent return different values beginning in .NET Framework 4.5

DetalhesDetails 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.Improvements were made to ComputeInkBoundingBox() and Extent in the .NET Framework 4.5 to address issues where the boxes were too small for the contained glyphs in some cases in the .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.As a result of this, some bounding boxes will be larger beginning in the .NET Framework 4.5, resulting in subtle differences in UI layout.
SugestãoSuggestion Lembre-se de que alguns tamanhos de caixa delimitadora do glifo aumentaram.Be aware that some glyph bounding box sizes have increased. 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:These changes will usually improve presentation and hit box testing, but if the older (pre-.NET 4.5) behavior is desired, it can be opted into by adding the following entry to the app.config file:
<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Não é possível rolar intermitentemente para o item na parte inferior em ItemsControls (como ListBox e DataGrid) ao usar DataTemplates personalizadosIntermittently unable to scroll to bottom item in ItemsControls (like ListBox and DataGrid) when using custom DataTemplates

DetalhesDetails Em alguns casos, um bug no .NET Framework 4.5 está fazendo com que ItemsControls (como ListBox, ComboBox, DataGrid etc.) não rolem para o item na parte inferior ao usar DataTemplates personalizados.In some instances, a bug in the .NET Framework 4.5 is causing ItemsControls (like ListBox, ComboBox, DataGrid, etc.) to not scroll to their bottom item when using custom DataTemplates. Se houver uma tentativa de rolagem pela segunda vez (depois da rolagem de volta), ela funcionará.If the scrolling is attempted a second time (after scrolling back up), it will work then.
SugestãoSuggestion 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.This issue has been fixed in the .NET Framework 4.5.2 and may be addressed by upgrading to that version (or a later version) of the .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.Alternatively, users can still drag scroll bars to the final items in these collections, but may need to try twice to do so successfully.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Items.Clear não remove duplicatas de SelectedItemsItems.Clear does not remove duplicates from SelectedItems

DetalhesDetails Suponha que um Seletor (com seleção múltipla habilitada) tenha duplicatas em sua coleção SelectedItems – o mesmo item é exibido mais de uma vez.Suppose a Selector (with multiple selection enabled) has duplicates in its SelectedItems collection - the same item appears more than once. A remoção desses itens da fonte de dados (por exemplo, chamando Items.Clear) falha ao removê-los de SelectedItems; somente a primeira instância é removida.Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from SelectedItems; only the first instance is removed. Além disso, o uso subsequente de SelectedItems (por exemplo, SelectedItems.Clear()) pode encontrar problemas, como ArgumentException, pois SelectedItems contém itens que não estão mais na fonte de dados.Furthermore, subsequent use of SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as ArgumentException, because SelectedItems contains items that are no longer in the data source.
SugestãoSuggestion Atualize se possível para o .NET Framework 4.6.2.Upgrade if possible to .NET Framework 4.6.2.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Problema de associação de ListBoxItem IsSelected com ObservableCollection<T>.MoveListBoxItem IsSelected binding issue with ObservableCollection<T>.Move

DetalhesDetails Chamar Move(Int32, Int32) ou MoveItem(Int32, Int32) em uma coleção associada a um ListBox com itens selecionados pode gerar comportamento imprevisível em seleções ou cancelamentos de seleção futuros de itens ListBox.Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a ListBox with items selected can lead to erratic behavior with future selection or unselection of ListBox items.
SugestãoSuggestion Chamar Remove(T) e Insert(Int32, T) em vez de Move(Int32, Int32) é uma solução alternativa para esse problema.Calling Remove(T) and Insert(Int32, T) instead of Move(Int32, Int32) will work around this issue. 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.Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Novos valores de enumeração em PageRangeSelection do WPFNew enum values in WPF's PageRangeSelection

DetalhesDetails Os dois novos membros (CurrentPage e SelectedPages) foram adicionados à enumeração PageRangeSelection.Two new members (CurrentPage and SelectedPages) have been added to the PageRangeSelection enum.
SugestãoSuggestion Na maioria das vezes, essas mudanças não afetarão o código do usuário.In most cases, these changes won't impact user code. O código que depende de um número específico de elementos existentes nas chamadas GetNames(Type) ou GetValues(Type) no tipo PageRangeSelection deve ser modificado.Code that depends on a particular number of elements existing in GetNames(Type) or GetValues(Type) calls on the PageRangeSelection type should be modified, though.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

PreviewLostKeyboardFocus será chamado repetidamente se seu manipulador mostrar uma caixa de mensagem do Windows FormsPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

DetalhesDetails 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.Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.
SugestãoSuggestion Há duas opções para contornar esse problema:There are two options to work around this issue:
  1. Ele pode ser evitado chamando MessageBox.Show em vez de MessageBox.Show.It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. Ele pode ser evitado mostrando a caixa de mensagem de um manipulador de eventos UIElement.LostKeyboardFocus (em oposição a um manipulador de eventos PreviewLostKeyboardFocus).It may be avoided by showing the message box from a UIElement.LostKeyboardFocus event handler (as opposed to a PreviewLostKeyboardFocus event handler).
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Clicar com o botão direito do mouse em um cabeçalho de linha do DataGrid do WPF altera a seleção de DataGridRight clicking on a WPF DataGrid row header changes the DataGrid selection

DetalhesDetails Clicar com o botão direito do mouse em um cabeçalho de linha DataGrid enquanto várias linhas estão selecionadas altera a seleção de DataGrid para somente a linha em questão.Right-clicking a selected DataGrid row header while multiple rows are selected results in the DataGrid's selection changing to only that row.
SugestãoSuggestion Esse problema foi corrigido no .NET Framework 4.6 e pode ser resolvido com o upgrade para essa versão do .NET Framework.This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Elementos DataTemplate do WPF agora são visíveis à UIAWPF DataTemplate elements are now visible to UIA

DetalhesDetails Anteriormente, os elementos DataTemplate eram invisíveis à Automação da Interface do Usuário.Previously, DataTemplate elements were invisible to UI Automation. A partir da versão 4.5, a Automação da Interface do Usuário detectar esses elementos.Beginning in 4.5, UI Automation will detect these elements. Isso é útil em muitos casos, mas pode arruinar os testes que dependem das árvores UIA que não contêm elementos DataTemplate.This is useful in many cases, but can break tests that depend on UIA trees not containing DataTemplate elements.
SugestãoSuggestion 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 DataTemplate anteriormente invisíveis.UI Automation tests for this app may need updated to account for the UIA tree now including previously invisible DataTemplate elements. 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.For example, tests that expect some elements to be next to each other may now need to expect previously invisible UIA elements in between. Ou os testes que dependem de determinadas contagens ou de índices para elementos UIA talvez precisem ser atualizados com novos valores.Or tests that rely on certain counts or indexes for UIA elements may need updated with new values.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

DispatcherSynchronizationContext.CreateCopy do WPF agora retorna uma nova cópia em vez da instância atualWPF DispatcherSynchronizationContext.CreateCopy now returns a new copy instead of the current instance

DetalhesDetails No .NET Framework 4, CreateCopy() retornava uma referência à instância atual, basicamente como uma otimização de desempenho.In the .NET Framework 4, CreateCopy() returned a reference to the current instance, primarily as a performance optimization. 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.In the .NET Framework 4.5, it returns a new instance which makes it possible for the first time to conclude that equal references indicate the executing thread is in the correct synchronization context. É 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.It is unlikely that code that checks the identity of these references will be affected, but because of the change, code that calls CreateCopy() should be tested as part of migration to the .NET Framework 4.5 or newer.
SugestãoSuggestion Lembre-se de que CreateCopy() agora retornará um novo objeto SynchronizationContext.Be aware that CreateCopy() will now return a new SynchronizationContext object. 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.Previously, code that used equivalence of references generated this way was not actually checking whether it was in the proper context, but does when built against .NET Framework 4.5 or later. 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.While unlikely to cause issues, exercising the affected code paths should be enough to determine if this poses any problem.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

O padrão da Caixa de Texto do WPF é o limite de 100 na ação desfazerWPF TextBox defaults to undo limit of 100

DetalhesDetails 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)In .NET Framework 4.5, the default undo limit for a WPF textbox is 100 (as opposed to being unlimited in .NET Framework 4.0)
SugestãoSuggestion Se um limite de 100 da ação desfazer for muito baixo, o limite poderá ser definido explicitamente com UndoLimit.If an undo limit of 100 is too low, the limit can be set explicitly with UndoLimit
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

O texto selecionado TextBox do WPF aparece em cor diferente quando a caixa de texto está inativaWPF TextBox selected text appears a different color when the text box is inactive

DetalhesDetails 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.In .NET Framework 4.5, when a WPF text box control is inactive (it doesn't have focus), the selected text inside the box will appear a different color than when the control is active.
SugestãoSuggestion O comportamento anterior (.NET Framework 4.0) poderá ser restaurado definindo a propriedade AreInactiveSelectionHighlightBrushKeysSupported como false.The previous (.NET Framework 4.0) behavior may be restored by setting the AreInactiveSelectionHighlightBrushKeysSupported property to false.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

TreeViewItem do WPF deve ser usado em um TreeViewWPF TreeViewItem must be used within a TreeView

DetalhesDetails Foi introduzida na versão 4.5 uma alteração que restringe o uso de elementos TreeViewItem fora de um TreeView.A change was introduced in 4.5 that restricts usage of TreeViewItem elements outside of a TreeView. Isso se manifesta sob as seguintes condições:This manifests under the following conditions:
  • O pai visual de TreeViewItem não é um painel.TreeViewItem's visual parent is not a panel. (Um TreeViewItem gerado para um TreeView terá um painel como pai)(A TreeViewItem generated for a TreeView will have a panel as its parent)
  • O TreeViewItem é descendente de um VirtualizingStackPanel que atua como o "host de itens" de um controle de lista (ListBox, DataGrid, ListView etc.).The TreeViewItem is a descendant of a VirtualizingStackPanel acting as the "items host" for a list control (ListBox, DataGrid, ListView, etc.). A virtualização não precisa ser habilitada.Virtualization doesn't need to be enabled.
  • O VirtualizingStackPanel é a rolagem de itens (ScrollUnit="Item").The VirtualizingStackPanel is item-scrolling (ScrollUnit="Item").
  • Alguém chama VirtualizingStackPanel.MakeVisible(v) para rolar um elemento v no modo de exibição.Someone calls VirtualizingStackPanel.MakeVisible(v) to scroll an element v into view. 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.This can be done explicitly, or implicitly in a number of ways; perhaps the most common way is simply clicking on v to give it the keyboard focus.
  • A cadeia de pais visuais de v para o VirtualizingStackPanel passa pelo TreeViewItem.The visual-parent chain from v to the VirtualizingStackPanel passes through the TreeViewItem.
Em outras palavras, isso é visto quando um TreeViewItem é usado fora de um TreeView e o usuário clica em um descendente do TreeViewItem para colocá-lo no modo de exibição.In other words, this is seen when a TreeViewItem is used outside of a TreeView, and the user clicks on a descendant of the TreeViewItem to bring it into view. Se o TreeViewItem não tiver descendentes focalizáveis, você nunca verá esse problema.If the TreeViewItem has no focusable descendants, you'll never see this issue. Um exemplo de situação em que isso acontece é quando um TreeViewItem é a raiz de um DataTemplate.An example of a situation where this is hit is when a TreeViewItem is the root of a DataTemplate. Quando esse problema for atingido, haverá uma InvalidCastException que ocorrerá dentro da estrutura do WPF.When this issue is hit, there is an InvalidCastException that occurs within the WPF framework.
SugestãoSuggestion Um hotfix será disponibilizado para isso.A hotfix will be made available for this.
EscopoScope SecundárioMinor
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

System.Activities agora é APTCASystem.Activities is now APTCA

DetalhesDetails O assembly é marcado com o atributo AllowPartiallyTrustedCallersAttribute.The assembly is marked with the AllowPartiallyTrustedCallersAttribute attribute.
SugestãoSuggestion Classes derivadas não podem ser marcadas com SecurityCriticalAttribute.Derived classes cannot be marked with the SecurityCriticalAttribute. Anteriormente, os tipos derivados precisavam ser marcados com o SecurityCriticalAttribute.Previously, derived types had to be marked with the SecurityCriticalAttribute. No entanto, essa mudança não deve ter um impacto real.However, this change should have no real impact.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

O WF agora serializa Expressions.Literal<T>DateTimes de modo diferente (interrompe analisadores XAML personalizados)WF serializes Expressions.Literal<T> DateTimes differently now (breaks custom XAML parsers)

DetalhesDetails O objeto ValueSerializer associado converterá um objeto DateTime ou DateTimeOffset cujos componentes Second e Millisecond são diferentes de zero e (para um valor de DateTime) cuja propriedade Kind não é Unspecified para a sintaxe de elemento de propriedade em vez de uma cadeia de caracteres.The associated ValueSerializer object will convert a DateTime or DateTimeOffset object whose Second and Millisecond components are non-zero and (for a DateTime value) whose Kind property is not Unspecified to property element syntax instead of a string. Essa alteração permite que os valores DateTime e DateTimeOffset completem um ciclo.This change allows DateTime and DateTimeOffset values to be round-tripped. Os analisadores XAML personalizados que assumem que a entrada XAML está na sintaxe de atributo não funcionará corretamente.Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.
SugestãoSuggestion Essa alteração permite que os valores DateTime e DateTimeOffset completem um ciclo.This change allows DateTime and DateTimeOffset values to be round-tripped. Os analisadores XAML personalizados que assumem que a entrada XAML está na sintaxe de atributo não funcionará corretamente.Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime

XML, XSLTXML, XSLT

XmlSchemaException agora define posições de linhas corretamenteXmlSchemaException now sets line positions properly

DetalhesDetails 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.If the SetLineInfo value is passed to the Load method and a validation error occurs, the LineNumber and LinePosition properties now contain line information.
SugestãoSuggestion 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.Exception-handling code that assumes LineNumber and LinePosition will not be set should be updated since these properties will now be set properly when SetLineInfo is used while loading XML.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Expansão da entidade DTD de XmlTextReader é limitada a 10.000.000 caracteresXmlTextReader DTD entity expansion is limited to 10,000,000 characters

DetalhesDetails A expansão da entidade DTD agora é limitada a 10.000.000 de caracteres.DTD entity expansion is now limited to 10,000,000 characters. O carregamento de arquivos XML sem expansão de entidade DTD ou com expansão de entidade DTD limitada não é afetado.Loading XML files without DTD entity expansion or with limited DTD entity expansion is unaffected. Arquivos com entidades DTD que se expandem para mais de 10.000.000 caracteres falham ao carregar e geram uma exceção.Files with DTD entities that expand to more than 10,000,000 characters fail to load, and now throw an exception.
SugestãoSuggestion 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.If the limit of DTD entity expansion is too low 10,000,000, the value can be overridden with the MaxCharactersFromEntities property. Um XmlReaderSettings com o valor MaxCharactersFromEntities correto pode ser passado para o XmlReader.Create que usa XmlReaderSettings (por exemplo, Create(String, XmlReaderSettings)).An XmlReaderSettings with the proper MaxCharactersFromEntities value can be passed to XmlReader.Create that takes XmlReaderSettings (ie. Create(String, XmlReaderSettings))
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Compatibilidade com versões posteriores do XSLT agora funcionaXSLT forward compat now works

DetalhesDetails No .NET Framework 4, a compatibilidade com versões posteriores do XSLT 1.0 tinha os seguintes problemas:In the .NET Framework 4, XSLT 1.0 forward compatibility had the following issues:
  • 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.Loading a style sheet failed if its version was set to 2.0 and the parser encountered an unrecognized XSLT 1.0 construct.
  • A construçãoxsl:sort falhava ao classificar os dados se a versão de folha de estilo era definida como 1.1.The xsl:sort construct failed to sort data if the style sheet version was set to 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.In the .NET Framework 4.5, these issues have been fixed, and XSLT 1.0 forward compatibility mode works properly.
SugestãoSuggestion A maioria dos aplicativos não deve ser afetada, mas os dados serão classificados diferentemente em alguns casos agora que xsl:sort é respeitado.Most apps should be unaffected, however data will be sorted differently in some cases now that xsl:sort is respected. Se xsl:sort for usado em folhas de estilo 1.1, verifique se os aplicativos dependem da ordem sem classificação dos dados.If xsl:sort is used in 1.1 style sheets, confirm that apps were not depending on the unsorted order of data. Se os aplicativos dependerem do comportamento de classificação de 4.0, remova xsl:sort da folha de estilos.If apps rely on the 4.0 sorting behavior, remove xsl:sort from the style sheet.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs

Mensagem de exceção da folha de estilos XSLT alteradaXSLT style sheet exception message changed

DetalhesDetails No .NET Framework 4.5, o texto da mensagem de erro quando um arquivo XSLT é muito complexo é "A folha de estilos é muito complexa". Nas versões anteriores, a mensagem de erro era "Erro de compilação de XSLT". O código do aplicativo que depende do texto da mensagem de erro não funcionará.In the .NET Framework 4.5, the text of the error message when an XSLT file is too complex is "The style sheet is too complex." In previous versions, the error message was "XSLT compile error." Application code that depends on the text of the error message will no longer work. No entanto, os tipos de exceção permanecem os mesmos, de modo que essa modificação não deve ter um impacto real.However, the exception types remain the same, so this change should have no real impact.
SugestãoSuggestion 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 (XsltException), que não foi alterado.Update any app code depending on the exception message from this error condition to expect the new message, or (even better) update the code to depend only on the exception type (XsltException), which has not changed.
EscopoScope Microsoft EdgeEdge
VersãoVersion 4.54.5
TipoType Tempo de execuçãoRuntime
APIs afetadasAffected APIs