Сборен пакет 3139550 корекция за .NET Framework (платформа) 4.6.1 и 4.6 на Windows

Проблем 1

Когато WPF приложение използва TreeViewItem извън контекста на TreeView, приложението може да срещне изключение InvalidCastException, чието проследяване на стека започва по следния начин:

Система. Windows. Контроли.ВиртуализиранеStackPanel.FindScrollOffset(Visual v)
Забележка Това изключение възниква, когато TreeViewItem е във виртуализирана контрола на списък (например listBox, DataGrid или ListView контрола), която се опитва да намери изместването на превъртането на TreeViewItem или един от неговите потомци. Например това изключение възниква, ако декларирате TreeViewItem като корен на DataTemplate и DataTemplate се използва като cellTemplate на колона dataGrid.


 

Проблем 2

Както System.web.Caching, така и System.Runtime.Caching съобщават размера на паметта, която се използва от целия AppDomain, а не паметта, използвана от елементите в кеша.

Това е регресия от .NET Framework (платформа) 4,5 поради промяна в внедряването на таймера. В допълнение към съобщаването за неправилен размер, допълнителните обекти, към които има препратка от кеша, могат значително да повлияят на забавянето на g2 GC. В ASP.NET хостинг сценарии кешът също така е изчислил неправилно размера на всички кешове във всички домейни на приложения (както е съобщено чрез "Кеш % използван лимит на паметта за процес" ASP.NET брояч на производителността), когато домейните на приложенията са били рециклирани.

Тази корекция премахва нежелани препратки от кеша към другите обекти на домейн на приложение, така че да се съобщи правилният размер. Тази корекция включва и промени за подобряване на закъснението за System.Runtime.Caching на многоядрени компютри, които използват GC за сървър. Освен това след прилагане на тази корекция размерът на всички кешове в сценариите за рециклиране на домейни на приложения се изчислява правилно.


 

Проблем 3

Когато имате приложение за Windows среда за представяния (WPF), което разчита на насърчаването на сензорни движения на мишката, за да се справите с взаимодействието на сензорния потребител (вместо чрез директно използване на сензорни събития), може да изпитате необичайно нисък обем на повишени движения на мишката.

По-рано WPF ускори промоцията на мишката на сензорни движения, за да избегнете голям обем сензорни движения, затрупани диспечера. В .NET Framework (платформа) 4.6.1 е въведена корекция за ограничаване на броя на движенията с докосване, които се обработват. След тази промяна ограничаването на промоциите на мишката предизвика допълнително намаляване на броя на движенията на мишката, които са генерирани. Ограничаването на промоциите на мишката сега се премахва, така че да има почти кореспонденция "един към един" между събитията за преместване на докосване и повишените събития за преместване на мишката.


 

Проблем 4

Да предположим, че работите върху WPF приложение, което е насочена към .NET Framework (платформа) 4.6. Опитвате се да зададете стойността CurrentThread.CurrentCulture или CurrentThread.CurrentUICulture във всеки метод, който се извиква от диспечера на WPF с помощта на Диспечерработа. Например се опитвате да зададете тази стойност в манипулатор на събития на пи или в конструктора MainWindow. В тази ситуация стойностите CurrentCulture и CurrentUICulture се нулират до съответните си предишни стойности в края на метода. Ако приложението задава CurrentUICulture в своя конструктор MainWindow или в манипулатор за щракване с бутон, тази настройка се връща към културата на потребителския интерфейс на системата.

Тази корекция гарантира, че стойностите на CurrentThread.CurrentCulture/CurrentUICulture, които са зададени в методи в WPF приложение, продължават да съществуват по същия начин, както преди .NET Framework (платформа) 4.6.


 

Проблем 5

В .NET Framework (платформа) 4.6 към библиотеката със задачи се добавя нов флаг " Продължение на задачаOptions.RunContinuationsAsynchronously". Когато обаче използвате този флаг заедно със Task.WhenAll, Task.WhenAny или Task.Unwrap, флагът няма ефект. Флагът е въведен, за да се избегнат определени условия за блокиране. Тази корекция гарантира, че всички видове продължаване на задача спазват новия флаг.


 

Проблем 6

В .NET Framework (платформа) 4.6 има грешка в AppContext, която води до неправилно прилагане на безопасността на нишките на методите appContext. AppContext е част от инфраструктурата, за да се намалят прекъсваните промени. Можете да използвате AppContext, за да задавате и извличате флагове и да вземате решения във вашето приложение въз основа на тези данни.

Тази корекция позволява правилната безопасност на нишките за методите в AppContext, които са свързани с настройката и извличането на стойности на превключвателя.


 

Проблем 7

Когато срещнете ръб, който има вашия модел на разпределение и оцеляване, и се нуждаете от нов сегмент на управляваната купчина, колекционерът на отпадъци може да изчисли размер на къмита, който е по-малък от би трябвало. Това води до нарушаване на достъпа по време на компактната фаза, защото събирачът на отпадъци се опитва да запише в некомпрометната памет.

Тази корекция изчислява размера правилно.


 

Проблем 8

Когато създавате основен код за определени методи, възможно е .NET Framework (платформа) приложения и процеси на NGEN да възникнат неочаквани сривове.

Проблем 9

RyuJit генерира неправилни инструкции за сравняване на 16-битовите неподписани цели суми в регистрите. Той води до неправилен резултат, ако входните стойности имат различни СТОЙНОСТИ на MSB и ако сравняват инструкции, които са генерирани, използват операнди за регистриране.

Тази корекция генерира правилни инструкции.
 

Отнася се за

Тази статия се отнася за следното:
 

• Microsoft .NET Framework (платформа) 4.6.1

• Microsoft .NET Framework (платформа) 4.6, когато се използва с:
   

  • Windows 8.1

  • Windows RT 8,1

  • Windows център за данни на Server 2012 R2

  • Windows Server 2012 R2 Essentials

  • Windows Server 2012 R2 за вградени системи

  • Windows Server 2012 R2 Foundation

  • Windows Server 2012 R2 Standard