Rollup hotfix 3139550 para o .NET Framework 4.6.1 e 4.6 no Windows

Problema 1

Quando uma aplicação WPF utiliza um TreeViewItem fora do contexto de uma TreeView, a aplicação pode encontrar uma exceção InvalidCastException cujo rastreio de pilhas é iniciado da seguinte forma:

Sistema. Windows. Controlos.VirtualizingStackPanel.FindScrollOffset(Visual v)
Nota Esta exceção ocorre quando o TreeViewItem está num controlo de lista virtualizado (por exemplo, um controlo ListBox, DataGrid ou ListView) que tenta encontrar o deslocamento do TreeViewItem ou um dos seus descendentes. Por exemplo, esta exceção ocorre se declarar uma TreeViewItem como a raiz de um DataTemplate e o DataTemplate for utilizado como o DataTemplate de uma coluna DataGrid.


 

Problema 2

Ambos os sistemas.web. Colocação em Cache e System.Runtime. Colocação em Cache comunicar o tamanho da memória utilizada pelo AppDomain inteiro em vez da memória utilizada pelos itens da cache.

Esta é uma regressão da .NET Framework 4.5 devido a uma alteração na implementação do Temporização. Para além de comunicar o tamanho errado, os objetos adicionais referenciados pela cache podem afetar significativamente a latência GC da geração2. Em cenários de alojado, ASP.NET cache também calculou indevidamente o tamanho de todas as caches em todos os domínios da aplicação (conforme comunicado através de um "Limite de Memória de Processo de Cache % Utilizado" ASP.NET contador de desempenho) quando os domínios da aplicação eram reciclagem.

Esta correção remove referências indesejadas da cache para os outros objetos de domínio da aplicação para que seja comunicado o tamanho correto. Esta correção também inclui alterações para melhorar a latência para System.Runtime. Colocação em Cache em computadores multi-core que estão a utilizar o Server GC. Além disso, após a aplicação desta correção, o tamanho de todas as caches em cenários de reciclagem de domínios de aplicações é calculado corretamente.


 

Problema 3

Quando tem uma aplicação Windows Presentation Foundation (WPF) que depende da promoção por rato das movimentações táteis para lidar com a interação por parte do utilizador tágico (em vez de utilizar diretamente eventos de toque), pode detetá-lo num volume invulgarmente baixo de movimentações de rato promovidas.

Anteriormente, a promoção do rato com uma velocidade de WPF para movimentações táteis estava a ser sobrecarregada com um grande volume de movimentações de toque. No .NET Framework 4.6.1, foi introduzida uma correção para corrigir o número de movimentações táteis que são processadas. Após esta alteração, a redução das promoções por rato causava uma redução adicional no número de movimentações de rato geradas. A eliminação de promoções por rato é removida, pelo que devem ser apresentados quase um-para-um entre eventos de movimentação de toques e eventos promovidos de movimentação de ratos.


 

Problema 4

Suponha que está a trabalhar numa aplicação WPF que tem como alvo a .NET Framework 4.6. Experimente definir o valor CurrentThread.CurrentCulture ou CurrentThread.CurrentUICulture em qualquer método que seja invocado pelo Envio WPF através de uma EmperaçãoDePaís. Por exemplo, está a tentar definir este valor num alçador de eventos da IU ou no construtor da MainWindow. Nesta situação, os valores CurrentCulture e CurrentUIICulture são repostos para os respetivos valores anteriores no final do método. Se uma aplicação definir CurrentUICulture no construtor MainWindow ou num alçador de clique de botão, essa definição reverte para a cultura da IU do sistema.

Esta correção garante que os valores de CurrentThread.CurrentCulture/CurrentUICulture definidos em métodos numa aplicação WPF persistem da mesma forma que antes do .NET Framework 4.6.


 

Problema 5

No .NET Framework 4.6, é adicionado um novo sinalizador, TaskContinuationOptions.RunContinuationsAsynchronously, à biblioteca de Tarefas. No entanto, quando utiliza este sinalizador em conjunto com a Tarefa.QuandoTol, Tarefa.QuandoAny ou Tarefa.Anuidade, o sinalizador não tem efeito. O sinalizador foi introduzido para evitar determinadas condições de bloqueio. Esta correção garante que todos os tipos de continuações de Tarefas respeitam o novo sinalizador.


 

Problema 6

No .NET Framework 4.6, existe um erro na AppContext que faz com que a segurança do tópico dos métodos AppContext seja implementada incorretamente. O AppContext faz parte da infraestrutura para reduzir a quebra de alterações. Pode utilizar o AppContext para definir e obter sinalizadores e para tomar decisões na sua aplicação com base nesses dados.

Esta correção ativa a segurança de tópicos correta para os métodos no AppContext relacionados com a definição e recuperação de valores de parâmetro.


 

Problema 7

Quando encontrar um caso limite que tenha o seu padrão de alocação e de capacidade e necessita de um novo segmento no seu item gerido, um recolhidor de lixo pode calcular um tamanho de entrega mais pequeno do que o esperado. Isto causa uma violação de acesso durante a fase compacta porque o recoltor do lixo está a tentar escrever para memória não commitida.

Esta correção calcula o tamanho corretamente.


 

Problema 8

Quando cria código nativo para determinados métodos, a .NET Framework de dados e os processos NGEN poderão desativar uma falha inesperada.

Problema 9

O RyuJit gera instruções incorretas para comparar números inteiros não assinados de 16 bits em registos. Produz um resultado incorreto se os valores de entrada apresentarem valores MSB diferentes e se comparar instruções geradas, utilizar o registo de operandos.

Esta correção gera instruções corretas.
 

Aplica-se a

Este artigo aplica-se ao seguinte:
 

• Microsoft .NET Framework 4.6.1

• Microsoft .NET Framework 4.6, quando utilizado com:
   

  • Windows 8.1

  • Windows RT 8.1

  • Windows Server 2012 de Dados R2

  • Windows Server 2012 R2 Essentials

  • Windows Server 2012 R2 para Sistemas Incorporados

  • Windows Server 2012 R2 Foundation

  • Windows Server 2012 R2 Padrão