يقوم Azure Data Lake Analytics بالترقية إلى .NET Framework v4.7.2

هام

تم إيقاف Azure Data Lake Analytics في 29 فبراير 2024. تعرف على المزيد من خلال هذا الإعلان.

بالنسبة لتحليلات البيانات، يمكن لمؤسستك استخدام 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 أن .NET Framework المنشورة في وقت تشغيل U-SQL (وقت التشغيل الافتراضي) ستكون الآن دائما 4.7.2. لا يوجد خيار جنبا إلى جنب للإصدارات .NET Framework.

بعد اكتمال هذه الترقية إلى .NET Framework 4.7.2، سيتم تشغيل التعليمات البرمجية المدارة للنظام كإصدار 4.7.2، وسيتم تشغيل المكتبات المقدمة من المستخدم مثل التجميعات المخصصة U-SQL في الوضع المتوافق مع الإصدارات السابقة المناسب للإصدار الذي تم إنشاء التجميع له.

• إذا تم إنشاء DLLs التجميع للإصدار 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.

ملاحظة

لا تكتشف الأداة التغييرات العاجلة الفعلية. يحدد فقط ما يسمى واجهات برمجة تطبيقات .NET التي قد تتسبب (لبعض المدخلات) في حدوث مشكلات. إذا تم إعلامك بمشكلة، فقد تظل التعليمات البرمجية الخاصة بك على ما يرام، ولكن يجب عليك التحقق من المزيد من التفاصيل.

1. قم بتشغيل مدقق التوافق مع الإصدارات السابقة على .NET DLLs إما بواسطة
   1. استخدام ملحق Visual Studio في ملحق .NET Portability Analyzer Visual Studio
   2. تنزيل الأداة المستقلة واستخدامها من GitHub dotnetapiport. توجد إرشادات لتشغيل أداة مستقلة في تغييرات كسر GitHub dotnetapiport
   3. ل 4.7.2. التوافق، read isRetargeting == True يحدد المشكلات المحتملة.
2. إذا كانت الأداة تشير إلى ما إذا كانت التعليمات البرمجية الخاصة بك قد تتأثر بأي من أوجه عدم التوافق المحتملة مع الإصدارات السابقة (يتم سرد بعض الأمثلة الشائعة لعدم التوافق أدناه)، يمكنك التحقق بشكل أكبر من خلال
   1. تحليل التعليمات البرمجية الخاصة بك وتحديد ما إذا كانت التعليمات البرمجية الخاصة بك تمرر القيم إلى واجهات برمجة التطبيقات المتأثرة
   2. إجراء فحص وقت التشغيل. لا يتم توزيع وقت التشغيل جنبا إلى جنب في ADLA. يمكنك إجراء فحص وقت التشغيل قبل الترقية، باستخدام التشغيل المحلي ل VisualStudio مع .NET Framework المحلية 4.7.2 مقابل مجموعة بيانات تمثيلية.
3. إذا كنت بالفعل متأثرا بعدم توافق مع الإصدارات السابقة، فاتخذ الخطوات اللازمة لإصلاحه (مثل إصلاح بياناتك أو منطق التعليمات البرمجية).

في معظم الحالات، لا ينبغي أن تتأثر بعدم التوافق مع الإصدارات السابقة.

اليوميات

يمكنك التحقق من نشر وقت التشغيل الجديد هنا استكشاف أخطاء وقت التشغيل وإصلاحها، ومن خلال النظر في أي مهمة ناجحة سابقة.

ماذا لو لم أتمكن من مراجعة التعليمات البرمجية الخاصة بي في الوقت المناسب

يمكنك إرسال وظيفتك مقابل إصدار وقت التشغيل القديم (الذي تم إنشاؤه يستهدف 4.5.2)، ولكن نظرا لعدم وجود قدرات .NET Framework جنبا إلى جنب، فإنه سيظل يعمل فقط في وضع التوافق 4.5.2. قد لا تزال تواجه بعض مشكلات التوافق مع الإصدارات السابقة بسبب هذا السلوك.

ما هي مشكلات التوافق مع الإصدارات السابقة الأكثر شيوعا التي قد تواجهها

أكثر حالات عدم التوافق مع الإصدارات السابقة التي من المحتمل أن يحددها المدقق هي (أنشأنا هذه القائمة عن طريق تشغيل المدقق على وظائف ADLA الداخلية الخاصة بنا)، والتي تتأثر المكتبات (ملاحظة: أنه يمكنك استدعاء المكتبات بشكل غير مباشر فقط، وبالتالي من المهم اتخاذ الإجراء المطلوب رقم 1 للتحقق مما إذا كانت وظائفك متأثرة)، والإجراءات الممكنة لتصحيحها. ملاحظة: في جميع الحالات تقريبا لوظائفنا الخاصة، تبين أن التحذيرات إيجابيات خاطئة بسبب الطبيعة الضيقة لمعظم التغييرات العاجلة.

• يجب أن تكون الخاصية IAsyncResult.CompletedSynchronously صحيحة حتى تكتمل المهمة الناتجة

  • عند استدعاء TaskFactory.FromAsync، يجب أن يكون تنفيذ الخاصية IAsyncResult.CompletedSynchronously صحيحا حتى تكتمل المهمة الناتجة. أي، يجب أن ترجع الخاصية true إذا اكتمل التنفيذ بشكل متزامن فقط إذا كان. في السابق، لم يتم التحقق من الخاصية.
  • المكتبات المتأثرة: mscorlib، System.Threading.Tasks
  • الإجراء المقترح: تأكد من إرجاع TaskFactory.FromAsync بشكل صحيح

• تسترد DataObject.GetData الآن البيانات ك UTF-8

  • بالنسبة للتطبيقات التي تستهدف .NET Framework 4 أو التي تعمل على .NET Framework 4.5.1 أو الإصدارات السابقة، تسترد DataObject.GetData البيانات بتنسيق HTML كسلسلة ASCII. ونتيجة لذلك، يتم تمثيل الأحرف غير ASCII (الأحرف التي تكون رموز ASCII الخاصة بها أكبر من 0x7F) بواسطة حرفين عشوائيين.#N##N#For التطبيقات التي تستهدف .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. قارئ الكتاب
  • الإجراء المقترح: تأكد من عدم كتابة زوج بديل غير صالح سيؤدي إلى استثناء الوسيطة

• لا يعرض <br/> HtmlTextWriter العنصر بشكل صحيح

  • بدءا من .NET Framework 4.6، سيؤدي استدعاء HtmlTextWriter.RenderBeginTag() و باستخدام عنصر <BR /> إلى إدراج واحد <BR /> فقط بشكل صحيح (HtmlTextWriter.RenderEndTag()بدلا من اثنين)
  • المكتبات المتأثرة: System.Web
  • الإجراء المقترح: تأكد من <BR /> إدراج المقدار الذي تتوقع رؤيته حتى لا يتم رؤية أي سلوك عشوائي في مهمة الإنتاج

• تم تغيير استدعاء CreateDefaultAuthorizationContext باستخدام وسيطة خالية

  • أدى تنفيذ AuthorizationContext الذي تم إرجاعه بواسطة استدعاء إلى وسيطة authorizationPolicies فارغة إلى CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) تغيير تنفيذه في .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's.
  • المكتبات المتأثرة: mscorlib، System.Core
  • الإجراء المقترح: تأكد من أن مفاتيح RSA تعمل كما هو متوقع

• عمليات التحقق من علامة النقطتان للمسار أكثر صرامة

  • في .NET Framework 4.6.2، تم إجراء العديد من التغييرات لدعم المسارات غير المدعومة سابقا (سواء في الطول أو التنسيق). تم إجراء عمليات التحقق من بناء جملة فاصل محرك الأقراص المناسب (النقطتين) بشكل أكثر صحة، والذي كان له تأثير جانبي لحظر بعض مسارات URI في عدد قليل من واجهات برمجة تطبيقات المسار المحددة حيث كانت متسامحة.
  • المكتبات المتأثرة: 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 الأسلوب . في إطار العمل 4.6.1 والإصدارات السابقة، يتم إرفاق الخاصية P:System.Security.Claims.ClaimsIdentify.Actor كمرجع موجود. وبسبب هذا التغيير، بدءا من .NET Framework 4.6.2، P:System.Security.Claims.ClaimsIdentify.Actor لا تساوي P:System.Security.Claims.ClaimsIdentify.Actor خاصية الكائن الجديد T:System.Security.Claims.ClaimsIdentity خاصية وسيطة الدالة الإنشائية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 V6 وV8.
  • المكتبات المتأثرة: System.Runtime.Serialization.Json
  • الإجراء المقترح: تأكد من نفس السلوك مع DataContractJsonSerializer