У цій статті описано зведене виправлення, доступне для Microsoft .NET Framework 4.6.1 і 4.6. Докладні відомості про проблеми, які виправляли це виправлення зведення, див. в розділі Проблеми з виправленнями цього виправлення .
Спосіб вирішення
Відомості про завантаження
Виправлення, що відповідають kb3139549, замінено на останні оновлення .NET Framework, які містять усі виправлення, раніше включені в KB3139549. Ми рекомендуємо інсталювати останні оновлення .NET Framework.
Докладніші відомості про завантаження файлів підтримки Microsoft див. у статті бази знань Microsoft:
119591 Як отримати файли підтримки Microsoft із онлайнових служб, які Корпорація Майкрософт шукає цей файл на наявність вірусів. Корпорація Майкрософт використовувала найновішу програму виявлення вірусів, доступну в день публікації файлу. Файл зберігається на серверах із посиленою безпекою, щоб запобігти несанкціонованим змінам файлу.
Додаткові відомості
Попередні вимоги
Щоб застосувати це виправлення, потрібно інсталювати .NET Framework 4.6.1 або .NET Framework 4.6.
Необхідність перезавантаження
Якщо використовуються такі файли, слід перезавантажити комп'ютер після застосування цього виправлення. Перш ніж застосовувати це виправлення, радимо .NET Framework всі програми на основі.
Відомості про заміну виправлень
Цей пакет виправлень не замінює раніше випущений пакет виправлень.
Проблеми, які виправляли це виправлення зведення
Проблема 1
Коли в програмі WPF використовується елемент TreeViewItem поза контекстом TreeView, у програмі може виникати виняток InvalidCastException, чиї трасування стека починається таким чином:
"Система". Windows. Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Примітка. Цей виняток виникає, якщо елемент керування TreeViewItem міститься в віртуалізованому елементі керування списком (наприклад, ListBox, DataGrid або ListView), який намагається знайти зсув прокручування TreeViewItem або елемента керування TreeViewItem чи одного з його спадання. Наприклад, якщо ви задекларували treeViewItem як корінь данихTemplate, а стовпець DataTemplate використовується як значення поля CellTemplate стовпця DataGrid, цей виняток виникає.
Проблема 2
Як System.Web.Caching, так і System.Runtime.Caching повідомляють про розмір пам'яті, який використовується в цілому документі AppDomain, а не розмір пам'яті, який використовується в елементах кеша.
Це проблема з регресією випуску .NET Framework 4.5, у якій внесено зміну в упровадженні таймера. Окрім повідомлення про неправильний розмір, додаткові об'єкти, на які посилається кеш, можуть суттєво вплинути на затримку Gen2 GC. У ASP.NET сценаріях розміщення кеш також неправильно обчислення розміру всіх кешів у всіх доменах програм (про які повідомляється через граничну кількість пам'яті кеша % процесу, використане ASP.NET лічильника продуктивності), коли утилізації доменів програм.
Виправлення видаляє несподійні посилання з кеша для решти об'єктів домену програми, а потім повідомляється правильний розмір. Він також містить зміни, які поліпшують затримку для System.Runtime.Caching на багатоязкових комп'ютерах, де використовується Server GC. Нарешті, це виправлення правильно обчислює розмір усіх кешів у сценаріях видалення домену програми.
Проблема 3
Якщо у вас є програма Система подання графіки (WPF), яка промотує рух миші, для обробки взаємодії користувача на сенсорному екрані (а не безпосередньо під час використання сенсорних подій), може виникати дуже низька гучність підвищеного руху миші.
У минулому миша WPF, що дроселюється, просувається, оскільки гучність дотиків переміщується надлишковим пересуванням. У .NET Framework 4.6.1 для цієї поведінки внесено виправлення. Виправлення реагує на кількість рухів дотику. Таким чином, збільшення кількості промоакцій миші спричиняє подальше зменшення рухів миші. У цьому зведеному оновленнях дроселювання промоакцій миші вилучено, і тепер має бути близьке до 1 листування між подіями руху дотиків і підвищеними подіями переміщення мишею.
Проблема 4
Припустімо, що ви працюєте в програмі WPF, яка працює в .NET Framework 4.6. Наприклад, припустімо, що ви намагаєтеся встановити CurrentThread.CurrentCulture або CurrentThread.CurrentUICulture будь-яким способом (наприклад, обробником події інтерфейсу користувача або конструктором MainWindow), який викликав надбудова WPF Dispatcher, використовуючи надбудову DispatcherOperation. У цій ситуації значення CurrentCulture і CurrentUICulture скидаються до відповідних попередніх значень наприкінці методу. Якщо програма призначить параметр CurrentUICulture конструктору MainWindow або клацаю кнопки, цей параметр відновлюється до системної культури інтерфейсу користувача.
Це виправлення гарантує, що значення CurrentThread.CurrentCulture/CurrentUICulture, які можна встановлювати в методах у програмі WPF, не відносяться до значення .NET Framework 4.6.
Проблема 5
У .NET Framework 4.6 до бібліотеки завдань додано нову позначку TaskContinuationOptions.RunContinuationsAsynchronously. Однак, якщо позначити цю позначку в поєднання з полем Task.WhenAll, Task.WhenAny або Task.Unwrap, ця позначка не почне діяти. Позначка представлена, щоб уникнути певних крайніх умов. Це виправлення гарантує, що всі типи продовження завдань поважають нову позначку.
Проблема 6
AppContext – це частина інфраструктури, яка зменшує невиконання змін. За допомогою AppContext можна встановлювати й отримувати позначки, а також приймати рішення в програмі на основі даних. В .NET Framework 4.6 помилка в AppContext, коли методи AppContext використовуються неправильно.
Це виправлення забезпечує правильну безпеку потоків для методів у AppContext, пов'язаних із налаштуванням і отриманням значень перемикачів.
Проблема 7
Якщо ви перейдете до межі регістра зі схемою виділення та виживанням, і вам потрібен новий сегмент у керованому геоплі, збирання смітів може обчислити розмір зобов'язання, менший за нього. Це спричиняє порушення доступу на компактному етапі, оскільки збирання смітник намагається записати в незахищену пам'ять. Це виправлення правильно обчислює розмір.
Проблема 8
Якщо створити власний код для певних методів, програми та процеси NGEN .NET Framework можуть аварійно завершувати роботу.
Проблема 9
RyuJit створює неправильні інструкції для порівняння 16-розрядних непідписаних цілих числів під час реєстрації. Він створює неправильні результати, якщо вхідні значення мають різні значення MSB, і тому створюються інструкції для порівняння, які використовують лише реєстрацію операндів. Це виправлення генерує правильні інструкції.
