Perubahan runtime untuk migrasi ke .NET Framework 4.6.x
Artikel ini mencantumkan masalah kompatibilitas aplikasi yang diperkenalkan dalam .NET Framework 4.6, 4.6.1, dan 4.6.2.
.NET Framework 4.6
ASP.NET
GridViews dengan AllowCustomPaging yang diatur ke true dapat memicu peristiwa PageIndexChanging saat meninggalkan halaman akhir tampilan
Detail
Bug di .NET Framework 4.5 menyebabkan System.Web.UI.WebControls.GridView.PageIndexChanging terkadang tidak dipicu untuk System.Web.UI.WebControls.GridView yang telah mengaktifkan System.Web.UI.WebControls.GridView.AllowCustomPaging.
Saran
Masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut. Sebagai solusinya, aplikasi dapat melakukan BindGrid eksplisit di semua Page_Load
yang akan mencapai kondisi ini (System.Web.UI.WebControls.GridView ada di halaman terakhir dan System.Web.UI.WebControls.GridView.PageSize terakhir berbeda dengan System.Web.UI.WebControls.GridView.PageSize). Sebagai alternatif, aplikasi dapat dimodifikasi agar penomoran halaman dapat dilakukan (bukan penomoran halaman kustom), karena skenario tersebut tidak menunjukkan masalah.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Inti
ConcurrentDictionary yang diserialisasi di .NET Framework 4.5 dengan NetDataContractSerializer tidak dapat dideserialisasi oleh .NET Framework 4.5.1 atau 4.5.2
Detail
Karena perubahan internal pada jenis tersebut, objek ConcurrentDictionary<TKey,TValue> yang diserialisasi dengan .NET Framework 4.5 dengan menggunakan System.Runtime.Serialization.NetDataContractSerializer tidak dapat dideserialisasi di .NET Framework 4.5.1 atau di .NET Framework 4.5.2. Perlu diperhatikan bahwa kebalikan dari upaya ini (serialisasi dengan .NET Framework 4.5.x dan deserialisasi dengan .NET Framework 4.5) dapat dilakukan. Demikian pula, semua serialisasi lintas versi 4.x berfungsi dengan .NET Framework 4.6. Serialisasi dan deserialisasi dengan satu versi .NET Framework tidak terpengaruh.
Saran
Jika perlu untuk menserialisasikan dan mendeserialisasi System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> antara .NET Framework 4.5 dan .NET Framework 4.5.1/4.5.2, serializer yang berbeda seperti System.Runtime.Serialization.DataContractSerializer yang harus digunakan alih-alih System.Runtime.Serialization.NetDataContractSerializer. Atau, karena masalah ini dibahas dalam .NET Framework 4.6, masalah ini dapat diselesaikan dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5.1 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
AppDomainSetup.DynamicBase tidak lagi diacak oleh UseRandomizedStringHashAlgorithm
Detail
Sebelum .NET Framework 4.6, nilai DynamicBase akan diacak di antara domain aplikasi, atau di antara proses, jika UseRandomizedStringHashAlgorithm diaktifkan dalam file konfigurasi aplikasi. Mulai .NET Framework 4.6, DynamicBase akan mengembalikan hasil yang stabil di antara berbagai instans aplikasi yang berjalan, dan di antara berbagai domain aplikasi. Basis dinamis akan tetap berbeda untuk aplikasi yang berbeda; perubahan ini hanya menghapus elemen penamaan acak untuk instans berbeda dari aplikasi yang sama.
Saran
Perhatikan bahwa mengaktifkan UseRandomizedStringHashAlgorithm
tidak akan mengakibatkan DynamicBase diacak. Jika diperlukan basis acak, basis tersebut harus dibuat dalam kode aplikasi Anda, bukan melalui API ini.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Memanggil Attribute.GetCustomAttributes pada properti pengindeks tidak lagi menampilkan AmbiguousMatchException jika ambiguitas dapat dipecahkan berdasarkan jenis indeks
Detail
Sebelum .NET Framework 4.6, memanggil GetCustomAttribute(s)
pada properti pengindeks yang berbeda dari properti lain hanya berdasarkan jenis indeks akan menghasilkan System.Reflection.AmbiguousMatchException. Mulai dari .NET Framework 4.6, atribut properti akan dikembalikan dengan benar.
Saran
Perlu diketahui bahwa GetCustomAttribute akan bekerja lebih sering sekarang. Jika aplikasi sebelumnya mengandalkan System.Reflection.AmbiguousMatchException, refleksi sekarang harus digunakan untuk secara eksplisit mencari beberapa pengindeks.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
- Attribute.GetCustomAttribute(MemberInfo, Type)
- Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
- Attribute.GetCustomAttributes(MemberInfo)
- Attribute.GetCustomAttributes(MemberInfo, Boolean)
- Attribute.GetCustomAttributes(MemberInfo, Type)
- Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)
COR_PRF_GC_ROOT_HANDLEs tidak disebutkan oleh profiler
Detail
Di .NET Framework v4.5.1, API profil RootReferences2()
tidak pernah mengembalikan COR_PRF_GC_ROOT_HANDLE
secara salah (sebagai gantinya, ia dikembalikan sebagai COR_PRF_GC_ROOT_OTHER
). Masalah ini diperbaiki mulai dari .NET Framework 4.6.
Saran
Masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5.1 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
ETW EventListeners tidak menangkap peristiwa dari penyedia dengan kata kunci eksplisit (seperti penyedia TPL)
Detail
ETW EventListeners dengan masker kata kunci kosong tidak menangkap kejadian dengan benar dari penyedia dengan kata kunci eksplisit. Di .NET Framework 4.5, penyedia TPL mulai menyediakan kata kunci eksplisit dan memicu masalah ini. Di .NET Framework 4.6, EventListeners telah diperbarui agar tidak lagi mengalami masalah ini.
Saran
Untuk mengatasi masalah ini, ganti panggilan ke EnableEvents(EventSource, EventLevel) dengan panggilan ke muatan berlebih enableEvents yang secara eksplisit menentukan masker "kata kunci apa pun" yang akan digunakan: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))
.
Sebagai alternatif, masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Kalender Persia kini menggunakan algoritme surya Hijriah
Detail
Mulai dari .NET Framework 4.6, kelas System.Globalization.PersianCalendar menggunakan algoritma matahari Hijriah. Mengonversi tanggal antara System.Globalization.PersianCalendar dan kalender lainnya dapat menghasilkan hasil yang sedikit berbeda yang dimulai dari .NET Framework 4.6 untuk tanggal yang lebih awal dari 1800 atau lebih baru dari 2023 (Gregorian). Selain itu, PersianCalendar.MinSupportedDateTime sekarang menjadi March 22, 0622
, bukan March 21, 0622
.
Saran
Perhatikan bahwa beberapa tanggal awal atau akhir mungkin sedikit berbeda saat menggunakan PersianCalendar di .NET Framework 4.6. Selain itu, saat melakukan serialisasi tanggal antara proses yang mungkin berjalan di .NET Framework versi yang berbeda, jangan menyimpannya sebagai string tanggal PersianCalendar (karena nilai tersebut mungkin berbeda).
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Objek refleksi tidak dapat lagi diteruskan dari kode terkelola ke klien DCOM yang tidak diproses
Detail
Objek refleksi tidak dapat lagi diteruskan dari kode terkelola ke klien DCOM yang tidak diproses. Jenis berikut terpengaruh:
- System.Reflection.Assembly
- System.Reflection.MemberInfo (dan jenis turunannya, termasuk System.Reflection.FieldInfo, System.Reflection.MethodInfo, System.Type, dan System.Reflection.TypeInfo)
- System.Reflection.MethodBody
- System.Reflection.Module
- System.Reflection.ParameterInfo
Panggilan ke IMarshal
untuk objek akan mengembalikan E_NOINTERFACE
.
Saran
Perbarui kode penyusunan agar berfungsi dengan objek non-refleksi.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
- System.Reflection.Assembly
- System.Reflection.FieldInfo
- System.Reflection.MemberInfo
- System.Reflection.MethodBody
- System.Reflection.MethodInfo
- System.Reflection.Module
- System.Reflection.ParameterInfo
- System.Reflection.TypeInfo
- System.Type
TargetFrameworkName untuk domain aplikasi default tidak lagi bernilai null secara default jika tidak diatur
Detail
System.AppDomainSetup.TargetFrameworkName sebelumnya null di domain aplikasi default, kecuali jika diatur secara eksplisit. Mulai dari .NET Framework 4.6, properti System.AppDomainSetup.TargetFrameworkName domain aplikasi default akan memiliki nilai default yang berasal dari TargetFrameworkAttribute (jika ada). Domain aplikasi non-default akan terus mewarisi System.AppDomainSetup.TargetFrameworkName-nya dari domain aplikasi default (yang nilainya tidak akan diatur ke null secara default di 4.6) kecuali jika diganti secara eksplisit.
Saran
Kode harus diperbarui agar tidak bergantung pada TargetFrameworkName yang nilainya diatur ke null secara default. Jika properti ini harus tetap dievaluasi ke null, properti tersebut dapat secara eksplisit diatur ke nilai tersebut.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
X509Certificate2.ToString(Boolean) kini tidak muncul saat .NET tidak dapat menangani sertifikat
Detail
Di .NET Framework 4.5.2 dan versi yang lebih lama, metode ini akan melemparkan pengecualian jika true
diteruskan untuk parameter verbose, dan ada sertifikat yang diinstal yang tidak didukung oleh .NET Framework. Sekarang, metode ini akan berhasil dan mengembalikan string yang valid yang menghilangkan bagian sertifikat yang tidak dapat diakses.
Saran
Kode apa pun yang bergantung pada X509Certificate2.ToString(Boolean) harus diperbarui agar string yang dikembalikan dapat mengecualikan beberapa data sertifikat (seperti kunci umum, kunci privat, dan ekstensi) dalam beberapa kasus saat API sebelumnya akan dibuang.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Data
Mencoba koneksi TCP/IP ke database SQL Server yang diselesaikan ke localhost
gagal
Detail
Dalam .NET Framework 4.6 dan 4.6.1, mencoba sambungan TCP/IP ke database SQL Server yang menangani ke localhost
gagal dengan kesalahan, "Terjadi kesalahan terkait jaringan atau khusus instans saat membuat sambungan ke SQL Server. Server tak ditemukan atau tak bisa diakses. Verifikasi bahwa nama instans sudah benar dan SQL Server dikonfigurasi untuk memungkinkan koneksi jarak jauh. (penyedia: Antarmuka Jaringan SQL, kesalahan: 26 - Kesalahan Menemukan Server/Instans yang Ditentukan)"
Saran
Masalah ini telah diatasi dan perilaku sebelumnya dipulihkan di .NET Framework 4.6.2. Untuk terhubung ke database SQL Server yang diselesaikan ke localhost
, tingkatkan ke .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Debugger
Nilai penggabungan null tidak akan terlihat di debugger hingga melewati satu langkah berikutnya
Detail
Bug di .NET Framework 4.5 menyebabkan nilai yang ditetapkan melalui operasi penggabungan null tidak langsung terlihat di debugger setelah operasi penetapan dieksekusi saat dijalankan di Framework versi 64-bit.
Saran
Melewati satu waktu tambahan dalam debugger akan menyebabkan nilai lokal/bidang diperbarui dengan benar. Selain itu, masalah ini telah diperbaiki di .NET Framework 4.6; meningkatkan ke versi Framework tersebut akan menyelesaikan masalah.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Jaringan
ContentDisposition DateTimes mengembalikan string yang sedikit berbeda
Detail
Mulai dari .NET Framework 4.6, representasi string System.Net.Mime.ContentDisposition telah diperbarui agar selalu mewakili komponen jam dari System.DateTime dengan dua digit. Representasi ini bertujuan untuk mematuhi RFC822 dan RFC2822. Representasi ini menyebabkan ToString() mengembalikan string yang sedikit berbeda dalam 4.6 dalam skenario saat salah satu elemen waktu disposisi adalah sebelum pukul 10.00. Perhatikan bahwa ContentDispositions terkadang diserialisasi dengan mengubahnya menjadi string, jadi setiap operasi ToString(), serialisasi, atau panggilan GetHashCode harus ditinjau.
Saran
Jangan berharap bahwa representasi string ContentDispositions dari versi .NET Framework yang berbeda akan membandingkan satu sama lain dengan benar. Konversikan string kembali ke ContentDispositions, jika memungkinkan, sebelum melakukan perbandingan.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Serialisasi
Pesan pengecualian telah berubah untuk serialisasi DataContract yang gagal jika terdapat jenis yang tidak diketahui
Detail
Mulai dari .NET Framework 4.6, pesan pengecualian yang diberikan jika System.Runtime.Serialization.DataContractSerializer atau System.Runtime.Serialization.Json.DataContractJsonSerializer gagal melakukan serialisasi atau deserialisasi karena 'jenis yang diketahui' hilang telah diklarifikasi.
Saran
Aplikasi tidak boleh bergantung pada pesan pengecualian tertentu. Jika aplikasi bergantung pada pesan ini, perbarui untuk mengharapkan pesan baru atau (lebih disukai) mengubahnya untuk hanya bergantung pada jenis pengecualian.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
- DataContractJsonSerializer(Type)
- DataContractJsonSerializer(Type, IEnumerable<Type>)
- DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
- DataContractJsonSerializer(Type, String)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>)
- DataContractJsonSerializer(Type, XmlDictionaryString)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
- DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractSerializer(Type)
- DataContractSerializer(Type, DataContractSerializerSettings)
- DataContractSerializer(Type, IEnumerable<Type>)
- DataContractSerializer(Type, String, String)
- DataContractSerializer(Type, String, String, IEnumerable<Type>)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
Penyiapan dan Penyebaran
Perubahan penerapan versi produk di versi .NET Framework 4.6 dan yang lebih baru
Detail
Penerapan versi produk telah berubah dari rilis .NET Framework sebelumnya, dan khususnya dari .NET Framework 4, 4.5, 4.5.1, dan 4.5.2. Berikut ini adalah detail perubahannya:
- Nilai entri
Version
dalam kunciHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
telah berubah menjadi4.6.xxxxx
untuk .NET Framework 4.6 dan rilis titiknya, dan menjadi4.7.xxxxx
untuk .NET Framework 4.7 dan 4.7.1. Di .NET Framework 4.5, 4.5.1, dan 4.5.2, formatnya4.5.xxxxx
. - File dan penerapan versi produk untuk file .NET Framework telah berubah dari skema penerapan versi sebelumnya 4.0.30319.x menjadi 4.6.X.0 untuk .NET Framework 4.6 dan rilis titiknya, dan menjadi 4.7.X.0 untuk .NET Framework 4.7 dan 4.7.1. Anda dapat melihat nilai baru ini saat melihat Properti file setelah mengklik kanan file.
- Atribut AssemblyFileVersionAttribute dan AssemblyInformationalVersionAttribute untuk rakitan terkelola memiliki nilai Versi dalam formulir 4.6.X.0 untuk .NET Framework 4.6 serta rilis poinnya, dan 4.7.X.0 untuk .NET Framework 4.7 dan 4.7.1 .
- Di .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, dan 4.7.1, properti Environment.Version mengembalikan string versi tetap
4.0.30319.42000
. Di .NET Framework 4, 4.5, 4.5.1, dan 4.5.2, ini mengembalikan string versi dalam format4.0.30319.xxxxx
(misalnya, "4.0.30319.18010"). Perhatikan bahwa kami tidak merekomendasikan kode aplikasi mengambil dependensi baru di properti Environment.Version.
Untuk informasi selengkapnya, lihat Cara: Menentukan Versi .NET Framework mana yang Diinstal.
Saran
Secara umum, aplikasi harus bergantung pada teknik yang direkomendasikan untuk mendeteksi hal-hal seperti versi runtime dari .NET Framework dan direktori penginstalan:
- Untuk mendeteksi versi runtime .NET Framework, lihat Cara: Menentukan Versi .NET Framework Mana yang Diinstal.
- Untuk menentukan jalur penginstalan .NET Framework, gunakan nilai entri
InstallPath
di kunciHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
.
Penting
Nama subkunci adalah NET Framework Setup
, bukan .NET Framework Setup
.
- Untuk menentukan jalur direktori ke runtime bahasa umum .NET Framework, panggil metode RuntimeEnvironment.GetRuntimeDirectory().
- Untuk mendapatkan versi CLR, panggil metode RuntimeEnvironment.GetSystemVersion(). Untuk .NET Framework 4 serta rilis poinnya (.NET Framework 4.5, 4.5.1, 4.5.2, dan .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, dan 4.7.1), string v4.0.30319 akan dikembalikan.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
.NET Framework 4.6 tidak menggunakan versi 4.5.x.x saat mendaftarkan dirinya di registri
Detail
Seperti yang diharapkan, kunci versi yang diatur dalam registri (di HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full
) untuk .NET Framework 4.6 dimulai dengan '4.6', bukan '4.5'. Aplikasi yang bergantung pada kunci registri ini untuk mengetahui versi .NET Framework mana yang diinstal pada komputer harus diperbarui untuk memahami bahwa 4.6 adalah versi baru yang mungkin, dan yang kompatibel dengan rilis 4.5.x sebelumnya.
Saran
Perbarui penyelidikan aplikasi untuk penginstalan .NET Framework 4.5 dengan mencari kunci registri 4.5 untuk menerima 4.6 juga.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Windows Communication Foundation (WCF)
Layanan WCF yang menggunakan NETTCP dengan keamanan SSL dan autentikasi sertifikat MD5
Detail
.NET Framework 4.6 menambahkan TLS 1.1 dan TLS 1.2 ke daftar protokol default SSL WCF. Jika komputer klien maupun server menginstal .NET Framework 4.6 atau versi yang lebih baru, TLS 1.2 akan digunakan untuk negosiasi. TLS 1.2 tidak mendukung autentikasi sertifikat MD5. Akibatnya, jika pelanggan menggunakan sertifikat MD5, klien WCF akan gagal tersambung ke layanan WCF.
Saran
Anda dapat mengatasi masalah ini sehingga klien WCF dapat menyambung ke server WCF dengan melakukan salah satu hal berikut ini:
- Perbarui sertifikat agar tidak menggunakan algoritma MD5. Pembaruan ini adalah solusi yang direkomendasikan.
- Jika pengikatan tidak dikonfigurasi secara dinamis dalam kode sumber, perbarui file konfigurasi aplikasi untuk menggunakan TLS 1.1 atau versi protokol yang lebih lama. Tindakan ini memungkinkan Anda terus menggunakan sertifikat dengan algoritma hash MD5.
Peringatan
Solusi ini tidak direkomendasikan, karena sertifikat dengan algoritma hash MD5 dianggap tidak aman.
File konfigurasi berikut melakukan hal berikut:
<configuration>
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding>
<security mode= "None/Transport/Message/TransportWithMessageCredential" >
<transport clientCredentialType="None/Windows/Certificate"
protectionLevel="None/Sign/EncryptAndSign"
sslProtocols="Ssl3/Tls1/Tls11">
</transport>
</security>
</binding>
</netTcpBinding>
</bindings>
</system.ServiceModel>
</configuration>
- Jika pengikatan dikonfigurasi secara dinamis dalam kode sumber, perbarui properti TcpTransportSecurity.SslProtocols untuk menggunakan TLS 1.1 (SslProtocols.Tls11 atau versi protokol yang lebih lama dalam kode sumber.
Peringatan
Solusi ini tidak direkomendasikan, karena sertifikat dengan algoritma hash MD5 dianggap tidak aman.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Windows Presentation Foundation (WPF)
Mengakses item yang dipilih WPF DataGrid dari penangan peristiwa UnloadingRow DataGrid dapat menyebabkan NullReferenceException
Detail
Dikarenakan bug di .NET Framework 4.5, penanganan aktivitas untuk peristiwa DataGrid yang melibatkan penghapusan baris dapat menyebabkan System.NullReferenceException muncul jika mereka mengakses properti System.Windows.Controls.Primitives.Selector.SelectedItem atau System.Windows.Controls.Primitives.MultiSelector.SelectedItems milik DataGrid.
Saran
Masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Memanggil Items.Refresh pada ListBox, ListView, atau DataGrid WPF dengan item yang dipilih dapat menyebabkan item duplikat muncul di elemen
Detail
Di .NET Framework 4.5, memanggil ListBox.Items.Refresh dari kode saat item dipilih di System.Windows.Controls.ListBox dapat menyebabkan item yang dipilih diduplikasi dalam daftar. Masalah serupa terjadi dengan System.Windows.Controls.ListView dan System.Windows.Controls.DataGrid. Masalah ini diperbaiki di .NET Framework 4.6.
Saran
Masalah ini dapat diatasi dengan membatalkan pilihan item secara terprogram sebelum System.Windows.Data.CollectionView.Refresh() dipanggil lalu memilihnya kembali setelah panggilan selesai. Sebagai alternatif, masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nilai | |
---|---|
Cakupan | Minor |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
CoerceIsSelectionBoxHighlighted
Detail
Urutan tindakan tertentu yang melibatkan System.Windows.Controls.ComboBox dan sumber datanya dapat menghasilkan System.NullReferenceException.
Saran
Jika memungkinkan, tingkatkan ke .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Masalah pengikatan ListBoxItem IsSelected dengan ObservableCollection<T>.Move
Detail
Memanggil Move(Int32, Int32) atau MoveItem(Int32, Int32) pada koleksi yang diikat ke System.Windows.Controls.ListBox dengan item yang dipilih dapat menyebabkan perilaku tak menentu dengan pilihan di masa mendatang atau pembatalan pilihan item System.Windows.Controls.ListBox.
Saran
Memanggil System.Collections.ObjectModel.Collection<T>.Remove(T) dan System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) alih-alih Move(Int32, Int32) akan mengatasi masalah ini. Sebagai alternatif, masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Mengeklik kanan header baris WPF DataGrid akan mengubah pilihan DataGrid
Detail
Mengklik kanan header baris System.Windows.Controls.DataGrid yang dipilih saat beberapa baris dipilih menghasilkan perubahan pilihan System.Windows.Controls.DataGrid hanya untuk baris tersebut.
Saran
Masalah ini telah diperbaiki di .NET Framework 4.6 dan dapat diatasi dengan meningkatkan ke versi .NET Framework tersebut.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
WPF menghasilkan proses wisptis.exe yang dapat membekukan mouse
Detail
Masalah diperkenalkan di 4.5.2 yang menyebabkan wisptis.exe
muncul yang dapat membekukan input mouse.
Saran
Perbaikan untuk masalah ini tersedia dalam rilis layanan .NET Framework 4.5.2 (hotfix rollup 3026376), atau dengan meningkatkan ke .NET Framework 4.6
Nama | Nilai |
---|---|
Cakupan | Parah |
Versi | 4.5.2 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Pemeriksaan ejaan WPF dalam kontrol dengan dukungan teks tidak akan berfungsi dalam Windows 10 untuk bahasa yang tidak ada dalam daftar bahasa input OS
Detail
Saat berjalan di Windows 10, pemeriksa ejaan mungkin tidak berfungsi untuk kontrol dengan dukungan teks WPF, karena kemampuan pemeriksaan ejaan platform hanya tersedia untuk bahasa yang ada dalam daftar bahasa input. Di Windows 10, saat bahasa ditambahkan ke daftar keyboard yang tersedia, Windows secara otomatis mengunduh dan menginstal paket Feature on Demand (FOD) yang sesuai, yang menyediakan kemampuan pemeriksaan ejaan. Dengan menambahkan bahasa ke daftar bahasa input, pemeriksa ejaan akan didukung.
Saran
Perhatikan bahwa bahasa atau teks yang ejaannya akan diperiksa harus ditambahkan sebagai bahasa input agar pemeriksaan ejaan berfungsi di Windows 10.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Jendela WPF dirender tanpa dipotong saat ukurannya meluas di luar satu monitor
Detail
Di .NET Framework 4.6 yang berjalan di Windows 8 atau versi yang lebih baru, seluruh jendela dirender tanpa dipotong ketika ukurannya meluas ke luar satu layar, saat ada beberapa monitor yang digunakan. Fenomena ini berbeda dengan versi .NET Framework sebelumnya, yang akan memotong jendela WPF yang meluas melebihi satu tampilan.
Saran
Perilaku ini (apakah akan terpotong atau tidak) dapat diatur secara eksplisit menggunakan elemen <EnableMultiMonitorDisplayClipping>
di <appSettings>
dalam file konfigurasi aplikasi, atau dengan mengatur properti EnableMultiMonitorDisplayClipping
saat memulai aplikasi.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
.NET Framework 4.6.1
Alat
Contract.Invariant atau Contract.Requires<TException> tidak menganggap String.IsNullOrEmpty murni
Detail
Untuk aplikasi yang menargetkan .NET Framework 4.6.1, jika kontrak invarian untuk Contract.Invariant atau kontrak prasyarat untuk Requires memanggil metode String.IsNullOrEmpty, pihak yang melakukan regenerasi mengeluarkan peringatan pengompilasi CC1036: "Ada panggilan yang terdeteksi ke metode 'System. String.IsNullOrWhiteSpace(System.String)' tanpa [Pure] dalam metode." Ini merupakan peringatan pengompilasi, dan bukan kesalahan pengompilasi.
Saran
Perilaku ini telah diatasi dalam Masalah GitHub #339. Untuk menghilangkan peringatan ini, Anda dapat mengunduh dan mengompilasi versi terbaru kode sumber untuk alat Kontrak Kode dari GitHub. Informasi terkait unduhan dapat ditemukan di bagian bawah halaman.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
Windows Presentation Foundation (WPF)
Menggulir item-kan daftar datar dengan item dari tinggi piksel yang berbeda
Detail
Saat System.Windows.Controls.ItemsControl menampilkan koleksi menggunakan virtualisasi (IsVirtualizing=true
) dan pengguliran item (ScrollUnit=Item
), dan saat kontrol bergulir untuk menampilkan item yang tinggi pikselnya berbeda dengan sebelahnya, System.Windows.Controls.VirtualizingStackPanel mengulangi semua item dalam koleksi. Antarmuka pengguna tidak responsif selama perulangan ini. Perulangan terjadi dalam keadaan lain, bahkan dalam rilis .NET Framework sebelumnya. Misalnya, ini terjadi saat pengguliran piksel (ScrollUnit=Pixel
) saat menemukan item dengan tinggi piksel yang berbeda, dan saat data hierarki pengguliran item (seperti System.Windows.Controls.TreeView atau System.Windows.Controls.ItemsControl dengan pengelompokan diaktifkan) saat menemukan item dengan jumlah item keturunan yang berbeda dari tetangganya. Untuk kasus pengguliran item dan tinggi piksel yang berbeda, perulangan diperkenalkan di .NET Framework 4.6.1 untuk memperbaiki bug dalam tata letak data hierarkis. Hal ini tidak diperlukan jika data datar (tidak ada hierarki), dan .NET Framework 4.6.2 tidak melakukannya dalam kasus itu.
Saran
Jika perulangan terjadi di .NET Framework 4.6.1 tetapi tidak di rilis sebelumnya - yakni, jika System.Windows.Controls.ItemsControl menggulir item-kan daftar datar dengan item dengan tinggi piksel yang berbeda-terdapat dua solusi:
- Pasang .NET Framework 4.6.2.
- Pasang perbaikan HR 1605 untuk .NET Framework 4.6.1.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
ObjectDisposedException ditampilkan oleh pemeriksa ejaan WPF
Detail
Aplikasi WPF terkadang mengalami crash saat aplikasi dimatikan disertai System.ObjectDisposedException yang ditampilkan oleh pemeriksa ejaan. Ini diperbaiki di .NET Framework 4,7 WPF dengan menangani pengecualian dengan baik, dan dengan demikian memastikan bahwa aplikasi tidak lagi terpengaruh. Perhatikan bahwa pengecualian kesempatan pertama sesekali akan tetap teramati dalam aplikasi yang berjalan di debugger.
Saran
Tingkatkan ke .NET Framework 4.7
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Pemeriksaan Ejaan WPF gagal dengan cara yang tidak terduga
Detail
Ini termasuk sejumlah masalah Pemeriksa Ejaan WPF:
- Pemeriksa Ejaan WPF terkadang menampilkan System.Runtime.InteropServices.COMException
- Pemeriksa Ejaan WPF gagal dengan UnauthorizedAccessException saat aplikasi diluncurkan menggunakan 'jalankan sebagai pengguna yang berbeda'
- Pemeriksa Ejaan WPF salah mengidentifikasi kesalahan ejaan dalam kata majemuk seperti 'Hausnummer' dalam bahasa Jerman.
Saran
Masalah # 1 - Masalah ini telah diperbaiki di .NET Framework 4.6.2 Masalah # 2 - Pemeriksa Ejaan WPF tidak lagi didukung saat aplikasi diluncurkan menggunakan 'jalankan sebagai pengguna yang berbeda'. Mulai dari .NET Framework 4.6.2, aplikasi yang diluncurkan dengan cara ini tidak akan lagi mengalami crash secara tak terduga - sebaliknya Pemeriksa Ejaan akan dinonaktifkan secara diam-diam. Masalah # 3 - Masalah ini telah diperbaiki di .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
.NET Framework 4.6.2
Data
Mencoba koneksi TCP/IP ke database SQL Server yang diselesaikan ke localhost
gagal
Detail
Dalam .NET Framework 4.6 dan 4.6.1, mencoba sambungan TCP/IP ke database SQL Server yang menangani ke localhost
gagal dengan kesalahan, "Terjadi kesalahan terkait jaringan atau khusus instans saat membuat sambungan ke SQL Server. Server tak ditemukan atau tak bisa diakses. Verifikasi bahwa nama instans sudah benar dan SQL Server dikonfigurasi untuk memungkinkan koneksi jarak jauh. (penyedia: Antarmuka Jaringan SQL, kesalahan: 26 - Kesalahan Menemukan Server/Instans yang Ditentukan)"
Saran
Masalah ini telah diatasi dan perilaku sebelumnya dipulihkan di .NET Framework 4.6.2. Untuk terhubung ke database SQL Server yang diselesaikan ke localhost
, tingkatkan ke .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Periode pemblokiran kumpulan koneksi untuk database Azure SQL dihapus
Detail
Mulai dari .NET Framework 4.6.2, untuk permintaan koneksi terbuka ke database Azure SQL yang diketahui (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), periode pemblokiran kumpulan koneksi dihapus, dan kesalahan koneksi terbuka tidak di-cache. Upaya untuk mencoba kembali permintaan koneksi terbuka akan terjadi segera setelah kesalahan koneksi sementara. Perubahan ini memungkinkan upaya buka koneksi untuk segera dicoba kembali untuk database Azure SQL, sehingga meningkatkan performa aplikasi yang diaktifkan cloud. Untuk semua upaya koneksi lainnya, periode pemblokiran kumpulan koneksi terus diberlakukan.
Di .NET Framework 4.6.1 dan versi yang lebih lama, ketika aplikasi mengalami kegagalan koneksi sementara saat menyambungkan ke database, upaya koneksi tidak dapat dicoba kembali dengan cepat, karena kumpulan koneksi menyimpan kesalahan dan melemparkannya kembali selama 5 detik hingga 1 menit. Untuk informasi selengkapnya, lihat Kumpulan Koneksi SQL Server (ADO.NET). Perilaku ini bermasalah untuk koneksi ke database Azure SQL, yang sering gagal dengan kesalahan sementara yang biasanya dipulihkan dalam beberapa detik. Dengan fitur pemblokiran kumpulan sambungan, aplikasi tidak dapat tersambung ke database dalam jangka waktu yang lama, meskipun database tersedia dan aplikasi perlu dirender dalam beberapa detik.
Saran
Jika perilaku ini tidak diinginkan, periode pemblokiran kumpulan sambungan dapat dikonfigurasi dengan mengatur properti System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod yang diperkenalkan di .NET Framework 4.6.2. Nilai properti adalah anggota dari enumerasi System.Data.SqlClient.PoolBlockingPeriod yang dapat mengambil salah satu dari tiga nilai:
Perilaku sebelumnya dapat dipulihkan dengan mengatur properti System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod ke AlwaysBlock.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Globalisasi
Kategori Unicode standar versi 8.0 kini didukung
Detail
Di .NET Framework 4.6.2, data Unicode telah ditingkatkan dari Unicode Standard versi 6.3 ke versi 8.0. Saat meminta kategori karakter Unicode di .NET Framework 4.6.2, beberapa hasil mungkin tidak cocok dengan hasil di versi .NET Framework sebelumnya. Perubahan ini sebagian besar memengaruhi suku kata Cherokee dan tanda vokal Tai Lue Baru dan tanda nada.
Saran
Tinjau kode dan hapus/ubah logika yang bergantung pada kategori karakter Unicode yang dikodekan secara permanen.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
- Char.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(String, Int32)
Keamanan
RSACng dan DSACng sekali lagi dapat digunakan dalam skenario Kepercayaan Parsial
Detail
CngLightup (digunakan di beberapa api kripto tingkat tinggi, seperti System.Security.Cryptography.Xml.EncryptedXml) dan System.Security.Cryptography.RSACng dalam beberapa kasus mengandalkan kepercayaan penuh. Ini termasuk P/Invokes tanpa menegaskan izin SecurityPermissionFlag.UnmanagedCode, dan jalur kode saat System.Security.Cryptography.CngKey memiliki permintaan izin untuk SecurityPermissionFlag.UnmanagedCode. Mulai .NET Framework 4.6.2, CngLightup dulunya digunakan untuk tombol ke System.Security.Cryptography.RSACng jika memungkinkan. Akibatnya, sebagian aplikasi kepercayaan yang berhasil menggunakan System.Security.Cryptography.Xml.EncryptedXml mulai gagal dan menampilkan pengecualian SecurityException. Perubahan ini menambahkan pernyataan yang diperlukan sehingga semua fungsi yang menggunakan CngLightup memiliki izin yang diperlukan.
Saran
Jika perubahan di .NET Framework 4.6.2 ini berdampak negatif pada aplikasi kepercayaan parsial Anda, tingkatkan ke .NET Framework 4.7.1.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.2 |
Jenis | Runtime |
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)
RSACng.VerifyHash sekarang menampilkan False untuk kegagalan verifikasi apa pun
Detail
Mulai dari .NET Framework 4.6.2, metode ini mengembalikan nilai False jika tanda tangan itu sendiri diformat dengan buruk. Sekarang, metode ini mengembalikan nilai false pada kegagalan verifikasi apa pun. Dalam .NET Framework 4.6 dan versi 4.6.1, metode tersebut melemparkan System.Security.Cryptography.CryptographicException jika tanda tangannya diformat dengan buruk.
Saran
Kode apa pun yang eksekusinya bergantung pada penanganan System.Security.Cryptography.CryptographicException seharusnya dijalankan jika validasi gagal dan metode mengembalikan False.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Perubahan yang Signifikan terhadap SignedXml dan EncryptedXml
Detail
Dalam .NET Framework 4.6.2, perbaikan keamanan di System.Security.Cryptography.Xml.SignedXml dan System.Security.Cryptography.Xml.EncryptedXml menyebabkan perilaku run-time yang berbeda. Misalnya:
- Jika dokumen memiliki beberapa elemen dengan atribut
id
yang sama dan tanda tangan menargetkan salah satu dari elemen tersebut sebagai akar tanda tangan, dokumen sekarang akan dianggap tidak valid. - Dokumen yang menggunakan algoritma transformasi XPath non-kanonik dalam referensi sekarang dianggap tidak valid.
- Dokumen yang menggunakan algoritma transformasi XSLT non-kanonik dalam referensi sekarang dianggap tidak valid.
- Setiap program yang menggunakan tanda tangan terpisah sumber daya eksternal tidak akan dapat melakukannya.
Saran
Pengembang mungkin ingin meninjau penggunaan XmlDsigXsltTransform dan XmlDsigXsltTransform, serta jenis turunan dari Transform karena penerima dokumen mungkin tidak dapat memprosesnya.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
- System.Security.Cryptography.Xml.Transform
- System.Security.Cryptography.Xml.XmlDsigXPathTransform
- System.Security.Cryptography.Xml.XmlDsigXsltTransform
Windows Communication Foundation (WCF)
Hapus Ssl3 dari WCF TransportDefaults
Detail
Saat menggunakan NetTcp dengan keamanan transportasi dan jenis mandat sertifikat, protokol SSL 3 bukan lagi protokol default yang digunakan untuk menegosiasikan koneksi aman. Dalam kebanyakan kasus, seharusnya tidak ada dampak pada aplikasi yang ada karena TLS 1.0 selalu disertakan dalam daftar protokol untuk NetTcp. Semua klien yang sudah ada harus dapat menegosiasikan koneksi dengan menggunakan setidaknya TLS1.0.
Saran
Jika Ssl3 diperlukan, gunakan salah satu mekanisme konfigurasi berikut untuk menambahkan Ssl3 ke daftar protokol yang dinegosiasikan.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Windows Presentation Foundation (WPF)
Mengubah properti IsEnabled induk kontrol TextBlock memengaruhi kontrol turunan apa pun
Detail
Mulai dari .NET Framework 4.6.2, mengubah properti System.Windows.UIElement.IsEnabled induk kontrol System.Windows.Controls.TextBlock memengaruhi kontrol turunan apa pun (seperti hyperlink dan tombol) dari kontrol System.Windows.Controls.TextBlock. Di .NET Framework 4.6.1 dan versi yang lebih lama, kontrol di dalam System.Windows.Controls.TextBlock tidak selalu mencerminkan status properti System.Windows.UIElement.IsEnabled induk System.Windows.Controls.TextBlock.
Saran
Tidak ada. Perubahan ini sesuai dengan perilaku yang diharapkan untuk kontrol di dalam kontrol System.Windows.Controls.TextBlock.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
CoerceIsSelectionBoxHighlighted
Detail
Urutan tindakan tertentu yang melibatkan System.Windows.Controls.ComboBox dan sumber datanya dapat menghasilkan System.NullReferenceException.
Saran
Jika memungkinkan, tingkatkan ke .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6 |
Jenis | Runtime |
API yang Terpengaruh
DataGridCellsPanel.BringIndexIntoView melemparkan ArgumentOutOfRangeException
Detail
ScrollIntoView(Object) akan bekerja secara asinkron ketika virtualisasi kolom diaktifkan tetapi lebar kolom belum ditentukan. Jika kolom dihapus sebelum pekerjaan asinkron terjadi, System.ArgumentOutOfRangeException bisa terjadi.
Saran
Salah satu dari berikut ini:
- Tingkatkan ke .NET Framework 4.7.
- Instal patch layanan terbaru untuk .NET Framework 4.6.2.
- Hindari menghapus kolom hingga respons asinkron untuk ScrollIntoView(Object) selesai.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Pengguliran dan virtualisasi horizontal
Detail
Perubahan ini berlaku untuk System.Windows.Controls.ItemsControl yang melakukan virtualisasinya sendiri ke arah yang ortogonal dengan arah pengguliran utama (contoh utamanya adalah System.Windows.Controls.DataGrid dengan EnableColumnVirtualization="True"). Hasil operasi pengguliran horizontal tertentu telah diubah untuk menghasilkan hasil yang lebih intuitif dan lebih analog dengan hasil operasi vertikal yang sebanding.
Operasi ini termasuk "Gulir Di Sini" dan "Tepi Kanan", untuk menggunakan nama dari menu yang diperoleh dengan mengklik kanan bilah gulir horizontal. Kedua komputasi ini offset kandidat dan panggilan SetHorizontalOffset(Double).
Setelah menggulir ke offset baru, gagasan "di sini" atau "tepi kanan" mungkin telah berubah karena konten yang baru dide-virtualisasi telah mengubah nilai System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.
Sebelum .NET Framework 4.6.2, operasi gulir hanya menggunakan offset kandidat, meskipun mungkin tidak "di sini" atau di "tepi kanan" lagi. Hal ini menghasilkan efek yang mirip seperti "memantulkan" jempol gulir, seperti yang diilustrasikan dalam contoh. Misalkan System.Windows.Controls.DataGrid memiliki ExtentWidth=1000 dan Width=200. Gulir ke "Tepi Kanan" menggunakan offset kandidat 1000 - 200 = 800. Saat menggulir ke offset tersebut, kolom baru tidak divirtualisasi, jadi, misalnya, kolom tersebut sangat luas sehingga System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth berubah menjadi 2000. Gulir berakhir dengan HorizontalOffset=800, dan jempol "memantul" kembali ke dekat tengah bilah gulir - tepatnya pada 800/2000 = 40%.
Perubahannya adalah mengolah ulang offset kandidat baru ketika situasi ini terjadi, dan coba lagi. (Inilah cara kerja pengguliran vertikal.)
Perubahan menghasilkan pengalaman yang lebih dapat diprediksi dan intuitif untuk pengguna akhir, tetapi juga dapat memengaruhi aplikasi apa pun yang tergantung pada nilai System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset yang tepat setelah gulir horizontal, baik dipanggil oleh pengguna akhir atau dengan panggilan eksplisit ke SetHorizontalOffset(Double).
Saran
Aplikasi yang menggunakan nilai yang diprediksi untuk System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset harus diubah agar mengambil nilai yang sebenarnya (dan nilai System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) setelah pengguliran horizontal yang dapat mengubah System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth karena de-virtualisasi.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Items.Clear tidak menghapus duplikat dari SelectedItems
Detail
Misalkan Pemilih (dengan beberapa pilihan diaktifkan) memiliki duplikat dalam koleksi System.Windows.Controls.Primitives.MultiSelector.SelectedItems - item yang sama akan muncul lebih dari sekali. Penghapusan item tersebut dari sumber data (misalnya, dengan memanggil Item.Clear) gagal menghapusnya dari System.Windows.Controls.Primitives.MultiSelector.SelectedItems; hanya instans pertama yang dihapus. Selain itu, penggunaan System.Windows.Controls.Primitives.MultiSelector.SelectedItems berikutnya (misalnya, SelectedItems.Clear()) dapat mengalami masalah seperti System.ArgumentException, karena System.Windows.Controls.Primitives.MultiSelector.SelectedItems berisi item yang tidak lagi berada dalam sumber data.
Saran
Tingkatkan jika memungkinkan ke .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.5 |
Jenis | Runtime |
API yang Terpengaruh
Menggulir item-kan daftar datar dengan item dari tinggi piksel yang berbeda
Detail
Saat System.Windows.Controls.ItemsControl menampilkan koleksi menggunakan virtualisasi (IsVirtualizing=true
) dan pengguliran item (ScrollUnit=Item
), dan saat kontrol bergulir untuk menampilkan item yang tinggi pikselnya berbeda dengan sebelahnya, System.Windows.Controls.VirtualizingStackPanel mengulangi semua item dalam koleksi. Antarmuka pengguna tidak responsif selama perulangan ini. Perulangan terjadi dalam keadaan lain, bahkan dalam rilis .NET Framework sebelumnya. Misalnya, ini terjadi saat pengguliran piksel (ScrollUnit=Pixel
) saat menemukan item dengan tinggi piksel yang berbeda, dan saat data hierarki pengguliran item (seperti System.Windows.Controls.TreeView atau System.Windows.Controls.ItemsControl dengan pengelompokan diaktifkan) saat menemukan item dengan jumlah item keturunan yang berbeda dari tetangganya. Untuk kasus pengguliran item dan tinggi piksel yang berbeda, perulangan diperkenalkan di .NET Framework 4.6.1 untuk memperbaiki bug dalam tata letak data hierarkis. Hal ini tidak diperlukan jika data datar (tidak ada hierarki), dan .NET Framework 4.6.2 tidak melakukannya dalam kasus itu.
Saran
Jika perulangan terjadi di .NET Framework 4.6.1 tetapi tidak di rilis sebelumnya - yakni, jika System.Windows.Controls.ItemsControl menggulir item-kan daftar datar dengan item dengan tinggi piksel yang berbeda-terdapat dua solusi:
- Pasang .NET Framework 4.6.2.
- Pasang perbaikan HR 1605 untuk .NET Framework 4.6.1.
Nama | Nilai |
---|---|
Cakupan | Minor |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
Latar belakang RibbonGroup diatur menjadi transparan di build yang dilokalkan
Detail
Latar belakang System.Windows.Controls.Ribbon.RibbonGroup pada build yang dilokalkan selalu dicat dengan kuas Transparan, sehingga menghasilkan pengalaman UI yang buruk. Masalah ini diperbaiki dalam perbaikan .NET Framework 4.7 WPF dengan memperbarui sumber daya yang dilokalkan untuk System.Windows.Controls.Ribbon.RibbonGroup, yang pada gilirannya memastikan bahwa sikat yang benar dipilih.
Saran
Tingkatkan ke .NET Framework 4.7
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.2 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.
Pemeriksaan Ejaan WPF gagal dengan cara yang tidak terduga
Detail
Ini termasuk sejumlah masalah Pemeriksa Ejaan WPF:
- Pemeriksa Ejaan WPF terkadang menampilkan System.Runtime.InteropServices.COMException
- Pemeriksa Ejaan WPF gagal dengan UnauthorizedAccessException saat aplikasi diluncurkan menggunakan 'jalankan sebagai pengguna yang berbeda'
- Pemeriksa Ejaan WPF salah mengidentifikasi kesalahan ejaan dalam kata majemuk seperti 'Hausnummer' dalam bahasa Jerman.
Saran
Masalah # 1 - Masalah ini telah diperbaiki di .NET Framework 4.6.2 Masalah # 2 - Pemeriksa Ejaan WPF tidak lagi didukung saat aplikasi diluncurkan menggunakan 'jalankan sebagai pengguna yang berbeda'. Mulai dari .NET Framework 4.6.2, aplikasi yang diluncurkan dengan cara ini tidak akan lagi mengalami crash secara tak terduga - sebaliknya Pemeriksa Ejaan akan dinonaktifkan secara diam-diam. Masalah # 3 - Masalah ini telah diperbaiki di .NET Framework 4.6.2.
Nama | Nilai |
---|---|
Cakupan | Azure Stack Edge |
Versi | 4.6.1 |
Jenis | Runtime |
API yang Terpengaruh
Tidak terdeteksi melalui analisis API.