Azure Data Lake Analytics обновляется до .NET Framework версии 4.7.2

Среда выполнения Azure Data Lake Analytics по умолчанию обновляется с .NET Framework версии 4.5.2 до .NET Framework версии 4.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 в ваших пользовательских сборках U-SQL.

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

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

Временная шкала

Вы можете проверить развертывание новой среды выполнения здесь Runtime troubleshoot и, взглянув на любое ранее успешное задание.

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

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

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

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

• Свойство 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 с нулевым аргументом произошли изменения.

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

• 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. В 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 V6 и V8

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