Azure Data Lake Analytics が .NET Framework v4.7.2 にアップグレード中
重要
Azure Data Lake Analyticsは、2024 年 2 月 29 日に廃止されました。 詳細については、このお知らせを参照してください。
データ分析の場合、organizationは 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 互換性チェックを実行して、下位互換性に問題がある可能性があるかどうかを確認します。
Note
このツールでは、実際の破壊的変更は検出されません。 呼び出された .NET API のうち、(特定の入力に対して) 問題の原因となる可能性のあるものが識別されるだけです。 問題の通知を受け取った場合でも、コードに問題がない可能性があるものの、詳細を確認する必要があります。
- 次のいずれかの方法で、.NET DLL に対して下位互換性チェックを実行します。
- .NET Portability Analyzer の Visual Studio 拡張機能に関するページに従って、Visual Studio 拡張機能を使用する。
- GitHub dotnetapiport からスタンドアロン ツールをダウンロードして使用する。 スタンドアロン ツールの実行手順については、GitHub dotnetapiport の破壊的変更に関するページを参照してください。
- 4.7.2 では、 互換性、
read isRetargeting == Trueは、潜在的な問題を特定します。
- ツールで、コードが下位互換性の可能性によって影響を受ける可能性があるかどうかを示している場合 (一般的な非互換性の例をいくつか以下に示します)、次の方法でさらにチェックできます。
- コードを分析し、影響を受ける API にコードによって値が渡されるかどうかを識別する。
- ランタイム チェックを実行する。 ADLA では、ランタイムのデプロイはサイド バイ サイドで実行されません。 代表的なデータ セットに対して Visual Studio のローカル実行をローカルの .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 よりも大きい文字) は、2 つのランダムな文字で表されます。.NET Framework 4.5 以降を対象とし、.NET Framework 4.5.2 で実行されるアプリでは、
DataObject.GetDataによって HTML 形式のデータが UTF-8 として取得されます。この場合、0x7F よりも大きい文字が正しく表されます。 - 影響を受けるライブラリ: Glo
- 推奨されるアクション: 取得されたデータが必要な形式であることを確認する
- .NET Framework 4 を対象とするアプリ、または .NET Framework 4.5.1 以前のバージョンで実行されるアプリでは、DataObject.GetData によって HTML 形式のデータが ASCII 文字列として取得されます。 その結果、非 ASCII 文字 (ASCII コードが 0x7F よりも大きい文字) は、2 つのランダムな文字で表されます。.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 />が 1 つのみ (2 つではなく) 正しく挿入されます。 - 影響を受けるライブラリ: 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 キーが正しく読み込まれるようになりました
- 4\.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの
GetRSAPublicKey()やGetRSAPrivateKey()でそのキーにアクセスできません。 "要求されたキー サイズはサポートされていません" というメッセージと共にCryptographicExceptionがスローされます。 .NET Framework 4.6.2 では、この問題は修正されています。 同様に、RSA.ImportParameters()とRSACng.ImportParameters()は非標準のキー サイズで動作するようになり、CryptographicExceptionはスローされなくなりました。 - 影響を受けるライブラリ: mscorlib、System.Core
- 推奨されるアクション: RSA キーが想定どおりに動作していることを確認する
- 4\.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの
パスのコロン確認が厳密化
- .NET Framework 4.6.2 では、以前はサポートされていなかったパス (長さと形式の両方) をサポートするために多くの変更が行われました。 適切なドライブ区切り (コロン) 構文の確認がより正確に行われました。その結果、それ以前は許容されていた、ごく少数のパス API の一部の URI パスがブロックされました。
- 影響を受けるライブラリ: mscorlib、System.Runtime.Extensions
- 推奨アクション:
ClaimsIdentity コンストラクターを呼び出す
- .NET Framework 4.6.2 以降では、パラメーターを持つ
T:System.Security.Principal.IIdentityコンストラクターが プロパティを設定する方法がT:System.Security.Claims.ClaimsIdentityP:System.Security.Claims.ClaimsIdentify.Actor変更されました。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 以降では、新しい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 と同じ動作を保証する