Azure Data Lake Analytics memutakhirkan ke .NET Framework v4.7.2

Penting

Azure Data Lake Analytics pensiun pada 29 Februari 2024. Pelajari lebih lanjut dengan pengumuman ini.

Untuk analitik data, organisasi Anda dapat menggunakan Azure Synapse Analytics atau Microsoft Fabric.

Runtime default Azure Data Lake Analytics ditingkatkan dari .NET Framework v4.5.2 ke .NET Framework v4.7.2. Perubahan ini memperkenalkan risiko kecil melanggar perubahan jika kode U-SQL Anda menggunakan majelis kustom, dan majelis kustom tersebut menggunakan library .NET.

Peningkatan dari .NET Framework 4.5.2 ke versi 4.7.2 berarti bahwa .NET Framework yang digunakan dalam runtime U-SQL (runtime default) sekarang akan selalu 4.7.2. Tidak ada opsi berdampingan untuk versi .NET Framework.

Setelah pemutakhiran ini ke .NET Framework 4.7.2 selesai, kode terkelola sistem akan berjalan sebagai versi 4.7.2, perpustakaan yang disediakan pengguna seperti rakitan kustom U-SQL akan berjalan dalam mode kompatibel mundur yang sesuai untuk versi yang telah dibuat oleh perakitan.

• Jika DL perakitan Anda dihasilkan untuk versi 4.5.2, kerangka kerja yang disebarkan akan memperlakukan mereka sebagai 4.5.2 perpustakaan, menyediakan (dengan beberapa pengecualian) 4.5.2 semantik.
• Sekarang Anda dapat menggunakan rakitan kustom U-SQL yang menggunakan fitur versi 4.7.2, jika Anda menargetkan .NET Framework 4.7.2.

Karena peningkatan ini ke .NET Framework 4.7.2, ada potensi untuk memperkenalkan perubahan yang melanggar pada pekerjaan U-SQL Anda yang menggunakan rakitan kustom .NET. Kami sarankan Anda memeriksa masalah kompatibilitas mundur menggunakan prosedur di bawah ini.

Cara memeriksa masalah kompatibilitas mundur

Periksa potensi masalah pemecahan kompatibilitas mundur dengan menjalankan pemeriksaan kompatibilitas .NET pada kode .NET Anda di majelis kustom U-SQL Anda.

Catatan

Alat ini tidak mendeteksi perubahan pemecahan aktual. itu hanya mengidentifikasi yang disebut API .NET yang mungkin (untuk input tertentu) menyebabkan masalah. Jika Anda mendapatkan pemberitahuan tentang masalah, kode Anda mungkin masih baik-baik saja, namun Anda harus check-in lebih detail.

1. Jalankan pemeriksa kompatibilitas mundur pada DL .NET Anda baik dengan
   1. Menggunakan Ekstensi Visual Studio di .NET Portability Analyzer Visual Studio Extension
   2. Mengunduh dan menggunakan alat mandiri dari GitHub dotnetapiport. Petunjuk untuk menjalankan alat mandiri ada di GitHub dotnetapiport melanggar perubahan
   3. Untuk 4.7.2. kompatibilitas, read isRetargeting == True mengidentifikasi kemungkinan masalah.
2. Jika alat menunjukkan apakah kode Anda dapat terpengaruh oleh salah satu kemungkinan ketidakkompibilan mundur (beberapa contoh umum ketidakkompibilitas tercantum di bawah), Anda dapat memeriksa lebih lanjut dengan
   1. Menganalisis kode Anda dan mengidentifikasi apakah kode Anda meneruskan nilai ke API yang terkena dampak
   2. Lakukan pemeriksaan runtime bahasa umum. Penyebaran runtime bahasa umum tidak dilakukan berdampingan di ADLA. Anda dapat melakukan pemeriksaan runtime bahasa umum sebelum pemutakhiran, menggunakan run lokal VisualStudio dengan .NET Framework 4.7.2 lokal terhadap himpunan data perwakilan.
3. Jika Anda memang terkena dampak ketidakcocokan mundur, ambil langkah-langkah yang diperlukan untuk memperbaikinya (seperti memperbaiki data atau logika kode Anda).

Dalam kebanyakan kasus, Anda tidak boleh terpengaruh oleh ketidakkompibilan mundur.

Garis waktu

Anda dapat memeriksa penyebaran runtime bahasa umum baru di sini Memecahkan masalah Runtime Bahasa Umum, dan dengan melihat pekerjaan yang berhasil sebelumnya.

Bagaimana jika saya tidak bisa mendapatkan kode saya ditinjau tepat waktu

Anda dapat mengirimkan pekerjaan Anda terhadap versi runtime bahasa umum lama (yang dibangun menargetkan 4.5.2), namun karena kurangnya kemampuan .NET Framework berdampingan, itu masih hanya akan berjalan dalam mode kompatibilitas 4.5.2. Anda mungkin masih mengalami beberapa masalah kompatibilitas mundur karena perilaku ini.

Apa masalah kompatibilitas mundur yang paling umum yang mungkin Anda temui

Ketidakkompatibilitas mundur yang paling umum yang mungkin diidentifikasi oleh pemeriksa adalah (kami membuat daftar ini dengan menjalankan pemeriksa pada pekerjaan ADLA internal kami sendiri), pustaka mana yang terpengaruh (catatan: bahwa Anda dapat memanggil pustaka hanya secara tidak langsung, sehingga penting untuk mengambil tindakan yang diperlukan #1 untuk memeriksa apakah pekerjaan Anda terpengaruh), dan kemungkinan tindakan untuk memperbaikinya. Catatan: Dalam hampir semua kasus untuk pekerjaan kita sendiri, peringatan ternyata positif salah karena sifat sempit dari sebagian besar perubahan yang melanggar.

• IAsyncResult.CompletedSynchronously properti harus benar agar tugas yang dihasilkan selesai

  • Saat memanggil TaskFactory.FromAsync, implementasi properti IAsyncResult.CompletedSynchronously harus benar agar tugas yang dihasilkan selesai. Artinya, properti harus kembali benar jika, dan hanya jika, implementasi selesai secara sinkron. Sebelumnya, properti tidak diperiksa.
  • Pustaka yang Terkena Dampak: mscorlib, System.Threading.Tasks
  • Tindakan yang Disarankan: Pastikan TaskFactory.FromAsync mengembalikan true dengan benar

• DataObject.GetData sekarang mengambil data sebagai UTF-8

  • Untuk aplikasi yang menargetkan .NET Framework 4 atau yang berjalan pada .NET Framework 4.5.1 atau versi yang lebih lama, DataObject.GetData mengambil data berformat HTML sebagai string ASCII. Akibatnya, karakter non-ASCII (karakter yang kode ASCII-nya lebih besar dari 0x7F) diwakili oleh dua karakter acak.#N##N#For yang menargetkan .NET Framework 4.5 atau yang lebih baru dan berjalan pada .NET Framework 4.5.2, DataObject.GetData mengambil data berformat HTML sebagai UTF-8, yang mewakili karakter yang lebih besar dari 0x7F dengan benar.
  • Perpustakaan yang Terkena Dampak: Glo
  • Tindakan yang Disarankan: Pastikan data yang diambil adalah format yang Anda inginkan

• XmlWriter melempar pada pasangan pengganti yang tidak valid

  • Untuk aplikasi yang menargetkan .NET Framework 4.5.2 atau versi sebelumnya, menulis pasangan pengganti yang tidak valid menggunakan penanganan fallback pengecualian tidak selalu memberikan pengecualian. Untuk aplikasi yang menargetkan .NET Framework 4.6, mencoba menulis pasangan pengganti yang tidak valid melempar ArgumentException .
  • Perpustakaan yang Terkena Dampak: System.Xml, System.Xml. Penulis Pembaca
  • Tindakan yang Disarankan: Pastikan Anda tidak menulis pasangan pengganti yang tidak valid yang akan menyebabkan pengecualian argumen

• HtmlTextWriter tidak merender <br/> elemen dengan benar

  • Dimulai di .NET Framework 4.6, panggilan dan HtmlTextWriter.RenderBeginTag() dengan elemen hanya akan menyisipkan satu HtmlTextWriter.RenderEndTag()<BR /><BR /> (bukan dua)
  • Pustaka yang Terkena Dampak: System.Web
  • Tindakan yang Disarankan: Pastikan Anda menyisipkan jumlah yang <BR /> Anda harapkan untuk dilihat sehingga tidak ada perilaku acak yang terlihat dalam pekerjaan produksi

• Memanggil CreateDefaultAuthorizationContext dengan argumen null telah berubah

  • Implementasi AuthorizationContext yang dikembalikan oleh panggilan ke CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) argumen otorisasi nullPolicies telah mengubah implementasinya dalam .NET Framework 4.6.
  • Perpustakaan yang Terkena Dampak: System.IdentityModel
  • Tindakan yang Disarankan: Pastikan Anda menangani perilaku baru yang diharapkan saat ada kebijakan otorisasi null

• RSACng sekarang memuat kunci RSA dengan benar dengan ukuran kunci non-standar

  • Dalam versi .NET Framework sebelum 4.6.2, pelanggan dengan ukuran kunci non-standar untuk sertifikat RSA tidak dapat mengakses kunci tersebut melalui GetRSAPublicKey() metode GetRSAPrivateKey() dan ekstensi. A CryptographicException dengan pesan "Ukuran kunci yang diminta tidak didukung" dilemparkan. Dengan .NET Framework 4.6.2 masalah ini telah diperbaiki. Demikian pula, RSA.ImportParameters() dan sekarang bekerja dengan ukuran kunci RSACng.ImportParameters() non-standar CryptographicException tanpa melempar.
  • Perpustakaan yang Terkena Dampak: mscorlib, System.Core
  • Tindakan yang Disarankan: Pastikan kunci RSA berfungsi seperti yang diharapkan

• Pemeriksaan titik dua jalur lebih ketat

  • Dalam .NET Framework 4.6.2, banyak perubahan yang dilakukan untuk mendukung jalur yang sebelumnya tidak didukung (panjang dan format). Pemeriksaan untuk sintaks pemisah drive (titik dua) yang tepat dibuat lebih benar, yang memiliki efek samping memblokir beberapa jalur URI di beberapa API Jalur tertentu ketika dulunya dapat ditoleransi.
  • Perpustakaan yang Terkena Dampak: mscorlib, System.Runtime.Extensions
  • Tindakan yang Disarankan:

• Panggilan ke konstruktor ClaimsIdentity

  • Dimulai dengan .NET Framework 4.6.2, ada perubahan bagaimana T:System.Security.Claims.ClaimsIdentity konstruktor dengan T:System.Security.Principal.IIdentity parameter mengatur P:System.Security.Claims.ClaimsIdentify.Actor properti . Jika T:System.Security.Principal.IIdentity argumen adalah T:System.Security.Claims.ClaimsIdentity objek, dan P:System.Security.Claims.ClaimsIdentify.Actor properti dari T:System.Security.Claims.ClaimsIdentity objek itu tidak null, maka P:System.Security.Claims.ClaimsIdentify.Actor properti dilampirkan dengan menggunakan M:System.Security.Claims.ClaimsIdentity.Clone metode. Dalam Kerangka Kerja 4.6.1 dan versi yang lebih P:System.Security.Claims.ClaimsIdentify.Actor lama, properti dilampirkan sebagai referensi lama. Karena perubahan ini, dimulai dengan .NET Framework 4.6.2, P:System.Security.Claims.ClaimsIdentify.Actor properti objek baru T:System.Security.Claims.ClaimsIdentity tidak sama dengan P:System.Security.Claims.ClaimsIdentify.Actor properti argumen T:System.Security.Principal.IIdentitykonstruktor. Dalam .NET Framework 4.6.1 dan versi yang lebih lama, itu sama.
  • Perpustakaan yang Terkena Dampak: mscorlib
  • Tindakan yang Disarankan: Pastikan ClaimsIdentity berfungsi seperti yang diharapkan pada runtime baru

• Serialisasi karakter kontrol dengan DataContractJsonSerializer sekarang kompatibel dengan ECMAScript V6 dan V8

  • Dalam .NET framework 4.6.2 dan versi yang lebih lama, DataContractJsonSerializer tidak membuat serial beberapa karakter kontrol khusus, seperti \b, \f, dan \t, dengan cara yang kompatibel dengan standar ECMAScript V6 dan V8. Dimulai dengan .NET Framework 4.7, serialisasi karakter kontrol ini kompatibel dengan ECMAScript V6 dan V8.
  • Pustaka yang Terkena Dampak: System.Runtime.Serialization.Jspada
  • Tindakan yang Disarankan: Pastikan perilaku yang sama dengan DataContractJsonSerializer