Перенацеливание изменений для миграции на платформа .NET Framework 4.6.x

В этой статье перечислены проблемы совместимости приложений, представленные в платформе .NET Framework 4.6, 4.6.1 и 4.6.2.

.NET Framework 4.6

ASP.NET

HtmlTextWriter неправильно отображает элемент <br/>

Сведения

Начиная с .NET Framework 4.6, при вызове RenderBeginTag(String) и RenderEndTag() с элементом <BR /> правильно вставляется только один <BR /> (вместо двух).

Предложение

Если приложение зависит от дополнительного тега <BR />, RenderBeginTag(String) следует вызвать второй раз. Обратите внимание, что это изменение поведения влияет только на приложения, предназначенные для .NET Framework 4.6 или более поздних версий, поэтому другим вариантом является нацеливание на предыдущую версию платформы .NET Framework для получения старого поведения.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Затронутые API

ClickOnce

Приложения, опубликованные с помощью ClickOnce с использованием сертификата подписи кода SHA-256, могут завершиться ошибкой в Windows 2003

Сведения

Исполняемый файл подписывается с помощью SHA256. Ранее он подписывался с помощью SHA1 независимо от того, какой использовался сертификат подписи кода: SHA-1 или SHA-256. Применение:

  • Все приложения, собранные с помощью Visual Studio 2012 или более поздней версии.
  • Приложения, собранные с помощью Visual Studio 2010 или более ранней версии в системах с установленной платформой .NET Framework 4.5. Кроме того, при наличии .NET Framework 4.5 или более поздней версии манифест ClickOnce также подписывается с помощью SHA-256 для сертификатов SHA-256 независимо от версии .NET Framework, в которой проводилась компиляция.

Предложение

Изменение в подписании исполняемого файла ClickOnce влияет только на системы Windows Server 2003; требуется, чтобы была установлена статья базы знаний KB 938397. Изменение метода подписи манифеста с использованием SHA-256, даже когда приложение нацелено на .NET Framework 4.0 или более раннюю версию, создает зависимость в среде выполнения от .NET Framework 4.5 или более поздней версии.

Имя. Значение
Область Microsoft Edge
Версия 4,5
Тип Ретаргетинг

ClickOnce поддерживает SHA-256 в приложениях, предназначенных для версии 4.0

Сведения

Раньше приложению ClickOnce с сертификатом, подписанным с SHA-256, требовалась платформа .NET Framework 4.5 или более поздней версии, даже если приложение предназначено для версии 4.0. Теперь приложения ClickOnce, предназначенные для .NET Framework 4.0, можно запускать на .NET Framework 4.0, даже если они подписаны с помощью алгоритма SHA-256.

Предложение

Это изменение удаляет зависимость и позволяет использовать сертификаты SHA-256 для подписи приложений ClickOnce на платформе .NET Framework 4 и более ранних версий.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Ядро

Поток CurrentCulture и CurrentUICulture между задачами

Сведения

Начиная с .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture хранятся в System.Threading.ExecutionContext потока, который проходит через асинхронные операции. Это означает, что изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture будут отражены в задачах, которые позже выполняются асинхронно. Это отличается от поведения предыдущих версий .NET Framework (которые во всех асинхронных задачах сбрасывали System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture).

Предложение

Приложения, которых коснулось это изменение, могут обойти его, явно задав System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в качестве первой операции в асинхронной задаче. Кроме того, можно выбрать прежнее поведение (без потока System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) путем установки следующего переключателя совместимости:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получат правильное поведение в WPF-приложениях, и System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture будет сохранено в операциях диспетчера.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

Названия событий ETW не должны отличаться только суффиксами "Start" или "Stop".

Сведения

В .NET Framework 4.6 и 4.6.1 во время выполнения выбрасывается исключение ArgumentException, если имена двух событий в трассировке событий Windows отличаются только суффиксами "Start" или "Stop" (например, когда одно событие называется LogUser, а другое — LogUserStart). В этом случае среда выполнения не может создать источник событий, который не может генерировать никаких записей в журнале.

Предложение

Чтобы предотвратить возникновение исключения, убедитесь, что имена событий отличаются не только суффиксами Start или Stop. Это требование снято в .NET Framework 4.6.2 и более поздних версий. Среда выполнения может устранить неоднозначность имен событий, которые отличаются только суффиксами Start и Stop.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Entity Framework (Энтити Фреймворк)

Построение EDMX Entity Framework с помощью Visual Studio 2013 может завершиться ошибкой MSB4062, если используются задачи EntityDeploySplit или EntityClean

Сведения

Инструменты MSBuild версии 12.0 (в составе Visual Studio 2013) изменили расположение файлов MSBuild, из-за чего старые целевые файлы Entity Framework стали недействительными. В результате задачи EntityDeploySplit и EntityClean завершаются ошибкой, так как они не могут найти Microsoft.Data.Entity.Build.Tasks.dll. Обратите внимание, что это нарушение возникает вследствие изменения набора инструментов (MSBuild и Visual Studio), а не из-за изменения платформы .NET Framework. Оно происходит только при обновлении средств разработчика, а не просто при обновлении .NET Framework.

Предложение

Начиная с .NET Framework 4.6, исправлены целевые файлы Entity Framework для работы с новым макетом MSBuild. Обновление до этой версии Framework решит данную проблему. В качестве альтернативы, этот обходной путь можно использовать для непосредственного исправления целевых файлов.

Имя. Значение
Область Основная
Версия 4.5.1
Тип Ретаргетинг

JIT

Инструкция IL ret недопустима в области try

Сведения

В отличие от компилятора JIT64, RyuJIT (используемого в .NET Framework 4.6) не допускает инструкцию IL ret в блоке try. Возврат из области try запрещен в спецификации ECMA-335, и ни один известный управляемый компилятор не создает такие IL. Однако компилятор JIT64 выполнит такие IL, если они созданы с помощью порождения отражения.

Предложение

Если приложение создает IL, который включает в себя код операции ret в области try, это приложение можно нацелить на платформу .NET Framework 4.5, чтобы использовать старый JIT-компилятор и избежать этой проблемы. Кроме того, создаваемый IL-код можно обновить, чтобы он возвращался после области try.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Новый 64-разрядный JIT-компилятор в .NET Framework 4.6

Сведения

Начиная с .NET Framework 4.6, для JIT-компиляции используется новый 64-разрядный компилятор JIT. В некоторых случаях вызывается непредвиденное исключение или наблюдается другое поведение, отличное от поведения при выполнении приложения с использованием 32-разрядного компилятора или старого 64-разрядного JIT-компилятора. Это изменение не влияет на 32-разрядный компилятор JIT. Известные различия включают в себя следующее.

  • При определенных условиях операция распаковки может вызывать исключение NullReferenceException в релизных сборках при включенной оптимизации.
  • В некоторых случаях выполнение рабочего кода в большом теле метода может вызывать исключение StackOverflowException.
  • При определенных условиях в сборках выпусков передаваемые методу структуры обрабатываются как ссылочные типы, а не типы значений. Одним из проявлений этой проблемы является то, что отдельные элементы коллекции располагаются в неожиданном порядке.
  • При определенных условиях сравнение значений UInt16 с установленным старшим битом выполняется неверно, если включена оптимизация.
  • При определенных условиях, особенно при инициализации значений массивов, инициализация памяти инструкцией OpCodes.Initblk IL может инициализировать память неправильным значением. Это может привести либо к необработанному исключению, либо к неправильным выходным данным.
  • В некоторых редких случаях условная поразрядная проверка может возвращать неверное значение типа Boolean или вызывать исключение, если включены оптимизации компилятора.
  • При определенных условиях, если инструкция if используется для проверки условия перед входом в блок try и на выходе из блока try, и такое же условие вычисляется в блоке catch или finally, новый 64-разрядный JIT-компилятор удаляет условие if из блока catch или finally при оптимизации кода. В результате код внутри инструкции if в блоке catch или finally выполняется безусловно.

Предложение

Устранение известных проблем
При возникновении перечисленных выше проблем их можно решить, выполнив одно из следующих действий.

  • Обновление до .NET Framework 4.6.2. Новый 64-разрядный компилятор, входящий в состав .NET Framework 4.6.2, устраняет все эти известные проблемы.

  • Убедитесь, что ваша версия Windows обновлена, выполнив Центр обновления Windows. Обновления служб для .NET Framework 4.6 и 4.6.1 решают все эти проблемы, кроме NullReferenceException в операции распаковки.

  • Компиляция с помощью старого 64-разрядного JIT-компилятора. Дополнительные сведения о том, как это сделать, см. в разделе Устранение других проблем. Устранение других проблем
    При возникновении любых других различий в поведении между кодом, скомпилированным с помощью старого и нового 64-разрядных JIT-компиляторов, или между отладочной и окончательной версиями приложения, которые обе скомпилированы новым 64-разрядным JIT-компилятором, можно выполнить следующие действия для компиляции приложения с помощью старого 64-разрядного JIT-компилятора.

  • Для каждого отдельного приложения можно добавить элемент < в файл конфигурации приложения. Следующее действие отключает компиляцию с помощью нового 64-разрядного JIT-компилятора и вместо этого использует устаревший 64-разрядный JIT-компилятор.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Для каждого отдельного пользователя можно добавить значение REG_DWORD с именем useLegacyJit в раздел реестра HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework. Значение 1 включает устаревший 64-разрядный JIT-компилятор; значение 0 отключает его и включает новый 64-разрядный JIT-компилятор.

  • Для каждого отдельного компьютера можно добавить значение REG_DWORD с именем useLegacyJit в раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework. Значение 1 включает устаревший 64-разрядный JIT-компилятор; значение 0 отключает его и включает новый 64-разрядный JIT-компилятор. Можно также сообщить нам об обнаруженной проблеме, обратившись в службу Microsoft Connect.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Сеть

Проверка OID EKU сертификата

Сведения

Начиная с .NET Framework 4.6 классы SslStream или ServicePointManager выполняют проверку идентификатора объекта (OID) расширенного использования ключа (EKU). Расширение ключа для расширенного использования (EKU) — это коллекция идентификаторов объектов (OID), которая указывает на приложения, которые используют ключ. При проверке OID EKU используются обратные вызовы удаленного сертификата, чтобы у удаленного сертификата были правильные OID для указанных целей.

Предложение

Если это изменение нежелательно, можно отключить проверку OID сертификата EKU, добавив следующий параметр в <AppContextSwitchOverrides> в ` файле конфигурации приложения:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Внимание

Этот параметр предоставляется исключительно для обратной совместимости. Его использование в других целях не рекомендуется.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

В System.Net.ServicePointManager и System.Net.Security.SslStream поддерживаются только протоколы Tls 1.0, 1.1 и 1.2

Сведения

Начиная с .NET Framework 4.6, ServicePointManager и SslStream классы могут использовать только один из следующих трех протоколов: Tls1.0, Tls1.1 или Tls1.2. Протокол SSL 3.0 и шифрование RC4 не поддерживаются.

Предложение

Рекомендуется обновить серверные приложения до TLS 1.0, 1.1 или 1.2. Если это невозможно, или если клиентские приложения не работают, можно использовать класс System.AppContext, чтобы отказаться от этой функции одним из двух способов.

  • Путем программной установки параметров совместимости на System.AppContext, как описано в анонсах .NET на Build 2015 года.
  • путем добавления следующей строки в раздел <runtime> файла app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

TLS 1.x по умолчанию передает флаг SCH_SEND_AUX_RECORD базовому API SCHANNEL

Сведения

При использовании TLS 1.x .NET Framework зависит от базового интерфейса API Windows SCHANNEL. Начиная с .NET Framework 4.6 флаг SCH_SEND_AUX_RECORD передается SCHANNEL по умолчанию. В результате SCHANNEL разделяет данные для шифрования на две отдельные записи. В первой — один байт, а во второй — n-1 байт. В редких случаях это нарушает логику взаимодействия между клиентами и существующими серверами, которая предполагает, что данные находятся в одной записи.

Предложение

Если это изменение нарушает связь с существующим сервером, вы можете отключить отправку флага SCH_SEND_AUX_RECORD и восстановить предыдущее поведение, при котором данные не разделяются на две записи, добавив следующий переключатель в элемент <AppContextSwitchOverrides> в разделе <runtime> файла конфигурации приложения:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Внимание

Этот параметр предоставляется исключительно для обратной совместимости. Его использование в других целях не рекомендуется.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Затронутые API

Windows Communication Foundation (WCF)

Был изменен вызов метода CreateDefaultAuthorizationContext с аргументом NULL

Сведения

В версии .NET Framework 4.6 изменилась реализация System.IdentityModel.Policy.AuthorizationContext, которая возвращается вызовом функции System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) с нулевым значением аргумента authorizationPolicies.

Предложение

В редких случаях в приложениях WCF, которые используют настраиваемую проверку подлинности, могут возникать различия в поведении. В таких случаях прежнее поведение можно восстановить двумя способами.

  • Перекомпилируйте приложение для ориентации на версию .NET Framework, предшествующую 4.6. Для служб, размещенных в IIS, используйте элемент <httpRuntime targetFramework="x.x"> для выбора более ранней версии .NET Framework в качестве целевой платформы.

  • Добавьте следующую строку в раздел <appSettings> файла app.config.

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

Windows Forms

Icon.ToBitmap успешно преобразует значки с кадрами PNG в растровые изображения

Сведения

Начиная с приложений, предназначенных для .NET Framework 4.6, метод Icon.ToBitmap успешно преобразует значки с кадрами PNG в объекты Bitmap.

В приложениях, предназначенных для платформы .NET Framework 4.5.2 и более ранних версий, метод создает исключение, если объект Icon имеет кадры PNG.

Это изменение затрагивает приложения, которые перекомпилируются под платформу .NET Framework 4.6 и в которых реализована специальная обработка исключения ArgumentOutOfRangeException, генерируемого при наличии в объекте Icon кадров PNG. При выполнении в .NET Framework 4.6 преобразование проходит успешно, исключение ArgumentOutOfRangeException больше не создается, и поэтому обработчик исключений больше не вызывается.

Предложение

Если такое поведение нежелательно, можно сохранить прежнее поведение, добавив в раздел <runtime> файла app.config следующий элемент:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Если файл app.config уже содержит элемент AppContextSwitchOverrides, новое значение следует объединить с атрибутом значения следующим образом:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

Windows Presentation Foundation (WPF)

CurrentCulture не сохраняется в операциях диспетчера WPF

Сведения

Начиная с версии .NET Framework 4.6, изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture, внесенные в ходе операции System.Windows.Threading.Dispatcher, будут утеряны к моменту завершения этой операции диспетчеризации. Аналогичным образом, изменения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture, внесенные за пределами операции Dispatcher, не будут учитываться при выполнении этой операции. С практической точки зрения это означает, что изменения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture могут не передаваться между обратными вызовами пользовательского интерфейса WPF и другим кодом приложения WPF. Это связано с изменением в System.Threading.ExecutionContext, в результате которого System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture сохраняются в контексте выполнения, начиная с приложений, предназначенных для версии .NET Framework 4.6. Операции диспетчеризации WPF сохраняют контекст выполнения, который используется для запуска операции и восстановления предыдущего контекста при завершении операции. Поскольку System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture теперь являются частью этого контекста, внесенные в рамках операции диспетчеризации изменения не сохраняются вне этой операции.

Предложение

В приложениях, на которые повлияет это изменение, можно обойти данную проблему, сохранив System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в поле и проверив во всех телах операций диспетчера (включая обработчики обратных вызовов событий пользовательского интерфейса), что установлены правильные значения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture. Кроме того, поскольку изменение ExecutionContext, являющееся базовым для этого изменения WPF, влияет только на приложения, предназначенные для .NET Framework 4.6 или более поздних версий, это нарушение можно исключить путем нацеливания на .NET Framework 4.5.2. В приложениях, ориентированных на платформу .NET Framework 4.6 или более поздней версии, эту проблему можно обойти, установив следующий параметр совместимости:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получат правильное поведение в WPF-приложениях, и System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture будет сохранено в операциях диспетчера.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Изменились параметры округления полей макета WPF

Сведения

Способ округления полей, а также их границ и фона, изменен. В результате этого изменения:

  • ширина или высота элементов может увеличиться или уменьшиться максимум на один пиксель;
  • расположение объекта может измениться максимум на один пиксель;
  • Центрированные элементы могут сместиться по вертикали или горизонтали от центра максимум на один пиксель. По умолчанию новый макет включен только для приложений, предназначенных для .NET Framework 4.6.

Предложение

Поскольку это изменение, как правило, приводит к устранению обрезки правых или нижних элементов управления WPF при высоком разрешении, для приложений, предназначенных для более ранних версий .NET Framework, но выполняющихся в .NET Framework 4.6, можно выбрать это новое поведение, добавив следующую строку в раздел <runtime> файла app.config.

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Для приложений, предназначенных для .NET Framework 4.6, в которых требуется задать отрисовку элементов управления WPF с помощью прежнего алгоритма макета, можно добавить следующую строку в раздел <runtime> файла app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

XML, XSLT

XmlWriter вызывает недействительные суррогатные пары

Сведения

Для приложений с целевой платформой .NET Framework 4.5.2 или предыдущих версий запись недействительной суррогатной пары с помощью обработки резервного исключения не всегда вызывает исключение. Для приложений с целевой платформой .NET Framework 4.6 попытка записи недействительной суррогатной пары вызывает исключение System.ArgumentException.

Предложение

При необходимости этого прерывания можно избежать, выбрав в качестве целевой платформы .NET Framework 4.5.2 или более ранней версии. Кроме того, до записи недействительных суррогатных пар можно предварительно обработать их и преобразовать в допустимый xml.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип ретаргетинг

Затронутые API

Проверка схемы XSD теперь правильно обнаруживает нарушения уникальных ограничений, если используются составные ключи и один ключ пуст

Сведения

В версиях платформы .NET Framework, предшествовавших версии 4.6, была ошибка, из-за которой проверка XSD не могла обнаруживать уникальные ограничения по составным ключам, если один из ключей был пуст. Эта проблема решена в .NET Framework 4.6. Это приведет к выполнению более правильной проверки, но также может привести к невозможности проверки некоторого XML-кода, которая осуществлялась раньше.

Предложение

Если требуется менее строгая проверка .NET Framework 4.0, проверяющее приложение может быть предназначено для версии 4.5 (или более ранней) платформы .NET Framework. Однако при изменении целевой платформы на .NET Framework 4.6 необходимо выполнить проверку кода, чтобы убедиться, что повторяющиеся составные ключи, как указано в описании текущей проблемы, не должны ожидаться для проверки.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Перенаправление рекламы

.NET Framework 4.6.1

Ядро

Изменение знака разделения пути в свойстве FullName объектов ZipArchiveEntry

Сведения

Для приложений, предназначенных для платформы .NET Framework версии 4.6.1 и выше, символ разделителя пути изменился с обратного слэша ("\") на косую черту ("/") в свойстве FullName объектов ZipArchiveEntry, созданных перегрузками метода CreateFromDirectory. Изменение обеспечивает соответствие реализации .NET разделу 4.4.17.1 спецификации формата ZIP-файла и позволяет распаковывать ZIP-архивы в системах, отличных от Windows.
При распаковке ZIP-файла, созданного приложением, предназначенным для предыдущей версии платформы .NET Framework в операционных системах, отличающихся от Windows, таких как Macintosh, не удается сохранить структуру каталогов. Например, в Macintosh создается набор файлов, имя которого объединяет путь к каталогу, а также все символы обратной косой черты (\) и имя файла. В результате структура каталогов распакованных файлов не сохраняется.

Предложение

Влияние этого изменения на файлы .ZIP, которые распаковываются в операционной системе Windows с помощью API в пространстве имен .NET Framework System.IO, будет минимальным, так как эти API могут без проблем обрабатывать как косую черту ("/"), так и обратную косую черту ("\") в качестве символа разделителя путей.
Если такое изменение нежелательно, от него можно отказаться, добавив параметр конфигурации в раздел <runtime> файла конфигурации приложения. В следующем примере показан как раздел <runtime>, так и параметр отключения Switch.System.IO.Compression.ZipFile.UseBackslash:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Кроме того, в приложениях, предназначенных для предыдущих версий .NET Framework, но выполняемых в .NET Framework 4.6.1 и более поздних версий, можно включить такое поведение, добавив параметр конфигурации в раздел <runtime> файла конфигурации приложения. Ниже представлены как секция <runtime>, так и переключатель подтверждения Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Имя. Значение
Область Microsoft Edge
Версия 4.6.1
Тип Ретаргетинг

Затронутые API

Windows Communication Foundation (WCF)

Связывание WCF с режимом безопасности TransportWithMessageCredential

Сведения

Начиная с платформы .NET Framework 4.6.1, привязку WCF, использующую режим безопасности TransportWithMessageCredential, можно настроить для получения сообщений с незавизированными заголовками "to" для асимметричных ключей безопасности. По умолчанию, в платформе .NET Framework 4.6.1 незавизированные заголовки "to" будут по-прежнему отклоняться. Они будут приниматься только если приложение выберет новый режим работы, используя переключатель конфигурации Switch.System.ServiceModel.AllowUnsignedToHeader.

Предложение

Поскольку это возможность, включаемая пользователем, она не должна влиять на поведение существующих приложений.
Для включения или отключения нового поведения используйте следующий параметр конфигурации:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Имя. Значение
Область Прозрачный
Версия 4.6.1
Тип Ретаргетинг

Затронутые API

X509CertificateClaimSet.FindClaims учитывает все типы утверждений

Сведения

Если в приложениях, предназначенных для .NET Framework 4.6.1, набор утверждений X509 инициализируется из сертификата, имеющего несколько записей DNS в поле SAN, метод System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) пытается сопоставить аргумент claimType со всеми записями DNS. В приложениях, предназначенных для предыдущих версий .NET Framework, метод System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) пытается сопоставить аргумент claimType только с последней записью DNS.

Предложение

Это изменение затрагивает только приложения, предназначенные для .NET Framework 4.6.1. Это изменение можно отключить (или включить, если используются версии, предшествующие 4.6.1) с помощью параметра совместимости DisableMultipleDNSEntries.

Имя. Значение
Область Незначительный
Версия 4.6.1
Тип Ретаргетинг

Затронутые API

Windows Forms

Application.FilterMessage больше не создает исключение для повторно входящих реализаций IMessageFilter.PreFilterMessage

Сведения

До версии .NET Framework 4.6.1 вызов FilterMessage(Message) с PreFilterMessage(Message), который вызывал System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) или System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (одновременно вызывая DoEvents()), приводил к возникновению исключения System.IndexOutOfRangeException.

Начиная с приложений, предназначенных для платформы .NET Framework 4.6.1, это исключение больше не возникает, и повторно входящие фильтры, как описано выше, могут использоваться.

Предложение

Имейте в виду, что FilterMessage(Message) больше не выбрасывает исключение для поведения PreFilterMessage(Message) с повторным входом, описанного выше. Будут затронуты только приложения, предназначенные для .NET Framework 4.6.1. Приложения, предназначенные для .NET Framework 4.6.1, могут отказаться от этого изменения, а приложения для более старых версий платформы могут его принять, используя параметр совместимости DontSupportReentrantFilterMessage.

Имя. Значение
Область Microsoft Edge
Версия 4.6.1
Тип Ретаргетинг

Затронутые API

Windows Presentation Foundation (WPF)

Вызовы метода System.Windows.Input.PenContext.Disable в сенсорных системах могут вызвать исключение ArgumentException.

Сведения

В некоторых случаях вызовы внутреннего метода System.Windows.Intput.PenContext.Disable в системах с поддержкой сенсорного ввода могут вызывать необработанное исключение T:System.ArgumentException из-за повторного входа.

Предложение

Эта проблема была устранена в .NET Framework 4.7. Чтобы это исключение не возникало, выполните обновление до версии платформы .NET Framework 4.7 или более поздней.

Имя. Значение
Область Microsoft Edge
Версия 4.6.1
Тип Ретаргетинг

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath создает исключение NullReferenceException

Сведения

В платформе .NET Framework 4.6.2 среда выполнения создает исключение T:System.NullReferenceException при получении значения P:System.Web.HttpRuntime.AppDomainAppPath, которое содержит нуль-символы. В .NET Framework 4.6.1 и более ранних версий среда выполнения создает исключение T:System.ArgumentNullException.

Предложение

В ответ на это изменение можно выполнить одно из следующих действий:

  • Обработайте T:System.NullReferenceException, если ваше приложение работает на платформе .NET Framework 4.6.2.
  • обновите систему до версии .NET Framework 4.7, в которой восстановлено прежнее поведение, выбрасывается исключение T:System.ArgumentNullException.
Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Ядро

Дешифратор AesCryptoServiceProvider предоставляет преобразование для повторного использования

Сведения

Начиная с приложений, предназначенных для .NET Framework 4.6.2, дешифратор AesCryptoServiceProvider возвращает преобразование, которое можно использовать повторно. Это преобразование повторно инициализируется после вызова System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) и его можно использовать снова. В приложениях, предназначенных для более ранних версий платформы .NET Framework, попытка повторного использования дешифратора путем вызова System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) после вызова System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) приводит к исключению CryptographicException или к повреждению данных.

Предложение

Влияние этого изменения должно быть минимальным, поскольку это ожидаемое поведение. В приложениях, которые зависят от прежнего поведения, можно отказаться от его изменения, добавив следующий параметр конфигурации в раздел <runtime> файла конфигурации приложения:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Кроме того, это поведение можно включить для приложений, предназначенных для предыдущих версий .NET Framework, но работающих под управлением .NET Framework 4.6.2 или более поздних версий. Для этого добавьте в раздел <runtime> файла конфигурации приложения следующий параметр:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Имя. Значение
Область Незначительный
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Вызовы к конструкторам ClaimsIdentity

Сведения

Начиная с .NET Framework 4.6.2 конструкторы ClaimsIdentity с параметром System.Security.Principal.IIdentity иначе задают свойство System.Security.Claims.ClaimsIdentity.Actor. Если аргумент System.Security.Principal.IIdentity является объектом ClaimsIdentity, а свойство System.Security.Claims.ClaimsIdentity.Actor этого объекта ClaimsIdentity не равно null, свойство System.Security.Claims.ClaimsIdentity.Actor присоединяется с помощью метода Clone(). В Framework 4.6.1 и более ранних версиях свойство System.Security.Claims.ClaimsIdentity.Actor прикреплено как существующая ссылка. В результате этого изменения, начиная с .NET Framework 4.6.2, свойство System.Security.Claims.ClaimsIdentity.Actor нового объекта ClaimsIdentity не равно свойству System.Security.Claims.ClaimsIdentity.Actor аргумента конструктора System.Security.Principal.IIdentity. В .NET Framework 4.6.1 и более ранних версиях они равны.

Предложение

Если такое поведение нежелательно, можно восстановить прежнее поведение, задав переключателю Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity в файле конфигурации приложения значение true. Для этого требуется добавить следующую информацию в раздел <runtime> файла web.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Изменения нормализации путей

Сведения

Начиная с приложений, предназначенных для .NET Framework 4.6.2, был изменен способ нормализации путей в среде выполнения. Нормализация пути включает в себя изменение строки, обозначающей путь или файл, чтобы эта строка соответствовала допустимому пути в целевой операционной системе. Нормализация обычно включает в себя:

  • канонизацию разделителей компонентов и каталогов;
  • применение текущего каталога к относительному пути;
  • Оценка относительного каталога (.) или каталога родителя (..) в пути.
  • Обрезка указанных символов. Начиная с приложений, предназначенных для платформы .NET Framework 4.6.2, по умолчанию включены следующие изменения в нормализации пути:
    • Исполняющая среда поручает операционной системе использовать функцию GetFullPathName для нормализации путей.
  • Нормализация больше не требует обрезки окончания сегментов каталогов (например, пробела в конце имени каталога).
  • Поддержка синтаксиса пути устройства в режиме полного доверия, включая \\.\ и \\?\ для API-интерфейсов файлового ввода-вывода в mscorlib.dll.
  • Среда выполнения не проверяет синтаксические пути устройств.
  • Поддерживается использование синтаксиса устройства для доступа к альтернативным потокам данных. Эти изменения улучшают производительность, позволяя методам получать доступ к ранее недоступным путям. Это изменение не влияет на приложения, предназначенные для .NET Framework 4.6.1 и более ранних версий, но работающие на платформе .NET Framework 4.6.2 или более новой версии.

Предложение

В приложениях, предназначенных для .NET Framework 4.6.2 или более поздней версии, данное изменение можно отключить и использовать устаревшую нормализацию, добавив следующее в раздел <runtime> файла конфигурации приложения:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

В приложениях, предназначенных для .NET Framework 4.6.1 или более ранней версии, но работающих на платформе .NET Framework 4.6.2 или более поздней версии, можно включить изменения в нормализацию пути, добавив следующую строку в раздел <runtime> файла конфигурации приложения:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Имя. Значение
Область Незначительный
Версия 4.6.2
Тип Ретаргетинг

Поток CurrentCulture и CurrentUICulture между задачами

Сведения

Начиная с .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture хранятся в System.Threading.ExecutionContext потока, который проходит через асинхронные операции. Это означает, что изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture будут отражены в задачах, которые позже выполняются асинхронно. Это отличается от поведения предыдущих версий .NET Framework (которые во всех асинхронных задачах сбрасывали System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture).

Предложение

Приложения, которых коснулось это изменение, могут обойти его, явно задав System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в качестве первой операции в асинхронной задаче. Кроме того, можно выбрать прежнее поведение (без потока System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) путем установки следующего переключателя совместимости:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получат правильное поведение в WPF-приложениях, и System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture будет сохранено в операциях диспетчера.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг

Затронутые API

Названия событий ETW не должны отличаться только суффиксами "Start" или "Stop".

Сведения

В .NET Framework 4.6 и 4.6.1 во время выполнения выбрасывается исключение ArgumentException, если имена двух событий в трассировке событий Windows отличаются только суффиксами "Start" или "Stop" (например, когда одно событие называется LogUser, а другое — LogUserStart). В этом случае среда выполнения не может создать источник событий, который не может генерировать никаких записей в журнале.

Предложение

Чтобы предотвратить возникновение исключения, убедитесь, что имена событий отличаются не только суффиксами Start или Stop. Это требование снято в .NET Framework 4.6.2 и более поздних версий. Среда выполнения может устранить неоднозначность имен событий, которые отличаются только суффиксами Start и Stop.

Имя. Значение
Область Microsoft Edge
Версия 4,6
Тип Ретаргетинг

Поддержка длинных путей

Сведения

Начиная с приложений, ориентированных на .NET Framework 4.6.2, поддерживаются длинные пути (до 32 тыс. символов), а ограничение длины пути в 260 символов (или MAX_PATH) было удалено. Для приложений, которые перекомпилируются для использования в .NET Framework 4.6.2, кодовые пути, ранее вызывавшие исключение System.IO.PathTooLongException, когда путь превышал 260 символов, теперь будут вызывать исключение System.IO.PathTooLongException только при следующих условиях:

  • длина пути превышает MaxValue (32 767) символов;
  • операционная система возвращает COR_E_PATHTOOLONG или его эквивалент; Для приложений, предназначенных для .NET Framework 4.6.1 и более ранних версий, среда выполнения автоматически создает исключение System.IO.PathTooLongException, когда длина пути превышает 260 символов.

Предложение

Для приложений, предназначенных для .NET Framework 4.6.2, можно отказаться от поддержки длинного пути, добавив следующую строку в раздел <runtime> файла app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

Для приложений, которые предназначены для более ранних версий .NET Framework, но выполняются в .NET Framework 4.6.2 или более поздней версии, можно включить поддержку длинного пути, добавив следующую строку в раздел <runtime> файла app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Имя. Значение
Область Незначительный
Версия 4.6.2
Тип Ретаргетинг

Более строгие проверки двоеточий в пути

Сведения

В .NET Framework 4.6.2 выполнен ряд изменений для поддержки ранее не поддерживаемых путей (по длине и формату). Исправлены проверки правильного синтаксиса разделителя дисков (двоеточие), что привело к побочному эффекту в виде блокировки некоторых URI-путей в нескольких выбранных Path API-интерфейсах, где это ранее допускалось.

Предложение

При передаче универсального кода ресурса (URI) в соответствующий API сначала измените строку, чтобы она содержала допустимый путь.

  • Удалите схему из URL-адресов вручную (например, удалите file:// из URL-адресов).

  • Передайте универсальный код ресурса (URI) в класс Uri и используйте LocalPath.

Кроме того, вы можете отказаться от новой нормализации путей, установив для переключателя Switch.System.IO.UseLegacyPathHandling AppContext значение true.

Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Безопасность

RSACng теперь правильно загружает ключи RSA нестандартного размера

Сведения

В версиях .NET Framework до 4.6.2 клиенты с нестандартным размером ключа для сертификатов RSA не могли получить доступ к этим ключам через методы расширения System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) и System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). Выдается System.Security.Cryptography.CryptographicException с сообщением "Запрошенный размер ключа не поддерживается". В .NET Framework 4.6.2 эта проблема была устранена. Аналогичным образом ImportParameters(RSAParameters) и ImportParameters(RSAParameters) теперь работают с нестандартными размерами ключа, не выбрасывая исключение System.Security.Cryptography.CryptographicException.

Предложение

Если существует логика обработки исключений, которая полагается на предыдущее поведение, когда при использовании ключей нестандартного размера возникало исключение System.Security.Cryptography.CryptographicException, возможно, следует удалить эту логику.

Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

SignedXml.GetPublicKey возвращает RSACng в net462 (или lightup) без изменения целевой среды

Сведения

Начиная с .NET Framework 4.6.2 конкретный тип объекта, возвращаемого методом SignedXml.GetPublicKey, изменен (без особенностей) с реализации CryptoServiceProvider на реализацию Cng. Это связано с изменениями реализации, предусматривающими использование certificate.PublicKey.Key вместо внутреннего certificate.GetAnyPublicKey с переадресацией к RSACertificateExtensions.GetRSAPublicKey.

Предложение

Начиная с приложений, выполняющихся в .NET Framework 4.7.1, вы можете использовать реализацию CryptoServiceProvider, используемую по умолчанию на платформе .NET Framework 4.6.1 и более ранних версий, добавив следующую конфигурацию в раздел runtime файла конфигурации приложения:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Windows Communication Foundation (WCF)

При использовании повторно входящих служб может возникнуть взаимоблокировка

Сведения

В результате взаимоблокировки может возникнуть реентерабельная служба, которая ограничивает выполнение службы одним потоком за раз. Службы, в которых может возникнуть это проблема, имеют следующий ServiceBehaviorAttribute в коде:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Предложение

Чтобы устранить эту проблему, выполните следующие действия:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Установите последнее обновление для .NET Framework 4.6.2 или обновитесь до последней версии платформы .NET Framework. Это приведет к отключению потока ExecutionContext в OperationContext.Current. Это поведение можно настраивать. Это эквивалентно добавлению следующего параметра приложения в файл конфигурации:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Значение Switch.System.ServiceModel.DisableOperationContextAsyncFlow нельзя устанавливать на false для повторно входящих служб.

Имя. Значение
Область Незначительный
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

OperationContext.Current может возвращать значение NULL при вызове в конструкции using

Сведения

OperationContext.Current может возвращать null, и если все следующие условия верны, это может привести к NullReferenceException.

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Предложение

Чтобы устранить эту проблему, выполните следующие действия:

  • Измените ваш код, чтобы создать новый объект, отличный от null и Current.

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Установите последнее обновление для .NET Framework 4.6.2 или обновитесь до последней версии платформы .NET Framework. Это приведет к отключению потока ExecutionContext в OperationContext.Current и восстановлению поведения приложений WCF в .NET Framework 4.6.1 и более ранних версий. Это поведение можно настраивать. Это эквивалентно добавлению следующего параметра приложения в файл конфигурации:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Если это изменение нежелательно и ваше приложение зависит от потока выполнения между контекстами операций, вы можете включить его следующим образом:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Защита транспорта WCF поддерживает сертификаты, сохраненные с помощью CNG

Сведения

Начиная с приложений, предназначенных для .NET Framework 4.6.2, защита транспорта WCF поддерживает сертификаты, сохраненные с использованием библиотеки шифрования Windows (CNG). Эта поддержка ограничивается сертификатами с открытым ключом, длина экспоненты которого не превышает 32 бита. Если приложение предназначено для .NET Framework 4.6.2, эта функция включена по умолчанию. В более ранних версиях платформы .NET Framework попытка использовать сертификаты X509 с поставщиком хранилища ключей CSG вызывала исключение.

Предложение

Для приложений, которые предназначены для .NET Framework 4.6.1 и более ранних версий, но работают в .NET Framework 4.6.2, можно включить поддержку сертификатов CNG, добавив следующую строку в раздел <runtime> файла app.config или web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Это также можно сделать программно с помощью следующего кода:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Обратите внимание, что из-за этого изменения любой код обработки исключений, который зависит от неудачной попытки инициировать защищенное взаимодействие с сертификатом CNG, больше не будет выполняться.

Имя. Значение
Область Незначительный
Версия 4.6.2
Тип Ретаргетинг

Windows Forms

Неправильная реализация MemberDescriptor.Equals

Сведения

Исходная реализация метода MemberDescriptor.Equals сравнивает два разных свойства строки из объектов для сравнения: имя категории и строка описания. Исправление заключается в сравнении Category первого объекта с Category второго объекта, и Description первого объекта с Description второго.

Предложение

Если приложение зависит от того, что MemberDescriptor.Equals иногда возвращает значение false, когда дескрипторы эквивалентны, и вы используете .NET Framework 4.6.2 или более поздней версии, у вас есть несколько вариантов:

  • Изменения в коде для сравнения полей Category и Description вручную в дополнение к вызову метода MemberDescriptor.Equals.
  • Откажитесь от этого изменения, добавив следующее значение в файл app.config:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Если ваше приложение предназначено для .NET Framework 4.6.1 или более ранней версии и выполняется на .NET Framework 4.6.2 или более поздней версии и вы хотите включить это изменение, вы можете указать для переключателя совместимости значение false, добавив следующее значение в файл app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Имя. Значение
Область Microsoft Edge
Версия 4.6.2
Тип Ретаргетинг

Затронутые API

Windows Presentation Foundation (WPF)

CurrentCulture не сохраняется в операциях диспетчера WPF

Сведения

Начиная с версии .NET Framework 4.6, изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture, внесенные в ходе операции System.Windows.Threading.Dispatcher, будут утеряны к моменту завершения этой операции диспетчеризации. Аналогичным образом, изменения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture, внесенные за пределами операции Dispatcher, не будут учитываться при выполнении этой операции. С практической точки зрения это означает, что изменения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture могут не передаваться между обратными вызовами пользовательского интерфейса WPF и другим кодом приложения WPF. Это связано с изменением в System.Threading.ExecutionContext, в результате которого System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture сохраняются в контексте выполнения, начиная с приложений, предназначенных для версии .NET Framework 4.6. Операции диспетчеризации WPF сохраняют контекст выполнения, который используется для запуска операции и восстановления предыдущего контекста при завершении операции. Поскольку System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture теперь являются частью этого контекста, внесенные в рамках операции диспетчеризации изменения не сохраняются вне этой операции.

Предложение

В приложениях, на которые повлияет это изменение, можно обойти данную проблему, сохранив System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в поле и проверив во всех телах операций диспетчера (включая обработчики обратных вызовов событий пользовательского интерфейса), что установлены правильные значения System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture. Кроме того, поскольку изменение ExecutionContext, являющееся базовым для этого изменения WPF, влияет только на приложения, предназначенные для .NET Framework 4.6 или более поздних версий, это нарушение можно исключить путем нацеливания на .NET Framework 4.5.2. В приложениях, ориентированных на платформу .NET Framework 4.6 или более поздней версии, эту проблему можно обойти, установив следующий параметр совместимости:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получат правильное поведение в WPF-приложениях, и System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture будет сохранено в операциях диспетчера.

Имя. Значение
Область Незначительный
Версия 4,6
Тип Ретаргетинг
  • Last updated on