Изменение целевой платформы для миграции с .NET Framework 4.5 на 4.6.1Retargeting Changes for Migration from .NET Framework 4.5 to 4.6.1

Если выполняется миграция с .NET Framework версии 4.5 на 4.6.1, просмотрите следующие разделы о проблемах совместимости приложений, которые могут повлиять на работу приложения:If you are migrating from the .NET Framework 4.5 to 4.6.1, review the following topics for application compatibility issues that may affect your app:

ADO.NETADO.NET

DbParameter.Precision и DbParameter.Scale теперь являются открытыми виртуальными членамиDbParameter.Precision and DbParameter.Scale are now public virtual members

ПодробнееDetails

Precision и Scale реализованы как открытые виртуальные свойства.Precision and Scale are implemented as public virtual properties. Они заменяют соответствующие явные реализации интерфейса: IDbDataParameter.Precision и IDbDataParameter.Scale.They replace the corresponding explicit interface implementations, IDbDataParameter.Precision and IDbDataParameter.Scale.

ПредложениеSuggestion

При повторном создании поставщика базы данных ADO.NET эти различия потребуют применения ключевого слова override к свойствам Precision и Scale.When re-building an ADO.NET database provider, these differences will require the 'override' keyword to be applied to the Precision and Scale properties. Это требуется только в случае повторного создания компонентов; существующие двоичные файлы будут продолжать работать.This is only needed when re-building the components; existing binaries will continue to work.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.5.14.5.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

ASP.NETASP.NET

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

ПодробнееDetails

Начиная с .NET Framework 4.6, при вызове RenderBeginTag(String) и RenderEndTag() с элементом <BR /> правильно вставляется только один <BR /> (вместо двух).Beginning in the .NET Framework 4.6, calling RenderBeginTag(String) and RenderEndTag() with a <BR /> element will correctly insert only one <BR /> (instead of two)

ПредложениеSuggestion

Если приложение зависит от дополнительного тега <BR />, RenderBeginTag(String) следует вызвать второй раз.If an app depended on the extra <BR /> tag, RenderBeginTag(String) should be called a second time. Обратите внимание, что это изменение поведения влияет только на приложения, предназначенные для .NET Framework 4.6 или более поздних версий, поэтому другим вариантом является нацеливание на предыдущую версию платформы .NET Framework для получения старого поведения.Note that this behavior change only affects apps that target the .NET Framework 4.6 or later, so another option is to target a previous version of the .NET Framework in order to get the old behavior.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

ClickOnceClickOnce

Приложения, опубликованные с помощью ClickOnce с использованием сертификата подписи кода SHA-256, могут завершиться ошибкой в Windows 2003Apps published with ClickOnce that use a SHA-256 code-signing certificate may fail on Windows 2003

ПодробнееDetails

Исполняемый файл подписывается с помощью SHA256.The executable is signed with SHA256. Ранее он подписывался с помощью SHA1 независимо от того, какой использовался сертификат подписи кода: SHA-1 или SHA-256.Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. Применение:This applies to:

  • Все приложения, собранные с помощью Visual Studio 2012 или более поздней версии.All applications built with Visual Studio 2012 or later.
  • Приложения, собранные с помощью Visual Studio 2010 или более ранней версии в системах с установленной платформой .NET Framework 4.5.Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present. Кроме того, при наличии .NET Framework 4.5 или более поздней версии манифест ClickOnce также подписывается с помощью SHA-256 для сертификатов SHA-256 независимо от версии .NET Framework, в которой проводилась компиляция.In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.

ПредложениеSuggestion

Изменение подписи исполняемого файла ClickOnce влияет только на системы Windows Server 2003; потребуется установка компонента из статьи базы знаний 938397.The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed. Изменение подписи манифеста с SHA-256, даже если целевая платформа приложения — .NET Framework 4.0 или более ранней версии, вводит зависимость среды выполнения для .NET Framework 4.5 или более поздней версии.The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4.0 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.54.5
TypeType Изменение целевой платформыRetargeting

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

ПодробнееDetails

Раньше приложению ClickOnce с сертификатом, подписанным с SHA-256, требовалась платформа .NET Framework 4.5 или более поздней версии, даже если приложение предназначено для версии 4.0.Previously, a ClickOnce app with a certificate signed with SHA-256 would require .NET Framework 4.5 or later to be present, even if the app targeted 4.0. Теперь приложения ClickOnce, предназначенные для .NET Framework 4.0, можно запускать на .NET Framework 4.0, даже если они подписаны с помощью алгоритма SHA-256.Now, .NET Framework 4.0-targeted ClickOnce apps can run on .NET Framework 4.0, even if signed with SHA-256.

ПредложениеSuggestion

Это изменение удаляет зависимость и позволяет использовать сертификаты SHA-256 для подписи приложений ClickOnce на платформе .NET Framework 4 и более ранних версий.This change removes that dependency and allows SHA-256 certificates to be used to sign ClickOnce apps that target .NET Framework 4 and earlier versions.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

ЯдроCore

Изменение знака разделения пути в свойстве FullName объектов ZipArchiveEntryChange in path separator character in FullName property of ZipArchiveEntry objects

ПодробнееDetails

Для приложений, предназначенных для .NET Framework 4.6.1 и более поздних версий, в качестве знака разделения пути в свойстве FullName объектов ZipArchiveEntry, созданных перегрузками метода CreateFromDirectory, вместо обратной косой черты ("\") используется символ косой черты ("/") .For apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("\") to a forward slash ("/") in the FullName property of ZipArchiveEntry objects created by overloads of the CreateFromDirectory method. Изменение обеспечивает соответствие реализации .NET разделу 4.4.17.1 спецификации формата ZIP-файла и позволяет распаковывать ZIP-архивы в системах, отличных от Windows.The change brings the .NET implementation into conformity with section 4.4.17.1 of the .ZIP File Format Specification and allows .ZIP archives to be decompressed on non-Windows systems.
При распаковке ZIP-файла, созданного приложением, предназначенным для предыдущей версии платформы .NET Framework в операционных системах, отличающихся от Windows, таких как Macintosh, не удается сохранить структуру каталогов.Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. Например, на компьютерах Macintosh создается набор файлов, имя которых объединяет путь к каталогу, вместе со всеми символами обратной косой черты ("\"), и имя файла.For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash ("\") characters, and the filename. В результате структура каталогов распакованных файлов не сохраняется.As a result, the directory structure of decompressed files is not preserved.

ПредложениеSuggestion

Влияние этого изменения на ZIP-файлы, которые распаковываются в операционной системе Windows API-интерфейсами из пространства имен .NET Framework System.IO, должно быть минимальным, так как эти API-интерфейсы без проблем принимают в качестве знака разделения в пути как косую черту ("/"), так и обратную косую черту ("\").The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework System.IO namespace should be minimal, since these APIs can seamlessly handle either a forward slash ("/") or a backslash ("\") as the path separator character.
Если такое изменение нежелательно, от него можно отказаться, добавив параметр конфигурации в раздел <runtime> файла конфигурации приложения.If this change is undesirable, you can opt out of it by adding a configuration setting to the <runtime> section of your application configuration file. В следующем примере показан как раздел <runtime>, так и параметр отключения Switch.System.IO.Compression.ZipFile.UseBackslash:The following example shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-out switch:

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

Кроме того, в приложениях, предназначенных для предыдущих версий .NET Framework, но выполняемых в .NET Framework 4.6.1 и более поздних версий, можно включить такое поведение, добавив параметр конфигурации в раздел <runtime> файла конфигурации приложения.In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the <runtime> section of the application configuration file. Ниже показаны как раздел <runtime>, так и параметр включения функции Switch.System.IO.Compression.ZipFile.UseBackslash.The following shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-in switch.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.6.14.6.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Поток CurrentCulture и CurrentUICulture между задачамиCurrentCulture and CurrentUICulture flow across tasks

ПодробнееDetails

Начиная с .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture хранятся в System.Threading.ExecutionContext потока, который проходит через асинхронные операции. Это означает, что изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture будут отражены в задачах, которые позже выполняются асинхронно.Beginning in the .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are stored in the thread's System.Threading.ExecutionContext, which flows across asynchronous operations.This means that changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture will be reflected in tasks which are later run asynchronously. Это отличается от поведения предыдущих версий .NET Framework (которые во всех асинхронных задачах сбрасывали System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture).This is different from the behavior of previous .NET Framework versions (which would reset System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture in all asynchronous tasks).

ПредложениеSuggestion

Приложения, которых коснулось это изменение, могут обойти его, явно задав System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в качестве первой операции в асинхронной задаче.Apps affected by this change may work around it by explicitly setting the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture as the first operation in an async Task. Кроме того, можно выбрать прежнее поведение (без потока System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) путем установки следующего переключателя совместимости:Alternatively, the old behavior (of not flowing System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) may be opted into by setting the following compatibility switch:

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

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2.This issue has been fixed by WPF in .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549.It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получают правильное поведение в приложениях WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) будет сохранено в операциях диспетчера.Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Имена событий в трассировке событий Windows не должны отличаться друг от друга только суффиксами "Start" или "Stop"ETW event names cannot differ only by a "Start" or "Stop" suffix

ПодробнееDetails

В .NET Framework 4.6 и 4.6.1 среда выполнения вызывает исключение ArgumentException, когда имена двух событий в трассировке событий Windows отличаются только суффиксами Start или Stop (например, когда имя одного события LogUser, а другого — LogUserStart).In the .NET Framework 4.6 and 4.6.1, the runtime throws an ArgumentException when two Event Tracing for Windows (ETW) event names differ only by a "Start" or "Stop" suffix (as when one event is named LogUser and another is named LogUserStart). В этом случае среда выполнения не может определить источник событий и, соответственно, сделать запись в журнале.In this case, the runtime cannot construct the event source, which cannot emit any logging.

ПредложениеSuggestion

Чтобы предотвратить возникновение исключения, убедитесь, что имена событий отличаются не только суффиксами Start или Stop. Это требование снято в .NET Framework 4.6.2 и более поздних версий. Среда выполнения может устранить неоднозначность имен событий, которые отличаются только суффиксами Start и Stop.To prevent the exception, ensure that no two event names differ only by a "Start" or "Stop" suffix.This requirement is removed starting with the .NET Framework 4.6.2; the runtime can disambiguate event names that differ only by the "Start" and "Stop" suffix.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Атрибут ObsoleteAttribute экспортируется как ObsoleteAttribute и DeprecatedAttribute в сценариях WinMDObsoleteAttribute exports as both ObsoleteAttribute and DeprecatedAttribute in WinMD scenarios

ПодробнееDetails

При создании библиотеки метаданных Windows (WINMD-файл) атрибут System.ObsoleteAttribute экспортируется как System.ObsoleteAttribute и Windows.Foundation.DeprecatedAttribute.When you create a Windows Metadata library (.winmd file), the System.ObsoleteAttribute attribute is exported as both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute.

ПредложениеSuggestion

При перекомпиляции существующего исходного кода, использующего атрибут System.ObsoleteAttribute, могут выдаваться предупреждения при использовании кода из C++/CX или JavaScript. Не рекомендуется применять атрибуты System.ObsoleteAttribute и Windows.Foundation.DeprecatedAttribute в коде в управляемых сборках. Это может привести к предупреждениям сборки.Recompilation of existing source code that uses the System.ObsoleteAttribute attribute may generate warnings when consuming that code from C++/CX or JavaScript.We do not recommend applying both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute to code in managed assemblies; it may result in build warnings.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.5.14.5.1
TypeType Изменение целевой платформыRetargeting

JITJIT

Инструкция IL ret недопустима в области tryIL ret not allowed in a try region

ПодробнееDetails

В отличие от JIT-компилятора JIT64, компилятор RyuJIT (в .NET Framework 4.6) не разрешает инструкцию IL ret в области try.Unlike the JIT64 just-in-time compiler, RyuJIT (used in .NET Framework 4.6) does not allow an IL ret instruction in a try region. Возврат из области try запрещен в спецификации ECMA-335, и ни один известный управляемый компилятор не создает такие IL.Returning from a try region is disallowed by the ECMA-335 specification, and no known managed compiler generates such IL. Однако компилятор JIT64 выполнит такие IL, если они созданы с помощью порождения отражения.However, the JIT64 compiler will execute such IL if it is generated using reflection emit.

ПредложениеSuggestion

Если приложение создает IL, который включает в себя код операции ret в области try, это приложение можно нацелить на платформу .NET Framework 4.5, чтобы использовать старый JIT-компилятор и избежать этой проблемы.If an app is generating IL that includes a ret opcode in a try region, the app may target .NET Framework 4.5 to use the old JIT and avoid this break. Кроме того, создаваемый IL-код можно обновить, чтобы он возвращался после области try.Alternatively, the generated IL may be updated to return after the try region.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

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

ПодробнееDetails

Начиная с .NET Framework 4.6, для JIT-компиляции используется новый 64-разрядный компилятор JIT.Starting with the .NET Framework 4.6, a new 64-bit JIT compiler is used for just-in-time compilation. В некоторых случаях вызывается непредвиденное исключение или наблюдается другое поведение, отличное от поведения при выполнении приложения с использованием 32-разрядного компилятора или старого 64-разрядного JIT-компилятора.In some cases, an unexpected exception is thrown or a different behavior is observed than if an app is run using the 32-bit compiler or the older 64-bit JIT compiler. Это изменение не влияет на 32-разрядный компилятор JIT.This change does not affect the 32-bit JIT compiler. Известные различия включают в себя следующее.The known differences include the following:

  • При определенных условиях операция распаковки может вызывать исключение NullReferenceException в сборках выпусков с включенной оптимизацией.Under certain conditions, an unboxing operation may throw a NullReferenceException in Release builds with optimization turned on.
  • В некоторых случаях выполнение рабочего кода в большом теле метода может вызывать исключение StackOverflowException.In some cases, execution of production code in a large method body may throw a StackOverflowException.
  • При определенных условиях в сборках выпусков передаваемые методу структуры обрабатываются как ссылочные типы, а не типы значений.Under certain conditions, structures passed to a method are treated as reference types rather than as value types in Release builds. Одним из проявлений этой проблемы является отображение отдельных элементов коллекции в непредвиденном порядке.One of the manifestations of this issue is that the individual items in a collection appear in an unexpected order.
  • При определенных условиях сравнение значений UInt16 с установленным старшим битом выполняется неверно, если включена оптимизация.Under certain conditions, the comparison of UInt16 values with their high bit set is incorrect if optimization is enabled.
  • При определенных условиях, особенно при инициализации значений массивов, инициализация памяти инструкцией OpCodes.Initblk IL может инициализировать память неправильным значением.Under certain conditions, particularly when initializing array values, memory initialization by the OpCodes.Initblk IL instruction may initialize memory with an incorrect value. Это может привести либо к необработанному исключению, либо к неправильным выходным данным.This can result either in an unhandled exception or incorrect output.
  • В некоторых редких случаях условная поразрядная проверка может возвращать неверное значение типа Boolean или вызывать исключение, если включены оптимизации компилятора.Under certain rare conditions, a conditional bit test can return the incorrect Boolean value or throw an exception if compiler optimizations are enabled.
  • При определенных условиях, если инструкция if используется для проверки условия перед входом в блок try и на выходе из блока try, и такое же условие вычисляется в блоке catch или finally, новый 64-разрядный JIT-компилятор удаляет условие if из блока catch или finally при оптимизации кода.Under certain conditions, if an if statement is used to test for a condition before entering a try block and in the exit from the try block, and the same condition is evaluated in the catch or finally block, the new 64-bit JIT compiler removes the if condition from the catch or finally block when it optimizes code. В результате код внутри инструкции if в блоке catch или finally выполняется безусловно.As a result, code inside the if statement in the catch or finally block is executed unconditionally.

ПредложениеSuggestion

Устранение известных проблемMitigation of known issues
При возникновении перечисленных выше проблем их можно решить, выполнив одно из следующих действий.If you encounter the issues listed above, you can address them by doing any of the following:

  • Обновление до .NET Framework 4.6.2.Upgrade to the .NET Framework 4.6.2. Новый 64-разрядный компилятор, входящий в состав .NET Framework 4.6.2, устраняет все эти известные проблемы.The new 64-bit compiler included with the .NET Framework 4.6.2 addresses each of these known issues.

  • Обновление Windows до актуального состояния при запуске Центра обновления Windows.Ensure that your version of Windows is up to date by running Windows Update. Обновления служб до .NET Framework 4.6 и 4.6.1 решают все эти проблемы, кроме исключения NullReferenceException при распаковке-преобразовании.Service updates to the .NET Framework 4.6 and 4.6.1 address each of these issues except the NullReferenceException in an unboxing operation.

  • Компиляция с помощью старого 64-разрядного JIT-компилятора.Compile with the older 64-bit JIT compiler. Дополнительные сведения о том, как это сделать, см. в разделе Устранение других проблем.See the Mitigation of other issues section for more information on how to do this. Устранение других проблемMitigation of other issues
    При возникновении любых других различий в поведении между кодом, скомпилированным с помощью старого и нового 64-разрядных JIT-компиляторов, или между отладочной и окончательной версиями приложения, которые обе скомпилированы новым 64-разрядным JIT-компилятором, можно выполнить следующие действия для компиляции приложения с помощью старого 64-разрядного JIT-компилятора.If you encounter any other difference in behavior between code compiled with the older 64-bit compiler and the new 64-bit JIT compiler, or between the debug and release versions of your app that are both compiled with the new 64-bit JIT compiler, you can do the following to compile your app with the older 64-bit JIT compiler:

  • Для каждого отдельного приложения можно добавить элемент < в файл конфигурации приложения.On a per-application basis, you can add the < element to your application's configuration file. Следующее действие отключает компиляцию с помощью нового 64-разрядного JIT-компилятора и вместо этого использует устаревший 64-разрядный JIT-компилятор.The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit JIT compiler.

    <?xml version ="1.0"?>
    <configuration>
      <runtime>
       <useLegacyJit enabled="1" />
      </runtime>
    </configuration>
    
  • Для каждого отдельного пользователя можно добавить значение REG_DWORD с именем useLegacyJit в раздел реестра HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework.On a per-user basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework key of the registry. Значение 1 включает устаревший 64-разрядный JIT-компилятор; значение 0 отключает его и включает новый 64-разрядный JIT-компилятор.A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler.

  • Для каждого отдельного компьютера можно добавить значение REG_DWORD с именем useLegacyJit в раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework.On a per-machine basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework key of the registry. Значение 1 включает устаревший 64-разрядный JIT-компилятор; значение 0 отключает его и включает новый 64-разрядный JIT-компилятор.A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler. Можно также сообщить нам об обнаруженной проблеме, обратившись в службу Microsoft Connect.You can also let us know about the problem by reporting a bug on Microsoft Connect.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

MSBuildMSBuild

Задача ResolveAssemblyReference теперь предупреждает о зависимостях с неправильной архитектуройResolveAssemblyReference task now warns of dependencies with the wrong architecture

ПодробнееDetails

Задача выдает предупреждение (MSB3270), которое означает, что ссылка или ее зависимости не соответствуют архитектуре приложения.The task emits a warning, MSB3270, which indicates that a reference or any of its dependencies does not match the app's architecture. Например, это происходит, если приложение, скомпилированное с параметром AnyCPU, содержит 32-разрядную ссылку.For example, this occurs if an app that was compiled with the AnyCPU option includes an x86 reference. Такой сценарий может привести к сбою приложения во время выполнения (в этом случае: если приложение развертывается как 64-разрядный процесс).Such a scenario could result in an app failure at run time (in this case, if the app is deployed as an x64 process).

ПредложениеSuggestion

Существует две области влияния.There are two areas of impact:

  • Во время перекомпиляции выдаются предупреждения, которые отсутствовали при компиляции в предыдущей версии MSBuild.Recompilation generates warnings that did not appear when the app was compiled under a previous version of MSBuild. Однако поскольку в предупреждении указан возможный источник ошибки среды выполнения, его следует проверить.However, because the warning identifies a possible source of runtime failure, it should be investigated and addressed.
  • Если предупреждения считаются ошибками, приложение скомпилировано не будет.If warnings are treated as errors, the app will fail to compile.
nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.5.14.5.1
TypeType Изменение целевой платформыRetargeting

СетиNetworking

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

ПодробнееDetails

Начиная с .NET Framework 4.6 классы SslStream или ServicePointManager выполняют проверку идентификатора объекта (OID) расширенного использования ключа (EKU).Starting with .NET Framework 4.6, the SslStream or ServicePointManager classes perform enhanced key use (EKU) object identifier (OID) validation. Расширение расширенного использования ключа (EKU) — это коллекция идентификаторов объекта (OID), которые указывают приложения, использующие ключ.An enhanced key usage (EKU) extension is a collection of object identifiers (OIDs) that indicate the applications that use the key. При проверке OID EKU используются обратные вызовы удаленного сертификата, чтобы у удаленного сертификата были правильные OID для указанных целей.EKU OID validation uses remote certificate callbacks to ensure that the remote certificate has the correct OIDs for the intended purpose.

ПредложениеSuggestion

Если это изменение нежелательно, можно отключить проверку OID EKU сертификата, добавив следующий параметр к <AppContextSwitchOverrides> в ` в файле конфигурации приложения:If this change is undesirable, you can disable certificate EKU OID validation by adding the following switch to the <AppContextSwitchOverrides> in the ` of your app configuration file:

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

Важно!

Этот параметр предоставляется исключительно для обратной совместимости.This setting is provided for backward compatibility only. Его использование в других целях не рекомендуется.Its use is otherwise not recommended.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

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

ПодробнееDetails

Начиная с версии .NET Framework 4.6, классы ServicePointManager и SslStream могут использовать только один из трех протоколов: Tls1.0, Tls1.1 или Tls1.2.Starting with the .NET Framework 4.6, the ServicePointManager and SslStream classes are only allowed to use one of the following three protocols: Tls1.0, Tls1.1, or Tls1.2. Протокол SSL 3.0 и шифрование RC4 не поддерживаются.The SSL3.0 protocol and RC4 cipher are not supported.

ПредложениеSuggestion

Рекомендуется обновить приложения на стороне сервера для использования Tls1.0, Tls1.1 или Tls1.2.The recommended mitigation is to upgrade the sever-side app to Tls1.0, Tls1.1, or Tls1.2. Если это невозможно, или если клиентские приложения не работают, можно использовать класс System.AppContext, чтобы отказаться от этой функции одним из двух способов.If this is not feasible, or if client apps are broken, the System.AppContext class can be used to opt out of this feature in either of two ways:

  • Путем программной установки параметров совместимости в System.AppContext, как описано здесь.By programmatically setting compat switches on the System.AppContext, as explained here.
  • путем добавления следующей строки в раздел <runtime> файла app.config:By adding the following line to the <runtime> section of the app.config file:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

TLS 1.x по умолчанию передает флаг SCH_SEND_AUX_RECORD базовому API SCHANNELTLS 1.x by default passes the SCH_SEND_AUX_RECORD flag to the underlying SCHANNEL API

ПодробнееDetails

При использовании TLS 1.x .NET Framework зависит от базового интерфейса API Windows SCHANNEL.When using TLS 1.x, the .NET Framework relies on the underlying Windows SCHANNEL API. Начиная с .NET Framework 4.6 флаг SCH_SEND_AUX_RECORD передается SCHANNEL по умолчанию.Starting with .NET Framework 4.6, the SCH_SEND_AUX_RECORD flag is passed by default to SCHANNEL. В результате SCHANNEL разбивает данные для шифрования на две отдельных записи. В первой — один байт, а во второй — n–1 байт. В редких случаях это нарушает логику взаимодействия между клиентами и существующими серверами, которая предполагает, что данные находятся в одной записи.This causes SCHANNEL to split data to be encrypted into two separate records, the first as a single byte and the second as n-1 bytes.In rare cases, this breaks communication between clients and existing servers that make the assumption that the data resides in a single record.

ПредложениеSuggestion

Если это изменение нарушает связь с существующим сервером, вы можете отключить отправку флага SCH_SEND_AUX_RECORD и восстановить предыдущее поведение, при котором данные не разделяются на две записи, добавив следующий переключатель в элемент <AppContextSwitchOverrides> в разделе <runtime> файла конфигурации приложения:If this change breaks communication with an existing server, you can disable sending the SCH_SEND_AUX_RECORD flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the <AppContextSwitchOverrides> element in the <runtime> section of your app configuration file:

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

Важно!

Этот параметр предоставляется исключительно для обратной совместимости.This setting is provided for backward compatibility only. Его использование в других целях не рекомендуется.Its use is otherwise not recommended.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Visual Basic .NETVisual Basic .NET

VB.NET больше не поддерживает частичные квалификации пространства имен для API-интерфейсов System.WindowsVB.NET no longer supports partial namespace qualification for System.Windows APIs

ПодробнееDetails

Начиная с .NET Framework 4.5.2 в проектах VB.NET невозможно задать API-интерфейсы System.Windows с частично указанными пространствами имен.Beginning in .NET Framework 4.5.2, VB.NET projects cannot specify System.Windows APIs with partially-qualified namespaces. Например, ссылка на Windows.Forms.DialogResult завершится ошибкой.For example, referring to Windows.Forms.DialogResult will fail. Вместо этого код должен ссылаться на полное доменное имя (DialogResult) или импортировать конкретное пространство имен и сослаться просто на System.Windows.Forms.DialogResult.Instead, code must refer to the fully qualified name (DialogResult) or import the specific namespace and refer simply to System.Windows.Forms.DialogResult.

ПредложениеSuggestion

Следует обновить код для ссылки на API System.Windows либо с простыми именами (и импортом соответствующего пространства имен), либо с полными доменными именами.Code should be updated to refer to System.Windows APIs either with simple names (and importing the relevant namespace) or with fully qualified names.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.5.24.5.2
TypeType Изменение целевой платформыRetargeting

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

Был изменен вызов метода CreateDefaultAuthorizationContext с аргументом NULLCalling CreateDefaultAuthorizationContext with a null argument has changed

ПодробнееDetails

В .NET Framework 4.6 изменилась реализация System.IdentityModel.Policy.AuthorizationContext, возвращаемая вызовом к System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) с нулевым аргументом authorizationPolicies.The implementation of the System.IdentityModel.Policy.AuthorizationContext returned by a call to the System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) with a null authorizationPolicies argument has changed its implementation in the .NET Framework 4.6.

ПредложениеSuggestion

В редких случаях в приложениях WCF, которые используют настраиваемую проверку подлинности, могут возникать различия в поведении.In rare cases, WCF apps that use custom authentication may see behavioral differences. В таких случаях прежнее поведение можно восстановить двумя способами.In such cases, the previous behavior can be restored in either of two ways:

  • Перекомпилируйте приложение для ориентации на версию .NET Framework, предшествующую 4.6.Recompile your app to target an earlier version of the .NET Framework than 4.6. Для служб, размещенных в IIS, используйте элемент <httpRuntime targetFramework="x.x"> для выбора более ранней версии .NET Framework в качестве целевой платформы.For IIS-hosted services, use the <httpRuntime targetFramework="x.x"> element to target an earlier version of the .NET Framework.

  • Добавьте следующую строку в раздел <appSettings> файла app.config.Add the following line to the <appSettings> section of your app.config file:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
    
nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Привязка WCF с режимом безопасности TransportWithMessageCredentialWCF binding with the TransportWithMessageCredential security mode

ПодробнееDetails

Начиная с .NET Framework 4.6.1 привязку WCF, которая использует режим безопасности TransportWithMessageCredential, можно настроить для получения сообщений с неподписанными заголовками "to" для асимметричных ключей безопасности. По умолчанию неподписанные заголовки "to" будут отклоняться в .NET Framework 4.6.1.Beginning in the .NET Framework 4.6.1, WCF binding that uses the TransportWithMessageCredential security mode can be set up to receive messages with unsigned "to" headers for asymmetric security keys.By default, unsigned "to" headers will continue to be rejected in .NET Framework 4.6.1. Они будут приниматься только в случае перевода приложения на новый режим с помощью переключателя конфигурации Switch.System.ServiceModel.AllowUnsignedToHeader.They will only be accepted if an application opts into this new mode of operation using the Switch.System.ServiceModel.AllowUnsignedToHeader configuration switch.

ПредложениеSuggestion

Поскольку это возможность, включаемая пользователем, она не должна влиять на поведение существующих приложений.Because this is an opt-in feature, it should not affect the behavior of existing apps.
Для включения или отключения нового поведения используйте следующий параметр конфигурации:To control whether the new behavior is used or not, use the following configuration setting:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
nameName ЗначениеValue
ОбластьScope ПрозрачныйTransparent
VersionVersion 4.6.14.6.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

X509CertificateClaimSet.FindClaims учитывает все аргументы claimTypeX509CertificateClaimSet.FindClaims Considers All claimTypes

ПодробнееDetails

Если в приложениях, предназначенных для .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.In apps that target the .NET Framework 4.6.1, if an X509 claim set is initialized from a certificate that has multiple DNS entries in its SAN field, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument with all the DNS entries.For apps that target previous versions of the .NET Framework, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument only with the last DNS entry.

ПредложениеSuggestion

Это изменение затрагивает только приложения, предназначенные для .NET Framework 4.6.1.This change only affects applications targeting the .NET Framework 4.6.1. Это изменение можно отключить (или включить, если используются версии, предшествующие 4.6.1) с помощью параметра совместимости DisableMultipleDNSEntries.This change may be disabled (or enabled if targeting pre-4.6.1) with the DisableMultipleDNSEntries compatibility switch.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.6.14.6.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Windows FormsWindows Forms

Application.FilterMessage больше не создает исключение для реализаций IMessageFilter.PreFilterMessage с повторным входомApplication.FilterMessage no longer throws for re-entrant implementations of IMessageFilter.PreFilterMessage

ПодробнееDetails

До версии .NET Framework 4.6.1 при вызове FilterMessage(Message) с PreFilterMessage(Message), вызывающим System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) или System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (с одновременным вызовом DoEvents()), возникало исключение System.IndexOutOfRangeException.Prior to the .NET Framework 4.6.1, calling FilterMessage(Message) with an PreFilterMessage(Message) which called System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) or System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (while also calling DoEvents()) would cause an System.IndexOutOfRangeException.

Начиная с приложений, предназначенных для .NET Framework 4.6.1, это исключение больше не создается, и можно использовать фильтры с повторным входом, как описано выше.Beginning with applications targeting the .NET Framework 4.6.1, this exception is no longer thrown, and re-entrant filters as described above may be used.

ПредложениеSuggestion

Имейте в виду, что FilterMessage(Message) больше не вызывает исключение для поведения PreFilterMessage(Message) с повторным входом, как описано выше.Be aware that FilterMessage(Message) will no longer throw for the re-entrant PreFilterMessage(Message) behavior described above. Будут затронуты только приложения, предназначенные для .NET Framework 4.6.1. В приложениях, предназначенных для .NET Framework 4.6.1, можно отказаться от этого изменения (или в приложениях, предназначенных для более старых платформ, можно использовать изменение) с помощью параметра совместимости DontSupportReentrantFilterMessage.This only affects applications targeting the .NET Framework 4.6.1.Apps targeting the .NET Framework 4.6.1 can opt out of this change (or apps targeting older Frameworks may opt in) by using the DontSupportReentrantFilterMessage compatibility switch.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.6.14.6.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

DataObject.GetData теперь получает данные в кодировке UTF-8DataObject.GetData now retrieves data as UTF-8

ПодробнееDetails

В приложениях, предназначенных для .NET Framework 4 или выполняющихся в .NET Framework 4.5.1 или более ранних версий, DataObject.GetData получает HTML-данные в виде строки ASCII.For apps that target the .NET Framework 4 or that run on the .NET Framework 4.5.1 or earlier versions, DataObject.GetData retrieves HTML-formatted data as an ASCII string. В результате символы, не относящиеся к ASCII (т. е. символы с кодами ASCII больше 0x7F), представляются двумя случайными символами.As a result, non-ASCII characters (characters whose ASCII codes are greater than 0x7F) are represented by two random characters.

Для приложений, предназначенных для NET Framework 4.5 и более поздней версии и выполняемых в .NET Framework 4.5.2, DataObject.GetData получает HTML-данные в формате UTF-8, который правильно представляет символы с кодами более 0x7F.For apps that target the .NET Framework 4.5 or later and run on the .NET Framework 4.5.2, DataObject.GetData retrieves HTML-formatted data as UTF-8, which represents characters greater than 0x7F correctly.

ПредложениеSuggestion

Если реализован обходной путь для проблемы с кодировкой HTML-строк (например, явная кодировка HTML-строки, полученной из буфера обмена, путем ее передачи в метод System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)), и выполняется изменение целевой платформы приложения с версии 4 на версию 4.5, этот обходной путь необходимо удалить. Если по какой-либо причине требуется старое поведение, для приложения можно выбрать целевую платформу .NET Framework 4.0.If you implemented a workaround for the encoding problem with HTML-formatted strings (for example, by explicitly encoding the HTML string retrieved from the Clipboard by passing it to System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) and you're retargeting your app from version 4 to 4.5, that workaround should be removed.If the old behavior is needed for some reason, the app can target the .NET Framework 4.0 to get that behavior.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.5.24.5.2
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Icon.ToBitmap успешно преобразует значки с кадрами PNG в растровые изображенияIcon.ToBitmap successfully converts icons with PNG frames into Bitmap objects

ПодробнееDetails

Начиная с приложений, предназначенных для .NET Framework 4.6, метод Icon.ToBitmap успешно преобразует значки с кадрами PNG в объекты Bitmap.Starting with the apps that target the .NET Framework 4.6, the Icon.ToBitmap method successfully converts icons with PNG frames into Bitmap objects.

В приложениях, предназначенных для .NET Framework 4.5.2 и более ранних версий, метод Icon.ToBitmap создает исключение ArgumentOutOfRangeException, если объект Icon содержит кадры PNG.In apps that target the .NET Framework 4.5.2 and earlier versions, the Icon.ToBitmap method throws an ArgumentOutOfRangeException exception if the Icon object has PNG frames.

Это изменение затрагивает приложения, которые компилируются повторно для платформы .NET Framework 4.6 и в которых реализуется специальная обработка исключения ArgumentOutOfRangeException, создаваемого при наличии кадров PNG в объекте Icon .This change affects apps that are recompiled to target the .NET Framework 4.6 and that implement special handling for the ArgumentOutOfRangeException that is thrown when an Icon object has PNG frames. При выполнении в .NET Framework 4.6 преобразование проходит успешно, исключение ArgumentOutOfRangeException больше не создается, и поэтому обработчик исключений больше не вызывается.When running under the .NET Framework 4.6, the conversion is successful, an ArgumentOutOfRangeException is no longer thrown, and therefore the exception handler is no longer invoked.

ПредложениеSuggestion

Если такое поведение нежелательно, можно сохранить прежнее поведение, добавив в раздел <runtime> файла app.config следующий элемент:If this behavior is undesirable, you can retain the previous behavior by adding the following element to the <runtime> section of your app.config file:

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

Если файл app.config уже содержит элемент AppContextSwitchOverrides, новое значение следует объединить с атрибутом значения следующим образом:If the app.config file already contains the AppContextSwitchOverrides element, the new value should be merged with the value attribute like this:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

Вызовы System.Windows.Input.PenContext.Disable в системах с поддержкой сенсорного ввода могут вызвать исключение ArgumentExceptionCalls to System.Windows.Input.PenContext.Disable on touch-enabled systems may throw an ArgumentException

ПодробнееDetails

В некоторых случаях вызовы внутреннего метода System.Windows.Intput.PenContext.Disable в системах с поддержкой сенсорного ввода могут вызывать необработанное исключение T:System.ArgumentException из-за повторного входа.Under some circumstances, calls to the internal System.Windows.Intput.PenContext.Disable method on touch-enabled systems may throw an unhandled T:System.ArgumentException because of reentrancy.

ПредложениеSuggestion

Эта проблема была устранена в .NET Framework 4.7.This issue has been addressed in the .NET Framework 4.7. Чтобы это исключение не возникало, выполните обновление до версии платформы .NET Framework 4.7 или более поздней.To prevent the exception, upgrade to a version of the .NET Framework starting with the .NET Framework 4.7.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.6.14.6.1
TypeType Изменение целевой платформыRetargeting

CurrentCulture не сохраняется в операциях диспетчера WPFCurrentCulture is not preserved across WPF Dispatcher operations

ПодробнееDetails

Начиная с версии .NET Framework 4.6, изменения System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture, внесенные в операции System.Windows.Threading.Dispatcher, будут утеряны в конце операции диспетчеризации.Beginning in the .NET Framework 4.6, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made within a System.Windows.Threading.Dispatcher will be lost at the end of that dispatcher operation. Аналогичным образом, изменения 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.Similarly, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made outside of a Dispatcher operation may not be reflected when that operation executes.Practically speaking, this means that System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture changes may not flow between WPF UI callbacks and other code in a WPF application.This is due to a change in System.Threading.ExecutionContext that causes System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture to be stored in the execution context beginning with apps targeting the .NET Framework 4.6. Операции диспетчеризации WPF сохраняют контекст выполнения, который используется для запуска операции и восстановления предыдущего контекста при завершении операции.WPF dispatcher operations store the execution context used to begin the operation and restore the previous context when the operation is completed. Поскольку System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture теперь являются частью этого контекста, внесенные в рамках операции диспетчеризации изменения не сохраняются вне этой операции.Because System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are now part of that context, changes to them within a dispatcher operation are not persisted outside of the operation.

ПредложениеSuggestion

В приложениях, затронутых данным изменением, можно обойти эту проблему, сохранив System.Globalization.CultureInfo.CurrentCulture или System.Globalization.CultureInfo.CurrentUICulture в поле и проверив все тексты операций диспетчеризации (включая обработчики обратного вызова событий пользовательского интерфейса) на установку правильных значений System.Globalization.CultureInfo.CurrentCulture и System.Globalization.CultureInfo.CurrentUICulture.Apps affected by this change may work around it by storing the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture in a field and checking in all Dispatcher operation bodies (including UI event callback handlers) that the correct System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are set. Кроме того, поскольку изменение ExecutionContext, являющееся базовым для этого изменения WPF, влияет только на приложения, предназначенные для .NET Framework 4.6 или более поздних версий, это нарушение можно исключить путем нацеливания на .NET Framework 4.5.2. В приложениях, ориентированных на платформу .NET Framework 4.6 или более поздней версии, эту проблему можно обойти, установив следующий параметр совместимости:Alternatively, because the ExecutionContext change underlying this WPF change only affects apps targeting the .NET Framework 4.6 or newer, this break can be avoided by targeting the .NET Framework 4.5.2.Apps that target .NET Framework 4.6 or later can also work around this by setting the following compatibility switch:

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

Эта проблема была устранена с помощью WPF в .NET Framework 4.6.2.This issue has been fixed by WPF in .NET Framework 4.6.2. Она также была устранена в .NET Framework версий 4.6 и 4.6.1 посредством KB 3139549.It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. Приложения, предназначенные для .NET Framework 4.6 или более поздней версии, автоматически получают правильное поведение в приложениях WPF — System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) будет сохранено в операциях диспетчера.Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Двусторонняя привязка данных к свойству с не предназначенным для общего доступа методом задания не поддерживаетсяTwo-way data-binding to a property with a non-public setter is not supported

ПодробнееDetails

Попытка привязки данных к свойству без общедоступного метода задания никогда не поддерживалась.Attempting to data bind to a property without a public setter has never been a supported scenario. Начиная с .NET Framework 4.5.1 этот сценарий выдает исключение System.InvalidOperationException.Beginning in the .NET Framework 4.5.1, this scenario will throw an System.InvalidOperationException. Обратите внимание, что это новое исключение создается только для приложений, которые предназначены специально для .NET Framework 4.5.1.Note that this new exception will only be thrown for apps that specifically target the .NET Framework 4.5.1. Если приложение предназначено для .NET Framework 4.5, вызов будет разрешен.If an app targets the .NET Framework 4.5, the call will be allowed. Если приложение не предназначено для определенной версии .NET Framework, привязка будет рассматриваться как односторонняя.If the app does not target a particular .NET Framework version, the binding will be treated as one-way.

ПредложениеSuggestion

Приложение следует обновить либо для использования односторонней привязки, либо для предоставления общего доступа к методу задания свойства.The app should be updated to either use one-way binding, or expose the property's setter publicly. Кроме того, выбор .NET Framework 4.5 в качестве целевой платформы приведет к восстановлению старого поведения приложения.Alternatively, targeting the .NET Framework 4.5 will cause the app to exhibit the old behavior.

nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.5.14.5.1
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Изменились параметры округления полей макета WPFWPF layout rounding of margins has changed

ПодробнееDetails

Способ округления полей, а также их границ и фона, изменен.The way in which margins are rounded and borders and the background inside of them has changed. В результате этого изменения:As a result of this change:

  • ширина или высота элементов может увеличиться или уменьшиться максимум на один пиксель;The width or height of elements may grow or shrink by at most one pixel.
  • расположение объекта может измениться максимум на один пиксель;The placement of an object can move by at most one pixel.
  • выровненные по центру элементы могут сместиться по вертикали или горизонтали максимум на один пиксель.Centered elements can be vertically or horizontally off center by at most one pixel. По умолчанию новый макет включен только для приложений, предназначенных для .NET Framework 4.6.By default, this new layout is enabled only for apps that target the .NET Framework 4.6.

ПредложениеSuggestion

Поскольку это изменение, как правило, приводит к устранению обрезки правых или нижних элементов управления WPF при высоком разрешении, для приложений, предназначенных для более ранних версий .NET Framework, но выполняющихся в .NET Framework 4.6, можно выбрать это новое поведение, добавив следующую строку в раздел <runtime> файла app.config.Since this modification tends to eliminate clipping of the right or bottom of WPF controls at high DPIs, apps that target earlier versions of the .NET Framework but are running on the .NET Framework 4.6 can opt into this new behavior by adding the following line to the <runtime> section of the app.config file:

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

Для приложений, предназначенных для .NET Framework 4.6, в которых требуется задать отрисовку элементов управления WPF с помощью прежнего алгоритма макета, можно добавить следующую строку в раздел <runtime> файла app.config:Apps that target the .NET Framework 4.6 but want WPF controls to render using the previous layout algorithm can do so by adding the following line to the <runtime> section of the app.config file:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />'.
nameName ЗначениеValue
ОбластьScope Дополнительный номерMinor
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

WorkflowDesigner.Load не удаляет свойство символаWorkflowDesigner.Load doesn't remove symbol property

ПодробнееDetails

При выборе целевой версии платформы .NET Framework 4.5 в конструкторе рабочих процессов и загрузке повторно размещаемого рабочего процесса 3.5 с помощью метода Load() во время сохранения рабочего процесса создается исключение System.Xaml.XamlDuplicateMemberException.When targeting the .NET Framework 4.5 in the workflow designer, and loading a re-hosted 3.5 workflow with the Load() method, a System.Xaml.XamlDuplicateMemberException is thrown while saving the workflow.

ПредложениеSuggestion

Эта ошибка возникает только при нацеливании на .NET Framework 4.5 в конструкторе рабочих процессов, поэтому ее можно устранить, установив WorkflowDesigner.Context.Services.GetService&lt;DesignerConfigurationService&gt;().TargetFrameworkName в 4.0 .NET Framework. Этой проблемы можно избежать, если использовать метод Load(String) для загрузки рабочего процесса вместо Load().This bug only manifests when targeting .NET Framework 4.5 in the workflow designer, so it can be worked around by setting the WorkflowDesigner.Context.Services.GetService&lt;DesignerConfigurationService&gt;().TargetFrameworkName to the 4.0 .NET Framework.Alternatively, the issue may be avoided by using the Load(String) method to load the workflow, instead of Load().

nameName ЗначениеValue
ОбластьScope ЗначительноMajor
VersionVersion 4.54.5
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

XML, XSLTXML, XSLT

XmlWriter вызывает недействительные суррогатные парыXmlWriter throws on invalid surrogate pairs

ПодробнееDetails

Для приложений с целевой платформой .NET Framework 4.5.2 или предыдущих версий запись недействительной суррогатной пары с помощью обработки резервного исключения не всегда вызывает исключение.For apps that target the .NET Framework 4.5.2 or previous versions, writing an invalid surrogate pair using exception fallback handling does not always throw an exception. Для приложений с целевой платформой .NET Framework 4.6 попытка записи недействительной суррогатной пары вызывает исключение System.ArgumentException.For apps that target the .NET Framework 4.6, attempting to write an invalid surrogate pair throws an System.ArgumentException.

ПредложениеSuggestion

При необходимости этого прерывания можно избежать, выбрав в качестве целевой платформы .NET Framework 4.5.2 или более ранней версии.If necessary, this break can be avoided by targeting the .NET Framework 4.5.2 or earlier. Кроме того, до записи недействительных суррогатных пар можно предварительно обработать их и преобразовать в допустимый xml.Alternatively, invalid surrogate pairs can be pre-processed into valid xml prior to writing them.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting

Затронутые APIAffected APIs

Проверка схемы XSD теперь правильно обнаруживает нарушения уникальных ограничений, если используются составные ключи и один ключ пустXSD Schema validation now correctly detects violations of unique constraints if compound keys are used and one key is empty

ПодробнееDetails

В версиях платформы .NET Framework, предшествовавших версии 4.6, была ошибка, из-за которой проверка XSD не могла обнаруживать уникальные ограничения по составным ключам, если один из ключей был пуст.Versions of the .NET Framework prior to 4.6 had a bug that caused XSD validation to not detect unique constraints on compound keys if one of the keys was empty. Эта проблема решена в .NET Framework 4.6.In the .NET Framework 4.6, this issue is corrected. Это приведет к выполнению более правильной проверки, но также может привести к невозможности проверки некоторого XML-кода, которая осуществлялась раньше.This will result in more correct validation, but it may also result in some XML not validating which previously would have.

ПредложениеSuggestion

Если требуется менее строгая проверка .NET Framework 4.0, проверяющее приложение может быть предназначено для версии 4.5 (или более ранней) платформы .NET Framework.If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.5 (or earlier) of the .NET Framework. Однако при изменении целевой платформы на .NET Framework 4.6 следует выполнить проверку кода, чтобы не проверять повторяющиеся составные ключи (как указано в описании этой проблемы).When retargeting to .NET Framework 4.6, however, code review should be done to be sure that duplicate compound keys (as described in this issue's description) are not expected to validate.

nameName ЗначениеValue
ОбластьScope Пограничный случайEdge
VersionVersion 4.64.6
TypeType Изменение целевой платформыRetargeting