3139551 пакет поточних виправлень для платформи .NET Framework 4.6.1 та 4.6, в ОС Windows

Проблема 1

Коли WPF-застосунок, використовує TreeViewItem окремо від, TreeView, програми, можуть виникнути виняток InvalidCastException , до якого трасування стека починається з таким чином.

System.Windows.Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Примітка. Цей виняток відбувається, коли, TreeViewItem віртуального списку керування (наприклад, у список, Дата Грідабо відображення списків керування), який намагається знайти прокручування зсув, TreeViewItem , або один із його нащадків. Наприклад, цей виняток виникає, якщо ви оголосити, TreeViewItem як до кореневої папки, DataTemplate, DataTemplate , що використовується як CellTemplate , що Дата Грід стовпця.

Проблема 2

System.Web.Caching , так і System.Runtime.Caching , повідомте про розмір пам'яті, що використовується весь домен застосунку, замість пам'яті, який використовується в кеші елементів.

Це регресії з в .NET Framework 4.5 через зміну в реалізації таймера. Окрім звітування розмір, додаткові об'єкти, які посилаються кеш-пам'яті може суттєво вплинути gen2 глобального Каталогу затримки. В ASP.NET хостинг сценарії, кеш-пам'яті й прорахувався розмір усіх кешуванням у всіх доменах для застосунку, (як повідомив через лічильників продуктивності "Кеш % процес використано для обмеження пам'яті" ASP.NET) коли застосунок домени були відновлений.

Виправлення видаляє ненавмисне посилання з кеша до іншого застосунку домену об'єктів так, що повідомляється неправильний розмір. Це виправлення, також містить зміни, внесені до покращення затримку System.Runtime.Caching на багатоядерних комп'ютерів, які використовують GC-сервер. Крім того, після цього виправлення, розмір усіх кеш в домені застосунку, переробка сценарії визначається правильно.

Проблема 3

Якщо у вас є застосування Windows подання графіки (WPF), пов'язане з рекламою миші контакт переміщує для взаємодії з користувачем зв'язку (а не за безпосередньо, використовуючи торкнутися події), можуть виникнути надто низька Том, підвищено вказівник рухається.

Раніше WPF, цих миша підвищення зв'язку переміщує уникнути великий обсяг зв'язку, переміщення, знищити Диспетчер. У .NET Framework 4.6.1 throttle, кількість зв'язку, переміщення, обробляються була представлена виправлення. Після цього зміни у дроселювання акції мишу, причиною вигляді кількості миші, переміщення, було створено. Дроселювання у миші акції вилучено так, що має бути майже один відповідності сенсорний переміщення події та підвищено перемістити курсор.

Помилка 4

Припустімо, що ви працюєте в застосунку WPF який застосовує до .NET Framework 4.6. Ви намагаєтеся встановити значення CurrentThread.CurrentCulture або CurrentThread.CurrentUICulture у спосіб, який викликається WPF Диспетчер за допомогою до DispatcherOperation. Наприклад, ви намагаєтеся встановити це значення в інтерфейс обробника подій або Конструктор MainWindow. У цьому випадку попереднього відповідні значення у кінці способу скинути значення CurrentCulture та CurrentUICulture . Якщо програма набору CurrentUICulture , його MainWindow-конструктора або кнопка обробник, цей параметр повертається до системи інтерфейсу користувача культури.

Це виправлення гарантує, що значення CurrentThread.CurrentCulture/CurrentUICulture , установленими способів, у застосунку WPF зберігаються таким же чином, як і раніше в .NET Framework 4.6.

Проблема 5

У полі 4.6 .NET Framework новий прапор, TaskContinuationOptions.RunContinuationsAsynchronously, додаються до бібліотеки завдання . Однак при використанні прапора разом з Task.WhenAll, Task.WhenAny або Task.Unwrap, позначку ніяк не впливає. Прапор була представлена уникнути за певних умов, взаємоблокування. Це виправлення гарантує, що всіх видів завдань частини, підтримує новий прапор.

Проблема 6

У полі 4.6 .NET Framework є помилка AppContext викликає потік безпеки AppContext способи здійснюватися неналежним чином. AppContext є інфраструктура для зменшення порушення зміни. Можна використовувати AppContext встановлення та отримання позначки, так і для прийняття рішень у вашому застосунку, на основі цих даних.

Це виправлення, дає правильний безпеки для методи AppContext, які стосуються настройка та отримання ключ-значення.

Помилка 7

Вами, край випадку ваш виділення та практичні поради стосовно шаблон, і потрібно, сегменту на ваш керованих пам'яті, збирач-сміття може визначати здійснювати розмір, який займає менше місця, ніж зазвичай. Це призводить до порушення прав доступу на етапі компактної через те, що у збирач сміття намагається виконати записування до незавершених пам'яті.

Це виправлення обчислює розмір належним чином.

Проблеми з 8

Під час створення власного коду для деяких способів, .NET Framework застосунків і NGEN процеси можуть виникати спричинюють неочікуване аварійне завершення роботи.

Проблеми з 9

RyuJit, створює неправильні інструкції для порівняння 16-розрядних непідписані чисел, на синхронізацію регістрів. Він забезпечує неправильний результат, введення значень, мають різні ГРЩ, значення, і, якщо порівняти інструкції, створені за допомогою реєстру операндів.

Це виправлення, генерує правильні інструкції.

Застосовується до

Ця стаття застосовується до такого:

• Microsoft .NET Framework 4.6.1

• Microsoft .NET Framework 4.6, під час використання з:
  
  

  • Windows 7 Service Pack 1

  • Windows Server 2008 R2 Service Pack 1

  • Windows Server 2008 Service Pack 2

  • Windows Vista Service Pack 2