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 版，則已部署的架構會將這些 DLL 視為 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 可攜性分析器 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 會以 ASCII 字串形式來擷取 HTML 格式的資料。 因此，非 ASCII 字元 (ASCII 碼大於 0x7F 的字元) 是由兩個隨機字元呈現。#N##N#若為以 .NET Framework 4.5 或更新版本為目標且在 .NET Framework 4.5.2 上執行的應用程式，
DataObject.GetData會以 UTF-8 格式擷取 HTML 格式資料，UTF-8 格式可以正確地呈現大於 0x7F 的字元。 - 受影響的程式庫：Glo
- 建議的動作：確定所擷取的資料是您想要的格式
- 若為以 NET Framework 4 為目標的應用程式，或者在 .NET Framework 4.5.1 或舊版上執行的應用程式，DataObject.GetData 會以 ASCII 字串形式來擷取 HTML 格式的資料。 因此，非 ASCII 字元 (ASCII 碼大於 0x7F 的字元) 是由兩個隨機字元呈現。#N##N#若為以 .NET Framework 4.5 或更新版本為目標且在 .NET Framework 4.5.2 上執行的應用程式，
無效的代理字組會擲回 XmlWriter
- 針對以 .NET Framework 4.5.2 或舊版為目標的應用程式，使用例外狀況後援處理撰寫無效的 Surrogate 配對不一定會擲回例外狀況。 針對以 .NET Framework 4.6 為目標的應用程式，嘗試寫入無效的代理字組會擲回
ArgumentException例外狀況。 - 受影響的程式庫：System.Xml、System.Xml.ReaderWriter
- 建議的動作：請確定您未撰寫會導致自變數例外狀況的無效 Surrogate 字組
- 針對以 .NET Framework 4.5.2 或舊版為目標的應用程式，使用例外狀況後援處理撰寫無效的 Surrogate 配對不一定會擲回例外狀況。 針對以 .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，則會使用M:System.Security.Claims.ClaimsIdentity.Clone方法來附加P:System.Security.Claims.ClaimsIdentify.Actor屬性。 在 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 在新的執行階段如預期般運作
- 從 .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 的行為相同