Perubahan runtime untuk migrasi ke .NET Framework 4.7.x

Artikel ini mencantumkan masalah kompatibilitas aplikasi yang diperkenalkan dalam .NET Framework 4,7, 4.7.1, dan 4.7.2.

.NET Framework 4.7

JIT

Pembuatan kode yang salah saat meneruskan dan membandingkan nilai UInt16

Detail lebih lanjut

Karena perubahan yang diperkenalkan dalam .NET Framework 4.7, dalam beberapa kasus kode yang dihasilkan oleh pengompilasi JIT dalam aplikasi yang berjalan pada .NET Framework 4.7 salah membandingkan dua T:System.UInt16 nilai. Untuk informasi selengkapnya, lihat Masalah #11508: Codegen buruk senyap saat meneruskan dan membandingkan args ushort pada GitHub.com.

Saran

Jika Anda mengalami masalah dalam perbandingan nilai 16-bit yang tidak ditandatangani di .NET Framework 4.7, tingkatkan ke .NET Framework 4.7.1.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Windows Presentation Foundation (WPF)

Crash di Selektor saat menghapus item dari koleksi INCC yang disesuaikan

Detail lebih lanjut

Hal ini dapat T:System.InvalidOperationException terjadi dalam skenario berikut:

• ItemsSource untuk T:System.Windows.Controls.Primitives.Selector adalah koleksi dengan implementasi kustom dari T:System.Collections.Specialized.INotifyCollectionChanged.
• Item terpilih dihapus dari koleksi.
• Objek T:System.Collections.Specialized.NotifyCollectionChangedEventArgs memiliki P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex = -1 (menunjukkan posisi yang tidak diketahui).

Tumpukan panggilan pengecualian dimulai at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element). Pengecualian ini dapat terjadi di .NET Framework 4.5 jika aplikasi memiliki lebih dari satu utas Dispatcher. Dalam .NET Framework 4.7, pengecualian juga dapat terjadi dalam aplikasi dengan satu utas Dispatcher.

Masalah ini diperbaiki dalam .NET Framework 4.7.1.

Saran

Tingkatkan ke .NET Framework 4.7.1.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

DataGridCellsPanel.BringIndexIntoView menghasilkan ArgumentOutOfRangeException

Detail lebih lanjut

ScrollIntoView(Object) akan berfungsi secara asinkron ketika virtualisasi kolom diaktifkan tetapi lebar kolom belum ditentukan. Jika kolom dihapus sebelum pekerjaan asinkron terjadi, System.ArgumentOutOfRangeException dapat terjadi.

Saran

Salah satu hal berikut ini:

• Tingkatkan ke .NET Framework 4.7.
• Instal patch layanan terbaru untuk .NET Framework 4.6.2.
• Hindari menghapus kolom sampai respons asinkron ScrollIntoView(Object) selesai.

API yang terpengaruh

• DataGrid.ScrollIntoView(Object)
• DataGrid.ScrollIntoView(Object, DataGridColumn)

ObjectDisposedException dilemparkan oleh pemeriksa ejaan WPF

Detail lebih lanjut

Aplikasi WPF terkadang mengalami crash selama pematian aplikasi dengan kesalahan System.ObjectDisposedException yang dilemparkan oleh pemeriksa ejaan. Ini diperbaiki dalam .NET Framework 4.7 WPF dengan menangani pengecualian dengan baik, oleh karena itu memastikan bahwa aplikasi tidak lagi terpengaruh. Perlu dicatat bahwa pengecualian kesempatan pertama sesekali akan terus diamati dalam aplikasi yang berjalan di bawah debugger.

Saran

Tingkatkan ke .NET Framework 4.7

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Mengubah ukuran Grid dapat menyebabkan aplikasi menjadi tidak responsif

Detail lebih lanjut

Perulangan tak terbatas dapat terjadi saat tata letak T:System.Windows.Controls.Grid dalam keadaan berikut:

• Definisi baris berisi dua baris bertanda *, keduanya menyatakan MinHeight dan MaxHeight.
• Konten dari baris * tidak melebihi Tinggi Maksimum yang sesuai.
• Tinggi yang tersedia pada Grid terlampaui oleh MinHeight pertama (ditambah baris lain yang bersifat tetap atau otomatis).
• Aplikasi ini menargetkan .NET Framework 4.7, atau ikut serta dalam algoritma alokasi 4.7 dengan mengatur Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false.

Loop bisa juga terjadi dengan lebih dari dua baris, atau dalam kasus serupa untuk kolom. Masalah ini diperbaiki dalam .NET Framework 4.7.1.

Saran

Tingkatkan ke .NET Framework 4.7.1. Atau, jika Anda tidak memerlukan algoritma alokasi 4.7, Anda dapat menggunakan pengaturan konfigurasi berikut:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Latar belakang Grup Pita diatur sebagai transparan pada build yang dilokalkan

Detail lebih lanjut

System.Windows.Controls.Ribbon.RibbonGroup latar belakang pada build yang dilokalkan selalu dicat dengan sikat Transparan, menghasilkan pengalaman UI yang buruk. Ini diperbaiki dalam .NET Framework 4.7 WPF dengan memperbarui sumber daya lokal untuk System.Windows.Controls.Ribbon.RibbonGroup, yang pada gilirannya memastikan pemilihan kuas yang tepat.

Saran

Tingkatkan ke .NET Framework 4.7

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Pembaruan Tumpukan Pencetakan WPF

Detail lebih lanjut

API Pencetakan WPF menggunakan System.Printing.PrintQueue sekarang memanggil Window's Print Document Package API alih-alih API Cetak XPS yang kini tidak digunakan lagi. Perubahan dilakukan dengan kemudahan perawatan sebagai pertimbangan; baik pengguna maupun pengembang tidak akan melihat perubahan pada perilaku atau penggunaan API. Tumpukan pencetakan baru diaktifkan secara default saat berjalan di Pembaruan Pembuat Windows 10. Tumpukan pencetakan lama masih akan terus berfungsi sama seperti sebelumnya di versi Windows yang lebih lama.

Saran

Untuk menggunakan tumpukan lama di Windows 10 Creators Update, atur nilai REG_DWORD UseXpsOMPrinting dari kunci registri HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\Windows Presentation Foundation\Printing ke 1.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Windows Workflow Foundation (WF)

Alur kerja sekarang melemparkan pengecualian asli alih-alih NullReferenceException dalam beberapa kasus

Detail lebih lanjut

Dalam .NET Framework 4.6.2 dan versi yang lebih lama, ketika metode Execute dari aktivitas alur kerja melempar pengecualian dengan nilai null untuk properti Message, runtime Alur Kerja System.Activities akan melemparkan System.NullReferenceException, menutupi pengecualian asli. Dalam .NET Framework 4.7, pengecualian asli yang sebelumnya ditutupi kini dilemparkan.

Saran

Jika kode Anda bergantung pada penanganan System.NullReferenceException, ubah agar dapat menangkap pengecualian yang dapat dilemparkan dari aktivitas kustom Anda.

API yang terpengaruh

• CodeActivity.Execute(CodeActivityContext)
• AsyncCodeActivity.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
• AsyncCodeActivity<TResult>.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
• WorkflowInvoker.Invoke()

Persistensi SQL alur kerja menambahkan kluster kunci primer dan tidak mengizinkan nilai null di beberapa kolom

Detail lebih lanjut

Dimulai dengan .NET Framework 4.7, tabel yang dibuat untuk SQL Workflow Instance Store (SWIS) oleh skrip SqlWorkflowInstanceStoreSchema.sql menggunakan kunci primer terkluster. Karena itu, identitas tidak mendukung nilai null. Pengoperasian SWIS tidak terpengaruh oleh perubahan ini. Pembaruan dibuat untuk mendukung Replikasi Transaksional SQL Server.

Saran

File SQL SqlWorkflowInstanceStoreSchemaUpgrade.sql harus diterapkan ke penginstalan yang ada untuk mengalami perubahan ini. Penginstalan database baru akan secara otomatis memiliki perubahan.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

.NET Framework 4.7.1

JIT

Pembuatan kode yang salah saat meneruskan dan membandingkan nilai UInt16

Detail lebih lanjut

Karena perubahan yang diperkenalkan dalam .NET Framework 4.7, dalam beberapa kasus kode yang dihasilkan oleh pengompilasi JIT dalam aplikasi yang berjalan pada .NET Framework 4.7 salah membandingkan dua T:System.UInt16 nilai. Untuk informasi selengkapnya, lihat Masalah #11508: Codegen buruk senyap saat meneruskan dan membandingkan args ushort pada GitHub.com.

Saran

Jika Anda mengalami masalah dalam perbandingan nilai 16-bit yang tidak ditandatangani di .NET Framework 4.7, tingkatkan ke .NET Framework 4.7.1.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Keamanan

RSACng dan DSACng sekali lagi dapat digunakan dalam skenario Kepercayaan Parsial

Detail lebih lanjut

CngLightup (digunakan dalam beberapa api kripto tingkat lebih tinggi, seperti System.Security.Cryptography.Xml.EncryptedXml) dan System.Security.Cryptography.RSACng dalam beberapa kasus mengandalkan kepercayaan penuh. Ini termasuk P/Invokes tanpa menegaskan SecurityPermissionFlag.UnmanagedCode izin, dan jalur kode di mana System.Security.Cryptography.CngKey memiliki permintaan izin untuk SecurityPermissionFlag.UnmanagedCode. Dimulai dengan .NET Framework 4.6.2, CngLightup digunakan untuk beralih ke System.Security.Cryptography.RSACng sedapat mungkin. Akibatnya, aplikasi dengan kepercayaan parsial yang telah berhasil menggunakan System.Security.Cryptography.Xml.EncryptedXml mulai gagal dan melempar pengecualian SecurityException. Perubahan ini menambahkan pernyataan yang diperlukan agar semua fungsi yang menggunakan CngLightup memiliki izin yang diperlukan.

Saran

Jika perubahan ini dalam .NET Framework 4.6.2 berdampak negatif pada aplikasi kepercayaan parsial Anda, tingkatkan ke .NET Framework 4.7.1.

API yang terpengaruh

• DSACng(CngKey)
• DSACng.Key
• DSACng.LegalKeySizes
• DSACng.CreateSignature(Byte[])
• DSACng.VerifySignature(Byte[], Byte[])
• RSACng(CngKey)
• RSACng.Key
• RSACng.Decrypt(Byte[], RSAEncryptionPadding)
• RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)

Windows Communication Foundation (WCF)

WCF AddressHeaderCollection akan melempar ArgumentException sekarang jika elemen addressHeader adalah null

Detail lebih lanjut

Dimulai dengan .NET Framework 4.7.1, konstruktor AddressHeaderCollection(IEnumerable<AddressHeader>) akan melempar ArgumentException jika salah satu elemennya adalah null. Dalam .NET Framework 4.7 dan versi yang lebih lama, tidak ada pengecualian yang dilemparkan.

Saran

Jika Anda mengalami masalah kompatibilitas dengan perubahan ini pada .NET Framework 4.7.1 atau versi yang lebih baru, Anda dapat menolaknya dengan menambahkan baris berikut ke <runtime> bagian file app.config:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
  </runtime>
</configuration>

API yang terpengaruh

• AddressHeaderCollection(IEnumerable<AddressHeader>)

Nilai default WCF MsmqSecureHashAlgorithm sekarang adalah SHA256

Detail lebih lanjut

Dimulai dengan .NET Framework 4.7.1, algoritma penandatanganan pesan default di WCF untuk pesan Msmq adalah SHA256. Dalam .NET Framework 4.7 dan versi yang lebih lama, algoritma penandatanganan pesan default adalah SHA1.

Saran

Jika Anda mengalami masalah kompatibilitas dengan perubahan ini pada .NET Framework 4.7.1 atau yang lebih baru, Anda dapat menolak perubahan dengan menambahkan baris berikut ke <runtime> bagian file app.config Anda:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true" />
  </runtime>
</configuration>

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

WCF PipeConnection.GetHashAlgorithm sekarang menggunakan SHA256

Detail lebih lanjut

Dimulai dengan .NET Framework 4.7.1, Windows Communication Foundation menggunakan hash SHA256 untuk menghasilkan nama acak untuk pipa bernama. Dalam .NET Framework 4.7 dan versi yang lebih lama, ia menggunakan hash SHA1.

Saran

Jika Anda mengalami masalah kompatibilitas dengan perubahan ini pada .NET Framework 4.7.1 atau yang lebih baru, Anda dapat menolaknya dengan menambahkan baris berikut ke <runtime> bagian file app.config Anda:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
  </runtime>
</configuration>

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Windows Presentation Foundation (WPF)

Popup Berantai dengan StaysOpen=False

Detail lebih lanjut

Popup dengan StaysOpen=False seharusnya ditutup saat Anda mengklik di luar Popup. Ketika dua atau beberapa Popup tersebut ditautkan (yaitu satu berisi yang lain), ada banyak masalah, termasuk:

• Buka dua tingkat, klik di luar P2 tetapi di dalam P1. Tidak ada yang terjadi.
• Buka dua tingkat, klik di luar P1. Kedua popup ditutup.
• Buka dan tutup dua tingkat. Kemudian coba buka P2 lagi. Tidak ada yang terjadi.
• Cobalah untuk membuka tiga tingkat. Anda tidak bisa. (Tidak ada yang terjadi atau dua tingkat pertama ditutup, tergantung di mana Anda mengklik.)

Kasus-kasus ini (dan varian lainnya) sekarang berfungsi seperti yang diharapkan.

API yang terpengaruh

• Popup.StaysOpen

Crash di Selektor saat menghapus item dari koleksi INCC yang disesuaikan

Detail lebih lanjut

Hal ini dapat T:System.InvalidOperationException terjadi dalam skenario berikut:

• ItemsSource untuk T:System.Windows.Controls.Primitives.Selector adalah koleksi dengan implementasi kustom dari T:System.Collections.Specialized.INotifyCollectionChanged.
• Item terpilih dihapus dari koleksi.
• Objek T:System.Collections.Specialized.NotifyCollectionChangedEventArgs memiliki P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex = -1 (menunjukkan posisi yang tidak diketahui).

Tumpukan panggilan pengecualian dimulai at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element). Pengecualian ini dapat terjadi di .NET Framework 4.5 jika aplikasi memiliki lebih dari satu utas Dispatcher. Dalam .NET Framework 4.7, pengecualian juga dapat terjadi dalam aplikasi dengan satu utas Dispatcher.

Masalah ini diperbaiki dalam .NET Framework 4.7.1.

Saran

Tingkatkan ke .NET Framework 4.7.1.

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Mengubah ukuran Grid dapat menyebabkan aplikasi menjadi tidak responsif

Detail lebih lanjut

Perulangan tak terbatas dapat terjadi saat tata letak T:System.Windows.Controls.Grid dalam keadaan berikut:

• Definisi baris berisi dua baris bertanda *, keduanya menyatakan MinHeight dan MaxHeight.
• Konten dari baris * tidak melebihi Tinggi Maksimum yang sesuai.
• Tinggi yang tersedia pada Grid terlampaui oleh MinHeight pertama (ditambah baris lain yang bersifat tetap atau otomatis).
• Aplikasi ini menargetkan .NET Framework 4.7, atau ikut serta dalam algoritma alokasi 4.7 dengan mengatur Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false.

Loop bisa juga terjadi dengan lebih dari dua baris, atau dalam kasus serupa untuk kolom. Masalah ini diperbaiki dalam .NET Framework 4.7.1.

Saran

Tingkatkan ke .NET Framework 4.7.1. Atau, jika Anda tidak memerlukan algoritma alokasi 4.7, Anda dapat menggunakan pengaturan konfigurasi berikut:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

.NET Framework 4.7.2

Inti

Izinkan Unicode dalam URI yang menyerupai berkas berbagi UNC

Detail lebih lanjut

Dalam System.Uri, pembuatan URI file yang berisi baik nama berbagi UNC maupun karakter Unicode tidak akan lagi menghasilkan URI dengan keadaan internal yang tidak valid. Perilaku hanya akan berubah ketika semua hal berikut ini benar:

• URI memiliki skema file: dan diikuti oleh empat garis miring atau lebih.
• Nama host dimulai dengan garis bawah atau simbol non-cadangan lainnya.
• URI berisi karakter Unicode.

Saran

Aplikasi yang bekerja dengan URI yang secara konsisten berisi Unicode mungkin saja telah menggunakan perilaku ini untuk mencegah rujukan ke berbagi UNC. Aplikasi tersebut harus menggunakan IsUnc sebagai gantinya.

API yang terpengaruh

• System.Uri

Mendukung notasi URI relatif khusus saat Unicode hadir

Detail lebih lanjut

Uri tidak akan lagi menghasilkan NullReferenceException saat memanggil TryCreate pada URI relatif tertentu yang mengandung Unicode. Reproduksi NullReferenceException paling sederhana adalah di bawah ini, dengan dua pernyataan yang setara:

bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:è", UriKind.RelativeOrAbsolute, out Uri href);

Untuk mereprodusi NullReferenceException, item berikut harus benar:

• URI harus ditentukan sebagai relatif dengan menambahkannya sebelumnya dengan 'http:' dan tidak mengikutinya dengan '//'.
• URI harus berisi Unicode yang dikodekan persen atau simbol yang tidak dicadangkan.

Saran

Pengguna yang bergantung pada perilaku ini untuk melarang URI relatif harus menentukan UriKind.Absolute saat membuat URI.

API yang terpengaruh

• Uri.TryCreate(Uri, Uri, Uri)
• Uri.TryCreate(String, UriKind, Uri)
• Uri.TryCreate(Uri, String, Uri)

Waktu Operasi

Peningkatan validasi sertifikat kepercayaan rantai WCF untuk autentikasi sertifikat Net.Tcp

Detail lebih lanjut

.NET Framework 4.7.2 meningkatkan validasi rantai kepercayaan sertifikat saat menggunakan autentikasi sertifikat dengan keamanan transport pada WCF. Dengan peningkatan ini, sertifikat klien yang digunakan untuk mengautentikasi ke server harus dikonfigurasi untuk autentikasi klien. Demikian pula sertifikat server yang untuk mengautentikasi server harus dikonfigurasi untuk autentikasi server. Dengan perubahan ini, jika sertifikat akar dinonaktifkan, validasi rantai sertifikat gagal. Perubahan yang sama juga dilakukan pada .NET Framework 3.5 dan versi yang lebih baru melalui roll-up keamanan Windows. Anda dapat menemukan informasi selengkapnya di KB 4055269. Perubahan ini aktif secara default dan dapat dinonaktifkan oleh pengaturan konfigurasi.

Saran

• Validasi apakah sertifikasi server dan klien Anda memiliki EKU OID yang diperlukan. Jika tidak, perbarui sertifikasi Anda.

• Validasi jika sertifikat akar Anda tidak valid. Jika demikian, perbarui sertifikat akar.

• Jika Anda tidak dapat memperbarui sertifikat, Anda dapat untuk sementara waktu mengatasi perubahan besar tersebut dengan pengaturan konfigurasi berikut. Namun, memilih keluar dari perubahan akan membuat sistem Anda rentan terhadap masalah keamanan.

  <appSettings>
    <add key="wcf:useLegacyCertificateUsagePolicy" value="true" />
  </appSettings>
  

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Aplikasi Web

Pengaturan aplikasi "dataAnnotations:dataTypeAttribute:disableRegEx" aktif secara default di .NET Framework 4.7.2

Detail lebih lanjut

Di .NET Framework 4.6.1, pengaturan aplikasi (dataAnnotations:dataTypeAttribute:disableRegEx) diperkenalkan yang memungkinkan pengguna menonaktifkan penggunaan ekspresi reguler dalam atribut jenis data (seperti System.ComponentModel.DataAnnotations.EmailAddressAttribute, , System.ComponentModel.DataAnnotations.UrlAttributedan System.ComponentModel.DataAnnotations.PhoneAttribute). Ini membantu mengurangi kerentanan keamanan seperti menghindari kemungkinan serangan Penolakan Layanan menggunakan ekspresi reguler tertentu.
Di .NET Framework 4.6.1, pengaturan aplikasi ini untuk menonaktifkan penggunaan RegEx diatur ke false secara default. Dimulai dengan .NET Framework 4.7.2, sakelar konfigurasi ini diatur ke true secara default untuk lebih mengurangi kerentanan aman untuk aplikasi web yang menargetkan .NET Framework 4.7.2 ke atas.

Saran

Jika Anda menemukan bahwa ekspresi reguler di aplikasi web Anda tidak berfungsi setelah meningkatkan ke .NET Framework 4.7.2, Anda dapat memperbarui pengaturan dataAnnotations:dataTypeAttribute:disableRegEx agar false mengembalikan ke perilaku sebelumnya.

<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.

Windows Presentation Foundation (WPF)

Perilaku petunjuk tombol ditingkatkan di WPF

Detail lebih lanjut

Perilaku KeyTips telah dimodifikasi agar sejalan dengan perilaku di Microsoft Word dan Windows Explorer. Dengan memeriksa apakah status keytip diaktifkan atau tidak dalam kasus SystemKey (khususnya, Key atau F11) yang ditekan, WPF menangani tombol keytip dengan tepat. Petunjuk tombol sekarang dapat menutup menu meskipun dibuka dengan mouse.

Saran

Tidak tersedia

API yang terpengaruh

Tidak dapat dideteksi melalui analisis API.