Azure Data Lake Analytics обновляется до .NET Framework v4.7.2

Среда выполнения Azure Data Lake Analytics по умолчанию обновляется с .NET Framework v4.5.2 до .NET Framework v4.7.2. Это изменение представляет небольшой риск поломки изменений, если ваш код U-SQL использует пользовательские сборки, а эти пользовательские сборки используют библиотеки .NET.

Это обновление .NET Framework 4.5.2 до версии 4.7.2 означает, что .NET Framework, развернутый в среде выполнения U-SQL (среда выполнения по умолчанию), теперь всегда будет 4.7.2. Для версий .NET Framework нет возможности параллельной работы.

После завершения этого обновления до .NET Framework 4.7.2 управляемый код системы будет работать как версия 4.7.2, а пользовательские библиотеки, такие как пользовательские сборки U-SQL, будут работать в режиме обратной совместимости, подходящем для версии, которую сборка создана для.

• Если ваши сборочные библиотеки DLL созданы для версии 4.5.2, развернутый фреймворк будет рассматривать их как библиотеки 4.5.2, обеспечивая (за некоторыми исключениями) семантику 4.5.2.
• Теперь вы можете использовать настраиваемые сборки U-SQL, которые используют функции версии 4.7.2, если вы нацеливаетесь на .NET Framework 4.7.2.

Из-за этого обновления до .NET Framework 4.7.2 существует возможность внести критические изменения в ваши задания U-SQL, использующие пользовательские сборки .NET. Мы предлагаем вам проверить наличие проблем с обратной совместимостью, используя описанную ниже процедуру.

Как проверить наличие проблем с обратной совместимостью

Проверьте наличие потенциальных проблем с нарушением обратной совместимости, выполнив проверки совместимости .NET для вашего кода .NET в пользовательских сборках U-SQL.

1. Запустите средство проверки обратной совместимости для ваших .NET DLL либо
   1. Использование расширения Visual Studio в Расширении Visual Studio для анализатора переносимости .NET
   2. Скачивание и использование автономного инструмента с GitHub dotnetapiport. Инструкции по запуску автономного инструмента находятся в разделе Критические изменения GitHub dotnetapiport
   3. Для 4.7.2. совместимость read isRetargeting == True выявляет возможные проблемы.
2. Если средство указывает, может ли на ваш код повлиять какая-либо из возможных обратной несовместимости (ниже перечислены некоторые распространенные примеры несовместимости), можно дополнительно проверка:
   1. Анализ вашего кода и определение того, передает ли ваш код значения затронутым API
   2. Выполните проверку во время выполнения. Развертывание среды выполнения в ADLA не выполняется параллельно. Перед обновлением можно выполнить проверку среды выполнения, используя локальный запуск VisualStudio с локальной .NET Framework 4.7.2 для репрезентативного набора данных.
3. Если на вас действительно влияет обратная несовместимость, примите необходимые меры для ее устранения (например, исправьте свои данные или логику кода).

В большинстве случаев обратная несовместимость не должна влиять на вас.

Сроки

Вы можете проверить развертывание новой среды выполнения здесь Устранение неполадок среды выполнения и просмотрев все предыдущие успешные задания.

Что делать, если я не могу вовремя проверить свой код

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

Каковы наиболее распространенные проблемы обратной совместимости, с которыми вы можете столкнуться

Наиболее распространенные обратные несовместимости, которые средство проверки, скорее всего, определит (мы создали этот список, запустив средство проверки для наших собственных внутренних заданий ADLA), на какие библиотеки влияют (обратите внимание, что вы можете вызывать библиотеки только косвенно, поэтому важно принять необходимые меры No 1, чтобы проверка, если это влияет на ваши задания), и возможные действия для исправления. Примечание. Практически во всех случаях для наших собственных заданий предупреждения оказывались ложными из-за узкого характера большинства критических изменений.

• Чтобы результирующая задача завершилась, реализация свойства IAsyncResult.CompletedSynchronously должна быть правильной

  • При вызове TaskFactory.FromAsync реализация свойства IAsyncResult.CompletedSynchronously должна быть правильной, чтобы результирующая задача завершилась. То есть свойство должно возвращать значение true, если (и только если) реализация завершилась синхронно. Ранее свойство не проверялось.
  • Затронутые библиотеки: mscorlib, System.Threading.Tasks
  • Предлагаемое действие: убедитесь, что TaskFactory.FromAsync правильно возвращает true

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

  • Для приложений, предназначенных для NET Framework 4, а также для выполняющихся в .NET Framework 4.5.1 или более ранних версиях, DataObject.GetData получает HTML-данные в виде строки ASCII. В результате символы, отличные от ASCII (символы, коды ASCII которых больше 0x7F), представлены двумя случайными символами. # N ## N # Для приложений, предназначенных для .NET Framework 4.5 или более поздних версий и работающих на .NET Framework 4.5.2, DataObject.GetData извлекает данные в формате HTML как UTF-8, который правильно представляет символы больше 0x7F.
  • Затронутые библиотеки: Glo
  • Предлагаемое действие: убедитесь, что извлекаемые данные имеют нужный вам формат

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

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

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

  • Начиная с .NET Framework 4.6, при вызове HtmlTextWriter.RenderBeginTag() и HtmlTextWriter.RenderEndTag() с элементом <BR /> правильно вставляется только один <BR /> (вместо двух).
  • Затронутые библиотеки: System.Web
  • Предлагаемое действие. Убедитесь, что вы вставляете ожидаемый объем, чтобы в рабочем задании <BR /> не было случайного поведения.

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

  • В .NET Framework 4.6 изменилась реализация AuthorizationContext, возвращаемая вызовом CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) с нулевым аргументом authorizationPolicies.
  • Затронутые библиотеки: System.IdentityModel
  • Предлагаемое действие. Убедитесь, что вы обрабатываете новое ожидаемое поведение при наличии политики авторизации null.

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

  • В версиях .NET Framework до 4.6.2 клиенты с нестандартным размером ключа для сертификатов RSA не могли получить доступ к этим ключам через методы расширения GetRSAPublicKey() и GetRSAPrivateKey(). Выдается CryptographicException с сообщением "Запрошенный размер ключа не поддерживается". В .NET Framework 4.6.2 эта проблема устранена. Точно так же RSA.ImportParameters() и RSACng.ImportParameters() теперь работают с нестандартными размерами ключей, не выбрасывая CryptographicException.
  • Затронутые библиотеки: mscorlib, System.Core
  • Предлагаемое действие: убедитесь, что ключи RSA работают должным образом

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

  • В платформа .NET Framework 4.6.2 было внесено много изменений для поддержки ранее неподдерживаемых путей (как по длине, так и по формату). Исправлены проверки надлежащего синтаксиса разделителя диска (двоеточие), в результате появился побочный эффект в виде блокировки некоторых путей универсального кода ресурса (URI) в некоторых API-интерфейсах пути, где раньше это допускалось.
  • Затронутые библиотеки: mscorlib, System.Runtime.Extensions
  • Предлагаемое действие:

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

  • Начиная с платформа .NET Framework 4.6.2, изменилось, как T:System.Security.Claims.ClaimsIdentity конструкторы с параметром T:System.Security.Principal.IIdentity задают P:System.Security.Claims.ClaimsIdentify.Actor свойство . Если аргумент T:System.Security.Principal.IIdentity является объектом T:System.Security.Claims.ClaimsIdentity, а свойство P:System.Security.Claims.ClaimsIdentify.Actor этого объекта T:System.Security.Claims.ClaimsIdentity не равно null, свойство P:System.Security.Claims.ClaimsIdentify.Actor присоединяется с помощью метода M:System.Security.Claims.ClaimsIdentity.Clone. В Framework 4.6.1 и более ранних версиях свойство P:System.Security.Claims.ClaimsIdentify.Actor прикреплено как существующая ссылка. Из-за этого изменения, начиная с .NET Framework 4.6.2, свойство P:System.Security.Claims.ClaimsIdentify.Actor нового объекта T:System.Security.Claims.ClaimsIdentity не равно свойству P:System.Security.Claims.ClaimsIdentify.Actor аргумента T:System.Security.Principal.IIdentity конструктора. В платформа .NET Framework 4.6.1 и более ранних версиях это равно.
  • Затронутые библиотеки: mscorlib
  • Предлагаемое действие: убедитесь, что ClaimsIdentity работает должным образом в новой среде выполнения

• Сериализация управляющих символов с помощью DataContractJsonSerializer теперь совместима с ECMAScript версии 6 и 8

  • В .NET Framework 4.6.2 и более ранних версиях DataContractJsonSerializer не сериализовал некоторые специальные управляющие символы, такие как \b, \f и \t, способом, совместимым со стандартами ECMAScript V6 и V8. Начиная с .NET Framework 4.7 сериализация таких управляющих символов совместима с ECMAScript версий 6 и 8.
  • Затронутые библиотеки: System.Runtime.Serialization.Json
  • Предлагаемое действие: обеспечьте такое же поведение с DataContractJsonSerializer