Azure Data Lake Analytics 将升级到 .NET Framework v4.7.2
重要
Azure Data Lake Analytics于 2024 年 2 月 29 日停用。 通过此公告了解更多信息。
对于数据分析，组织可以使用 Azure Synapse Analytics 或 Microsoft Fabric。
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 的这一升级意味着在 U-SQL 运行时（默认运行时）中部署的 .NET Framework 现在将始终是 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 语义（有几个例外）。
- 如果你以 .NET Framework 4.7.2 作为目标，则现在可以利用那些使用 4.7.2 版功能的 U-SQL 自定义程序集。
由于这个升级（升级到 .NET Framework 4.7.2），可能会将中断性变更引入那些使用 .NET 自定义程序集的 U-SQL 作业。 建议使用以下过程检查是否存在后向兼容性问题。
如何检查后向兼容性问题
通过对你的 U-SQL 自定义程序集中的 .NET 代码运行 .NET 兼容性检查，检查是否可能存在后向兼容性中断性问题。
注意
该工具不会检测实际的中断性变更。 它仅查明所调用的可能会导致问题的 .NET API（对于某些输入而言）。 如果你收到有关问题的通知，你的代码可能仍然会正常运行，但是你应该进行更细致的检查。
- 通过以下方式对 .NET DLL 运行后向兼容性检查器：
- 使用 .NET Portability Analyzer Visual Studio 扩展中的 Visual Studio 扩展
- 下载并使用 GitHub dotnetapiport 中的独立工具。 有关运行独立工具的说明，请参阅 GitHub dotnetapiport 中断性变更
- 对于 4.7.2 兼 容性，
read isRetargeting == True表明可能存在问题。
- 如果该工具指示代码是否可能受到任何可能的后向不兼容影响， (下面列出了一些常见的不兼容示例) ，则可以进一步检查
- 分析你的代码并确定代码是否在将值传递给受影响的 API
- 执行运行时检查。 ADLA 中不会并行执行运行时部署。 在升级之前，你可以对一个具有代表性的数据集使用 VisualStudio 的本地运行和本地 .NET Framework 4.7.2 来执行运行时检查。
- 如果你确实受到后向不兼容性问题的影响，请采取必要的步骤来修复它（例如修复数据或代码逻辑）。
在大多数情况下，不应受到向后不兼容的影响。
时间线
你可以在这里检查新运行时的部署：运行时排除故障，并查看以前成功的作业。
如果我不能及时检查代码，该怎么办？
你可以针对旧的运行时版本（以 4.5.2 作为目标构建）提交作业，但是由于缺少 .NET Framework 并行功能，它仍然只能在 4.5.2 兼容模式下运行。 由于存在此行为，你可能仍会遇到一些后向兼容性问题。
你可能会遇到的最常见后向兼容性问题是什么
检查器可能识别的最常见的向后兼容性是 (我们在自己的内部 ADLA 作业上运行检查器) 生成此列表，这些库会受到影响 (注意：可以仅间接调用库，因此，如果作业) 受到影响，请务必采取所需的操作 #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将按 UTF-8 检索 HTML 格式的数据，从而可以正确表示大于 0x7F 的字符。 - 受影响的库：Glo
- 建议的操作：确保检索的数据采用你需要的格式
- 对于面向 .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 上运行的应用，
XmlWriter 引发无效的代理项对
- 对于面向 .NET Framework 4.5.2 或早期版本的应用，使用异常回退处理编写无效代理项对并不总是引发异常。 对于面向 .NET Framework 4.6 的应用，尝试编写无效的代理项对会引发
ArgumentException。 - 受影响的库：System.Xml、System.Xml.ReaderWriter
- 建议的操作：确保未编写将导致参数异常的无效代理项对
- 对于面向 .NET Framework 4.5.2 或早期版本的应用，使用异常回退处理编写无效代理项对并不总是引发异常。 对于面向 .NET Framework 4.6 的应用，尝试编写无效的代理项对会引发
HtmlTextWriter 无法正确呈现
<br/>元素- 从 .NET Framework 4.6 开始，调用带有
<BR />的HtmlTextWriter.RenderBeginTag()和HtmlTextWriter.RenderEndTag()将正确插入唯一<BR />（而非两个） - 受影响的库：System.Web
- 建议的操作：确保插入预期的数量
<BR />，以便在生产作业中看不到任何随机行为
- 从 .NET Framework 4.6 开始，调用带有
调用具有 null 自变量的 CreateDefaultAuthorizationContext 的方式已更改
- 调用具有 null authorizationPolicies 自变量的
CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)所返回的 AuthorizationContext 实现更改了其在 .NET Framework 4.6 中的实现。 - 受影响的库：System.IdentityModel
- 建议的操作：确保在存在 null 授权策略时处理新的预期行为
- 调用具有 null authorizationPolicies 自变量的
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 之前的版本中，使用非标准密钥大小的 RSA 证书的客户无法通过
路径冒号检查更严格
- 在 .NET Framework 4.6.2 中，进行了许多更改，以支持以前不支持的路径 (长度和格式) 。 检查正确的驱动器分隔符（冒号）语法变得更加严格，这样做的副作用是阻止了少量特选路径 API 中的某些 URI 路径，这些曾经是可以容忍的。
- 受影响的库：mscorlib、System.Runtime.Extensions
- 建议的操作：
调用 ClaimsIdentity 构造函数
- 从 .NET Framework 4.6.2 开始，具有
T:System.Security.Principal.IIdentity参数的构造函数设置P:System.Security.Claims.ClaimsIdentify.Actor属性的方式T:System.Security.Claims.ClaimsIdentity发生了变化。 如果T:System.Security.Principal.IIdentity参数是T:System.Security.Claims.ClaimsIdentity对象，且该T:System.Security.Claims.ClaimsIdentity对象的P:System.Security.Claims.ClaimsIdentify.Actor属性不为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 开始，新的T:System.Security.Claims.ClaimsIdentity对象的P:System.Security.Claims.ClaimsIdentify.Actor属性不等于构造函数的T:System.Security.Principal.IIdentity参数的P:System.Security.Claims.ClaimsIdentify.Actor属性。 在 .NET Framework 4.6.1 及更早版本中，它是相等的。 - 受影响的库：mscorlib
- 建议的操作：确保 ClaimsIdentity 在新运行时上按预期方式工作
- 从 .NET Framework 4.6.2 开始，具有
使用 DataContractJsonSerializer 控制字符的序列化现在与 ECMAScript V6 和 V8 兼容
- 在 .NET Framework 4.6.2 及更早版本中，DataContractJsonSerializer 未以与 ECMAScript V6 和 V8 标准兼容的方式序列化某些特殊控制字符，例如 \b、\f 和 \t。 从 .NET Framework 4.7 开始，这些控制字符的序列化与 ECMAScript V6 和 V8 兼容。
- 受影响的库：System.Runtime.Serialization.Json
- 建议的操作：确保在使用 DataContractJsonSerializer 时具有相同的行为