Bagikan melalui

Menargetkan ulang perubahan untuk migrasi ke .NET Framework 4.6.x

  • Artikel

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

HtmlTextWriter tidak merender elemen <br/> dengan benar

Detail

Dimulai di .NET Framework 4.6, panggilan dan RenderBeginTag(String) dengan elemen hanya akan menyisipkan satu RenderEndTag() <BR /> <BR /> (bukan dua)

Saran

Jika aplikasi bergantung pada tag tambahan <BR />, RenderBeginTag(String) harus dipanggil untuk kedua kalinya. Perhatikan bahwa perubahan perilaku ini hanya memengaruhi aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru. Jadi, opsi lainnya adalah dengan menargetkan versi .NET Framework sebelumnya untuk mendapatkan perilaku lama.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

ClickOnce

Aplikasi yang diterbitkan dengan ClickOnce yang menggunakan sertifikat penandatanganan kode SHA-256 mungkin gagal pada Windows 2003

Detail

File yang dapat dieksekusi ditandatangani dengan SHA256. Sebelumnya, ia ditandatangani dengan SHA1 terlepas dari apakah sertifikat penandatanganan kode berupa SHA-1 atau SHA-256. Ini berlaku untuk:

  • Semua aplikasi yang dibangun dengan Visual Studio 2012 atau yang lebih baru.
  • Aplikasi yang dibangun dengan Visual Studio 2010 atau lebih lama pada sistem dengan .NET Framework 4.5 ada. Selain itu, jika .NET Framework 4.5 atau versi yang lebih baru telah diinstal, manifes ClickOnce juga ditandatangani dengan sertifikat SHA-256 untuk SHA-256 terlepas dari versi .NET Framework yang dikompilasinya.

Saran

Perubahan penandatanganan bagian ClickOnce yang dapat dijalankan hanya memengaruhi sistem Windows Server 2003 saja, karena sistem tersebut mengharuskan agar KB 938397 diinstal. Perubahan dalam penandatanganan manifes dengan SHA-256 bahkan saat aplikasi menargetkan .NET Framework 4.0 atau versi sebelumnya memperkenalkan dependensi runtime bahasa umum pada .NET Framework 4.5 atau versi yang lebih baru.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.5
Jenis Penargetan Ulang

ClickOnce mendukung SHA-256 pada aplikasi yang menargetkan .NET Framework 4.0

Detail

Sebelumnya, aplikasi ClickOnce dengan sertifikat yang ditandatangani dengan SHA-256 akan mengharuskan keberadaan .NET Framework 4.5 atau versi yang lebih baru, meskipun aplikasi ditargetkan 4.0. Sekarang, aplikasi ClickOnce yang ditargetkan .NET Framework 4.0 dapat berjalan di .NET Framework 4.0, meskipun ditandatangani dengan SHA-256.

Saran

Perubahan ini menghilangkan ketergantungan tersebut dan memungkinkan sertifikat SHA-256 digunakan untuk menandatangani aplikasi ClickOnce yang menargetkan .NET Framework 4 dan versi yang lebih lama.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

Core

Alur CurrentCulture dan CurrentUICulture di seluruh tugas

Detail

Dimulai di .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture disimpan di rangkaian System.Threading.ExecutionContext, yang mengalir di seluruh operasi asinkron. Ini berarti bahwa perubahan ke System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture akan tercermin dalam tugas yang kemudian berjalan secara asinkron. Ini berbeda dari perilaku versi .NET Framework yang sebelumnya (yang akan mengatur ulang System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture di semua tugas asinkron).

Saran

Aplikasi yang terpengaruh oleh perubahan ini dapat mengatasinya dengan secara eksplisit mengatur System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang diinginkan sebagai operasi pertama dalam Tugas asinkron. Atau, perilaku lama (tidak mengalir System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) dapat diikutsertakan dengan mengatur tombol kompatibilitas berikut:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Masalah ini telah diperbaiki oleh WPF di .NET Framework 4.6.2. Masalah ini juga telah diperbaiki dalam .NET Frameworks 4.6, 4.6.1 hingga KB 3139549. Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru akan otomatis mendapatkan perilaku yang tepat dalam aplikasi WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) akan dipertahankan di seluruh operasi Dispatcher.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Nama peristiwa ETW tidak boleh hanya berbeda dengan akhiran "Mulai" atau "Berhenti"

Detail

Dalam .NET Framework 4.6 dan 4.6.1, runtime menampilkan ArgumentException ketika dua nama peristiwa Pelacakan Peristiwa untuk Windows (ETW) hanya berbeda dengan akhiran "Mulai" atau "Berhenti" (seperti saat satu peristiwa bernama LogUser dan yang lainnya bernama LogUserStart). Dalam hal ini, runtime tidak dapat membuat sumber kejadian, yang tidak dapat memancarkan pengelogan apa pun.

Saran

Untuk mencegah pengecualian, pastikan bahwa tidak ada dua nama peristiwa yang hanya berbeda dengan akhiran "Mulai" atau "Berhenti". Persyaratan ini dihapus muali dari .NET Framework 4.6.2; runtime dapat membedakan nama peristiwa yang hanya berbeda dengan akhiran "Mulai" dan "Berhenti".

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

Entity Framework

Membangun Entity Framework edmx dengan Visual Studio 2013 dapat gagal disertai kesalahan MSB4062 jika menggunakan tugas EntityDeploySplit atau EntityClean

Detail

Alat MSBuild 12.0 (termasuk dalam Visual Studio 2013) mengubah lokasi file MSBuild, yang menyebabkan file target Entity Framework yang lebih lama menjadi tidak valid. Hasilnya adalah bahwa tugas EntityDeploySplit dan EntityClean gagal karena tidak dapat menemukan Microsoft.Data.Entity.Build.Tasks.dll. Perhatikan bahwa jeda ini disebabkan oleh perubahan toolset (MSBuild/VS), bukan karena perubahan .NET Framework. Hal ini hanya akan terjadi saat meningkatkan versi alat pengembang, bukan saat meningkatkan .NET Framework saja.

Saran

File target Entity Framework diperbaiki untuk berfungsi dengan tata letak MSBuild baru mulai dari .NET Framework 4.6. Meningkatkan ke versi Framework tersebut akan memperbaiki masalah ini. Atau, solusi ini dapat digunakan untuk menambal file target secara langsung.

Nama Nilai
Cakupan Parah
Versi 4.5.1
Jenis Penargetan Ulang

JIT

Ret IL (bahasa perantara) tidak diperbolehkan di wilayah percobaan

Detail

Berbeda dengan kompiler just-in-time JIT64, RyuJIT (digunakan di .NET Framework 4.6) tidak mengizinkan instruksi ret bahasa perantara di wilayah percobaan. Kembali dari wilayah percobaan tidak diizinkan oleh spesifikasi ECMA-335, dan tidak ada kompiler terkelola yang diketahui menghasilkan bahasa perantara tersebut. Namun, kompilator JIT64 akan menjalankan bahasa perantara tersebut jika dihasilkan menggunakan pancaran pantulan.

Saran

Jika aplikasi menghasilkan bahasa perantara yang menyertakan opcode ret di wilayah percobaan, aplikasi dapat menargetkan .NET Framework 4.5 agar menggunakan JIT lama sehingga menghindari jeda ini. Secara alternatif, bahasa perantara yang dihasilkan dapat diperbarui untuk kembali setelah wilayah percobaan.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

Kompilator JIT 64-bit baru di .NET Framework 4.6

Detail

Mulai dari .NET Framework 4.6, pengompilasi JIT 64-bit baru digunakan untuk kompilasi just-in-time. Dalam beberapa kasus, pengecualian tak terduga dilemparkan atau perilaku yang berbeda diamati. Hal ini jarang terjadi jika aplikasi dijalankan menggunakan pengompilasi 32-bit atau pengompilasi JIT 64-bit yang lebih lama. Perubahan ini tidak mempengaruhi kompilator JIT 32-bit. Perbedaan yang diketahui antara lain sebagai berikut:

  • Dalam kondisi tertentu, operasi unboxing dapat melempar NullReferenceException dalam build Rilis dengan pengoptimalan diaktifkan.
  • Dalam beberapa kasus, eksekusi kode produksi dalam badan metode yang besar dapat menimbulkan StackOverflowException.
  • Dalam kondisi tertentu, struktur yang diteruskan ke metode diperlakukan sebagai tipe referensi, bukan sebagai tipe nilai dalam build Rilis. Salah satu manifestasi masalah ini adalah bahwa item individual dalam koleksi muncul dalam urutan yang tidak terduga.
  • Dalam kondisi tertentu, perbandingan nilai UInt16 dengan set bit tinggi miliknya salah jika pengoptimalan diaktifkan.
  • Dalam kondisi tertentu, khususnya saat menginisialisasi nilai larik, inisialisasi memori dengan instruksi bahasa perantara OpCodes.Initblk dapat menginisialisasi memori dengan nilai yang salah. Ini dapat mengakibatkan pengecualian yang tidak tertangani atau output yang salah.
  • Dalam kondisi tertentu yang jarang terjadi, pengujian bit kondisional dapat mengembalikan nilai Boolean yang salah atau melempar pengecualian jika pengoptimalan kompiler diaktifkan.
  • Dalam kondisi tertentu, jika pernyataan if digunakan untuk menguji kondisi sebelum memasuki blok try dan di luar blok try, serta kondisi yang sama dievaluasi di blok catch atau finally, pengompilasi JIT 64-bit baru menghapus kondisi if dari blok catch atau finally ketika mengoptimalkan kode. Akibatnya, kode di dalam pernyataan if di blok catch atau finally dijalankan tanpa syarat.

Saran

Mitigasi masalah yang diketahui
Jika Anda mengalami masalah yang tercantum di atas, Anda dapat mengatasinya dengan melakukan salah satu dari hal berikut ini:

  • Tingkatkan ke .NET Framework 4.6.2. Kompiler 64-bit baru yang disertakan dengan .NET Framework 4.6.2 mengatasi setiap masalah yang diketahui ini.

  • Pastikan versi Windows Anda adalah yang terbaru dengan menjalankan Windows Update. Pembaruan layanan ke .NET Framework 4.6 dan 4.6.1 mengatasi setiap masalah ini kecuali NullReferenceException dalam operasi unboxing.

  • Kompilasi dengan kompilator JIT 64-bit yang lebih lama. Lihat bagian Mitigasi masalah lain untuk informasi lebih lanjut mengenai cara melakukannya. Mitigasi masalah lain
    Jika Anda menemukan perbedaan perilaku lainnya antara kode yang dikompilasi dengan kompiler 64-bit lama dan kompiler JIT 64-bit baru, atau antara versi debug dan rilis aplikasi Anda yang keduanya dikompilasi dengan kompiler JIT 64-bit baru, Anda dapat melakukan hal berikut untuk mengompilasi aplikasi Anda dengan kompiler JIT 64-bit yang lebih lama:

  • Pada basis per aplikasi, Anda dapat menambahkan elemen < ke file konfigurasi aplikasi Anda. Berikut ini menonaktifkan kompilasi dengan kompiler JIT 64-bit baru dan sebagai gantinya menggunakan kompiler JIT 64-bit lama.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Pada basis per pengguna, Anda dapat menambahkan nilai REG_DWORD bernama useLegacyJit ke kunci HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework registri. Nilai 1 memungkinkan kompilator JIT 64-bit lama; nilai 0 menonaktifkannya dan mengaktifkan kompilator JIT 64-bit yang baru.

  • Pada basis per mesin, Anda dapat menambahkan nilai REG_DWORD bernama useLegacyJit ke kunci HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework registri. Nilai 1 memungkinkan kompilator JIT 64-bit lama; nilai 0 menonaktifkannya dan mengaktifkan kompilator JIT 64-bit yang baru. Anda juga dapat memberi tahu kami tentang masalah tersebut dengan melaporkan bug di Microsoft Connect.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

Jaringan

Validasi Sertifikat EKU OID

Detail

Mulai dari .NET Framework 4.6, kelas SslStream atau ServicePointManager melakukan validasi pengidentifikasi objek (OID) penggunaan kunci yang disempurnakan (EKU). Ekstensi penggunaan kunci yang disempurnakan (EKU) adalah kumpulan pengidentifikasi objek (OID) yang menunjukkan aplikasi yang menggunakan kunci. Validasi EKU OID menggunakan panggilan balik sertifikat jarak jauh untuk memastikan bahwa sertifikat jarak jauh memiliki OID yang benar sesuai dengan tujuannya.

Saran

Jika perubahan ini tidak diinginkan, Anda dapat menonaktifkan validasi sertifikat EKU OID dengan menambahkan tombol berikut ke <AppContextSwitchOverrides> di ` file konfigurasi aplikasi Anda:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Penting

Pengaturan ini disediakan hanya untuk kompatibilitas mundur. Penggunaannya tidak disarankan.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Hanya protokol Tls 1.0, 1.1 dan 1.2 yang didukung di System.Net.ServicePointManager dan System.Net.Security.SslStream

Detail

Mulai dari .NET Framework 4.6, kelas ServicePointManager dan SslStream hanya diizinkan untuk menggunakan salah satu dari tiga protokol berikut: Tls1.0, Tls1.1, atau Tls1.2. Protokol SSL3.0 dan cipher RC4 tidak didukung.

Saran

Mitigasi yang direkomendasikan adalah meningkatkan aplikasi sisi server ke Tls1.0, Tls1.1, atau Tls1.2. Jika tindakan ini tidak memungkinkan, atau jika aplikasi klien rusak, maka kelas System.AppContext dapat digunakan untuk menolak fitur ini dengan melakukan salah satu dari dua cara berikut:

  • Dengan mengatur pengalih kompat secara terprogram pada System.AppContext, seperti yang dijelaskan di sini.
  • Dengan menambahkan baris berikut ke bagian <runtime> dari file app.config:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

TLS 1.x secara default meneruskan bendera SCH_SEND_AUX_RECORD ke API SCHANNEL yang mendasarinya

Detail

Saat menggunakan TLS 1.x, .NET Framework bergantung pada API SCHANNEL Windows yang mendasarinya. Mulai dari .NET Framework 4.6, bendera SCH_SEND_AUX_RECORD diteruskan secara default ke SCHANNEL. Ini menyebabkan SCHANNEL membagi data dienkripsi menjadi dua rekaman terpisah, yang pertama sebagai byte tunggal dan yang kedua sebagai n-1 byte. Dalam kasus yang jarang terjadi, ini memutus komunikasi antara klien dan server yang ada yang membuat asumsi bahwa data berada dalam satu rekaman.

Saran

Jika perubahan ini memutus komunikasi dengan server yang sudah ada, Anda dapat menonaktifkan pengiriman bendera SCH_SEND_AUX_RECORD dan memulihkan perilaku sebelumnya yang tidak memisahkan data menjadi rekaman terpisah dengan menambahkan tombol berikut ke elemen <AppContextSwitchOverrides> di bagian <runtime> file konfigurasi aplikasi Anda:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Penting

Pengaturan ini disediakan hanya untuk kompatibilitas mundur. Penggunaannya tidak disarankan.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Communication Foundation (WCF)

Memanggil CreateDefaultAuthorizationContext dengan argumen null telah berubah

Detail

Implementasi dari System.IdentityModel.Policy.AuthorizationContext yang dikembalikan oleh panggilan ke System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) dengan argumen authorizationPolicies null telah mengubah implementasinya dalam .NET Framework 4.6.

Saran

Dalam kasus yang jarang terjadi, aplikasi WCF yang menggunakan autentikasi kustom dapat melihat perbedaan perilaku. Dalam kasus seperti itu, perilaku sebelumnya dapat dipulihkan dengan melakukan salah satu dari dua tindakan berikut:

  • Kompilasi ulang aplikasi Anda untuk menargetkan versi .NET Framework yang lebih lama dari 4.6. Untuk layanan yang dihosting IIS, gunakan elemen <httpRuntime targetFramework="x.x"> untuk menargetkan versi .NET Framework yang lebih lama.

  • Tambahkan baris berikut ke bagian <appSettings> file app.config Anda:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Formulir Windows

Icon.ToBitmap berhasil mengonversi ikon dengan bingkai PNG menjadi objek Bitmap

Detail

Dimulai dengan aplikasi yang menargetkan .NET Framework 4.6, Icon.ToBitmap metode berhasil mengonversi ikon dengan bingkai PNG menjadi objek Bitmap.

Dalam aplikasi yang menargetkan .NET Framework 4.5.2 dan versi yang lebih lama, Icon.ToBitmap metode melemparkan ArgumentOutOfRangeException pengecualian jika objek Ikon memiliki bingkai PNG.

Perubahan ini memengaruhi aplikasi yang dikompresi ulang untuk menargetkan .NET Framework 4.6 dan yang menerapkan penanganan khusus untuk ArgumentOutOfRangeException yang dilemparkan saat objek Ikon memiliki bingkai PNG. Saat berjalan di bawah .NET Framework 4.6, konversi berhasil, ArgumentOutOfRangeException tidak lagi dimunculkan, dan oleh karena itu penangan pengecualian tidak lagi dipanggil.

Saran

Jika perilaku ini tidak diinginkan, Anda dapat mempertahankan perilaku sebelumnya dengan menambahkan elemen berikut ke bagian <runtime> dari file app.config Anda:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Jika file app.config sudah berisi elemen AppContextSwitchOverrides, nilai baru harus digabungkan dengan atribut nilai seperti ini:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Presentation Foundation (WPF)

CurrentCulture tidak dipertahankan di seluruh operasi Dispatcher WPF

Detail

Mulai dari .NET Framework 4.6, perubahan System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang dilakukan dalam System.Windows.Threading.Dispatcher akan hilang di akhir operasi dispatcher tersebut. Demikian pula, perubahan pada System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang dibuat di luar operasi Dispatcher mungkin tidak terlihat saat operasi tersebut dijalankan. Secara praktis, ini berarti bahwa perubahan System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture mungkin tidak mengalir antara panggilan balik antarmuka pengguna WPF dan kode lainnya dalam aplikasi WPF. Ini karena perubahan System.Threading.ExecutionContext yang menyebabkan System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture disimpan dalam konteks eksekusi yang dimulai dengan aplikasi yang menargetkan .NET Framework 4.6. Operasi dispatcher WPF menyimpan konteks eksekusi yang digunakan untuk memulai operasi dan memulihkan konteks sebelumnya ketika operasi selesai. Karena System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture kini merupakan bagian dari konteks tersebut, perubahan pada mereka dalam operasi dispatcher tidak dipertahankan di luar operasi.

Saran

Aplikasi yang terpengaruh oleh perubahan ini dapat mengatasinya dengan menyimpan System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang diinginkan dalam bidang dan memeriksa semua isi operasi Dispatcher (termasuk penangan panggilan balik peristiwa antarmuka pengguna) bahwa System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture yang benar telah diatur. Atau, karena perubahan ExecutionContext yang mendasari perubahan WPF ini hanya memengaruhi aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru, jeda ini dapat dihindari dengan menargetkan .NET Framework 4.5.2.Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru juga dapat mengatasi ini dengan mengatur sakelar kompatibilitas berikut:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Masalah ini telah diperbaiki oleh WPF di .NET Framework 4.6.2. Masalah ini juga telah diperbaiki dalam .NET Frameworks 4.6, 4.6.1 hingga KB 3139549. Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru akan otomatis mendapatkan perilaku yang tepat dalam aplikasi WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) akan dipertahankan di seluruh operasi Dispatcher.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

Pembulatan tata letak WPF margin telah berubah

Detail

Cara di mana margin dibulatkan dan batas dan latar belakang di dalamnya telah berubah. Akibat perubahan ini:

  • Lebar atau tinggi elemen dapat tumbuh atau menyusut paling banyak satu piksel.
  • Penempatan objek dapat bergerak paling banyak satu piksel.
  • Elemen terpusat bisa secara vertikal atau horizontal menyimpang dari pusat maksimal satu piksel. Secara default, tata letak baru ini hanya diaktifkan untuk aplikasi yang menargetkan .NET Framework 4.6.

Saran

Karena modifikasi ini cenderung menghilangkan kliping kontrol WPF kanan atau bawah pada DPI yang tinggi, maka aplikasi yang menargetkan versi .NET Framework yang lebih lama, tetapi yang berjalan pada .NET Framework 4.6 dapat memilih perilaku baru ini dengan menambahkan baris berikut ke bagian <runtime> file app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Aplikasi yang menargetkan .NET Framework 4.6, tetapi ingin agar kontrol WPF dirender menggunakan algoritma tata letak sebelumnya dapat melakukannya dengan menambahkan baris berikut ke bagian <runtime> file app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

XML, XSLT

XmlWriter melempar pada pasangan pengganti yang tidak valid

Detail

Untuk aplikasi yang menargetkan .NET Framework 4.5.2 atau versi sebelumnya, menulis pasangan pengganti yang tidak valid menggunakan penanganan mundur pengecualian tidak selalu memberikan pengecualian. Untuk aplikasi yang menargetkan .NET Framework 4.6, mencoba menulis pasangan pengganti yang tidak valid melempar System.ArgumentException .

Saran

Jika perlu, jeda ini dapat dihindari dengan menargetkan .NET Framework 4.5.2 atau yang lebih lama. Atau, pasangan pengganti yang tidak valid dapat diproses sebelumnya ke dalam xml yang valid sebelum menulisnya.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Validasi Skema XSD sekarang mendeteksi pelanggaran batasan unik dengan benar jika kunci gabungan digunakan dan satu kunci kosong

Detail

Versi .NET Framework sebelum 4.6 memiliki bug yang menyebabkan validasi XSD tidak mendeteksi batasan unik pada kunci gabungan jika salah satu kunci kosong. Di .NET Framework 4.6, masalah ini dikoreksi. Hal Ini akan menghasilkan validasi yang lebih benar, tetapi juga mungkin dapat mengakibatkan beberapa XML tidak memvalidasi yang sebelumnya akan divalidasi.

Saran

Jika validasi .NET Framework 4.0 yang lebih longgar diperlukan, aplikasi validasi dapat menargetkan versi .NET Framework 4.5 (atau versi yang lebih lama). Namun, saat penargetan ulang ke .NET Framework 4.6, tinjauan kode harus dilakukan untuk memastikan bahwa kunci gabungan duplikat (seperti yang dijelaskan dalam deskripsi masalah ini) tidak diharapkan untuk divalidasi.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

.NET Framework 4.6.1

Core

Perubahan karakter pemisah jalur di properti FullName objek ZipArchiveEntry

Detail

Untuk aplikasi yang menargetkan .NET Framework 4.6.1 dan versi yang lebih baru, karakter pemisah jalur telah berubah dari garis miring terbalik ("\") menjadi garis miring ("/") di properti FullName objek ZipArchiveEntry yang dibuat oleh muatan berlebih metode CreateFromDirectory. Perubahan tersebut membuat implementasi .NET sesuai dengan bagian 4.4.17.1 dari Spesifikasi Format File .ZIP dan memungkinkan arsip .ZIP didekompresi di sistem non-Windows.
Dekompresi file zip yang dibuat oleh aplikasi yang menargetkan .NET Framework versi sebelumnya di sistem operasi non-Windows seperti Macintosh gagal mempertahankan struktur direktori. Misalnya, pada Macintosh, ini membuat sekumpulan file yang nama filenya menggabungkan jalur direktori, bersama dengan karakter garis miring terbalik ("\"), dan nama file. Akibatnya, struktur direktori file yang didekompresi tidak dipertahankan.

Saran

Dampak perubahan ini pada file .ZIP yang didekompresi pada sistem operasi Windows oleh API di namespace layanan System.IO .NET Framework harus minimal, karena API ini dapat menangani garis miring ("/") atau garis miring terbalik ("\") dengan lancar sebagai karakter pemisah jalur.
Jika perubahan ini tidak diinginkan, Anda dapat menolaknya dengan menambahkan setelan konfigurasi ke bagian <runtime> file konfigurasi aplikasi Anda. Contoh berikut menunjukkan bagian <runtime> dan tombol untuk menolak Switch.System.IO.Compression.ZipFile.UseBackslash:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Selain itu, aplikasi yang menargetkan versi .NET Framework sebelumnya tetapi berjalan pada .NET Framework 4.6.1 dan versi yang lebih baru dapat ikut serta dalam perilaku ini dengan menambahkan setelan konfigurasi ke bagian <runtime> file konfigurasi aplikasi. Hal berikut ini menunjukkan bagian <runtime> dan tombol Switch.System.IO.Compression.ZipFile.UseBackslash untuk ikut serta.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.1
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Communication Foundation (WCF)

Pengikatan WCF dengan mode keamanan TransportWithMessageCredential

Detail

Mulai dari .NET Framework 4.6.1, pengikatan WCF yang menggunakan mode keamanan TransportWithMessageCredential dapat diatur untuk menerima pesan dengan header "to" yang tidak ditandatangani untuk kunci keamanan asimetris. Secara default, header "to" yang tidak ditandatangani akan terus ditolak di .NET Framework 4.6.1. Header ini hanya akan diterima jika aplikasi memilih mode operasi baru ini menggunakan tombol konfigurasi Switch.System.ServiceModel.AllowUnsignedToHeader.

Saran

Karena ini adalah fitur keikutsertaan, seharusnya tidak memengaruhi perilaku aplikasi yang sudah ada.
Untuk mengontrol apakah perilaku baru digunakan atau tidak, gunakan pengaturan konfigurasi berikut:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Nama Nilai
Cakupan Transparan
Versi 4.6.1
Jenis Penargetan Ulang

API yang Terpengaruh

X509CertificateClaimSet.FindClaims Mempertimbangkan Semua claimTypes

Detail

Dalam aplikasi yang menargetkan .NET Framework 4.6.1, jika kumpulan klaim X509 diinisialisasi dari sertifikat yang memiliki beberapa entri DNS di bidang SAN-nya, metode System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) mencoba mencocokkan argumen claimType dengan semua entri DNS. Sedangkan, untuk aplikasi yang menargetkan versi .NET Framework sebelumnya, metode System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) mencoba mencocokkan argumen claimType hanya dengan entri DNS terakhir.

Saran

Perubahan ini hanya memengaruhi aplikasi yang menargetkan .NET Framework 4.6.1. Perubahan ini dapat dinonaktifkan (atau diaktifkan jika menargetkan .NET Framework sebelum versi 4.6.1) dengan tombol kompatibilitas DisableMultipleDNSEntries.

Nama Nilai
Cakupan Minor
Versi 4.6.1
Jenis Penargetan Ulang

API yang Terpengaruh

Formulir Windows

Application.FilterMessage tidak lagi dilemparkan untuk implementasi re-entrant dari IMessageFilter.PreFilterMessage

Detail

Sebelum .NET Framework 4.6.1, panggilan FilterMessage(Message) dengan PreFilterMessage(Message) yang disebut System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) atau System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (sementara juga memanggil DoEvents()) akan menyebabkan System.IndexOutOfRangeException.

Dimulai dengan aplikasi yang menargetkan .NET Framework 4.6.1, pengecualian ini tidak lagi dilemparkan, dan filter entrant ulang seperti yang dijelaskan di atas dapat digunakan.

Saran

Perlu diketahui bahwa FilterMessage(Message) tidak akan lagi muncul untuk perilaku PreFilterMessage(Message) re-entrant yang dijelaskan di atas. Perubahan ini hanya memengaruhi aplikasi yang menargetkan .NET Framework 4.6.1. Sementara aplikasi yang menargetkan .NET Framework 4.6.1 dapat menolak perubahan ini (atau aplikasi yang menargetkan versi .NET Framework yang lebih lama dapat ikut serta) dengan menggunakan tombol kompatibilitas DontSupportReentrantFilterMessage.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.1
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Presentation Foundation (WPF)

Panggilan ke System.Windows.Input.PenContext.Disable pada sistem yang mendukung sentuhan dapat menimbulkan ArgumentException

Detail

Dalam beberapa keadaan, panggilan ke metode System.Windows internal. Metode Intput.PenContext.Disable pada sistem yang mendukung sentuhan dapat menerapkan T:System.ArgumentException tidak tertangani karena masuknya kembali.

Saran

Masalah ini telah diatasi di .NET Framework 4.7. Untuk mencegah pengecualian, tingkatkan ke .NET Framework mulai dari .NET Framework versi 4.7.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.1
Jenis Penargetan Ulang

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath Menampilkan NullReferenceException

Detail

Di .NET Framework 4.6.2, runtime menampilkan T:System.NullReferenceException saat mengambil nilai P:System.Web.HttpRuntime.AppDomainAppPath yang menyertakan karakter null. Dalam .NET Framework 4.6.1 dan versi sebelumnya, runtime menampilkan T:System.ArgumentNullException.

Saran

Anda dapat melakukan salah satu hal berikut ini untuk menanggapi perubahan ini:

  • Lakukan penanganan T:System.NullReferenceException jika aplikasi Anda berjalan di .NET Framework 4.6.2.
  • Tingkatkan ke .NET Framework 4.7, yang memulihkan perilaku sebelumnya dan melempar T:System.ArgumentNullException.
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Core

Pendekripsi AesCryptoServiceProvider menyediakan transformasi yang dapat digunakan kembali

Detail

Mulai dari aplikasi yang menargetkan .NET Framework 4.6.2, decryptor AesCryptoServiceProvider menyediakan transformasi yang dapat digunakan kembali. Setelah panggilan ke System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), transformasi akan diinisialisasi ulang dan dapat digunakan kembali. Untuk aplikasi yang menargetkan versi .NET Framework yang lebih lama, percobaan untuk menggunakan kembali pendekripsi dengan panggilan System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) setelah panggilan ke System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) akan menampilkan CryptographicException atau menghasilkan data yang rusak.

Saran

Dampak perubahan ini harus minimal, karena ini adalah perilaku yang diharapkan. Aplikasi yang bergantung pada perilaku sebelumnya dapat menolak perubahan ini dengan menambahkan setelan konfigurasi berikut ke bagian <runtime> file konfigurasi aplikasi:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Selain itu, aplikasi yang menargetkan versi .NET Framework sebelumnya tetapi berjalan dengan versi .NET Framework mulai dari .NET Framework 4.6.2 dapat ikut serta dengan menambahkan setelan konfigurasi berikut ke bagian <runtime> file konfigurasi aplikasi:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Nama Nilai
Cakupan Minor
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Panggilan ke konstruktor ClaimsIdentity

Detail

Dimulai dengan .NET Framework 4.6.2, ada perubahan bagaimana ClaimsIdentity konstruktor dengan System.Security.Principal.IIdentity parameter mengatur System.Security.Claims.ClaimsIdentity.Actor properti. Jika System.Security.Principal.IIdentity argumen adalah ClaimsIdentity objek, dan System.Security.Claims.ClaimsIdentity.Actor properti dari ClaimsIdentity objek itu tidak null, maka System.Security.Claims.ClaimsIdentity.Actor properti dilampirkan dengan menggunakan Clone() metode. Dalam Framework 4.6.1 dan versi yang lebih lama, properti System.Security.Claims.ClaimsIdentity.Actor dilampirkan sebagai referensi yang ada. Karena perubahan ini, mulai dari .NET Framework 4.6.2, properti System.Security.Claims.ClaimsIdentity.Actor objek ClaimsIdentity baru tidak sama dengan properti System.Security.Claims.ClaimsIdentity.Actor argumen System.Security.Principal.IIdentity konstruktor. Dalam .NET Framework 4.6.1 dan versi yang lebih lama, itu sama.

Saran

Jika perilaku ini tidak diinginkan, Anda dapat memulihkan perilaku sebelumnya dengan mengatur tombol Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity di file konfigurasi aplikasi Anda ke true. Tindakan ini mengharuskan Anda menambahkan elemen berikut ini ke bagian <runtime> file web.config Anda:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Perubahan normalisasi jalur

Detail

Mulai dari aplikasi yang menargetkan .NET Framework 4.6.2, cara runtime menormalkan jalur telah berubah. Normalisasi jalur melibatkan modifikasi string yang mengidentifikasi jalur atau file agar sesuai dengan jalur yang valid pada sistem operasi target. Normalisasi biasanya melibatkan:

  • Kanonikalisasi komponen dan pemisah direktori.
  • Menerapkan direktori saat ini ke jalur relatif.
  • Mengevaluasi direktori relatif (.) atau direktori induk (..) di suatu jalur.
  • Memangkas karakter yang ditentukan. Dimulai dengan aplikasi yang menargetkan .NET Framework 4.6.2, perubahan normalisasi jalur berikut diaktifkan secara default:
    • Runtime menunda fungsi GetFullPathName sistem operasi untuk menormalkan jalur.
  • Normalisasi tidak lagi melibatkan pemangkasan akhir segmen direktori (seperti spasi di akhir nama direktori).
  • Dukungan untuk sintaks jalur perangkat dengan kepercayaan penuh, termasuk \\.\ dan, untuk API I/O file di mscorlib.dll, \\?\.
  • Runtime tidak memvalidasi jalur sintaks perangkat.
  • Penggunaan sintaks perangkat untuk mengakses aliran data alternatif didukung. Perubahan ini meningkatkan performa sekaligus memungkinkan metode mengakses jalur yang sebelumnya tidak dapat diakses. Aplikasi yang menargetkan .NET Framework 4.6.1 dan versi yang lebih lama, tetapi berjalan di versi .NET Framework 4.6.2 atau versi yang lebih baru tidak terpengaruh oleh perubahan ini.

Saran

Aplikasi yang menargetkan .NET Framework 4.6.2 atau versi yang lebih baru dapat menolak perubahan ini dan menggunakan normalisasi lama dengan menambahkan elemen berikut ke bagian <runtime> file konfigurasi aplikasi:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Aplikasi yang menargetkan .NET Framework 4.6.1 atau yang lebih lama tetapi berjalan pada .NET Framework 4.6.2 atau yang lebih baru dapat mengaktifkan perubahan pada normalisasi jalur dengan menambahkan baris berikut ke bagian <runtime> file .configuration aplikasi:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Nama Nilai
Cakupan Minor
Versi 4.6.2
Jenis Penargetan Ulang

Alur CurrentCulture dan CurrentUICulture di seluruh tugas

Detail

Dimulai di .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture disimpan di rangkaian System.Threading.ExecutionContext, yang mengalir di seluruh operasi asinkron. Ini berarti bahwa perubahan ke System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture akan tercermin dalam tugas yang kemudian berjalan secara asinkron. Ini berbeda dari perilaku versi .NET Framework yang sebelumnya (yang akan mengatur ulang System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture di semua tugas asinkron).

Saran

Aplikasi yang terpengaruh oleh perubahan ini dapat mengatasinya dengan secara eksplisit mengatur System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang diinginkan sebagai operasi pertama dalam Tugas asinkron. Atau, perilaku lama (tidak mengalir System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) dapat diikutsertakan dengan mengatur tombol kompatibilitas berikut:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Masalah ini telah diperbaiki oleh WPF di .NET Framework 4.6.2. Masalah ini juga telah diperbaiki dalam .NET Frameworks 4.6, 4.6.1 hingga KB 3139549. Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru akan otomatis mendapatkan perilaku yang tepat dalam aplikasi WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) akan dipertahankan di seluruh operasi Dispatcher.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang

API yang Terpengaruh

Nama peristiwa ETW tidak boleh hanya berbeda dengan akhiran "Mulai" atau "Berhenti"

Detail

Dalam .NET Framework 4.6 dan 4.6.1, runtime menampilkan ArgumentException ketika dua nama peristiwa Pelacakan Peristiwa untuk Windows (ETW) hanya berbeda dengan akhiran "Mulai" atau "Berhenti" (seperti saat satu peristiwa bernama LogUser dan yang lainnya bernama LogUserStart). Dalam hal ini, runtime tidak dapat membuat sumber kejadian, yang tidak dapat memancarkan pengelogan apa pun.

Saran

Untuk mencegah pengecualian, pastikan bahwa tidak ada dua nama peristiwa yang hanya berbeda dengan akhiran "Mulai" atau "Berhenti". Persyaratan ini dihapus muali dari .NET Framework 4.6.2; runtime dapat membedakan nama peristiwa yang hanya berbeda dengan akhiran "Mulai" dan "Berhenti".

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6
Jenis Penargetan Ulang

Dukungan jalur panjang

Detail

Mulai dari aplikasi yang menargetkan .NET Framework 4.6.2, jalur panjang (hingga 32K karakter) didukung, dan batasan 260 karakter (atau MAX_PATH) panjang jalur telah dihapus. Untuk aplikasi yang dikompilasi ulang untuk menargetkan .NET Framework 4.6.2, jalur kode yang sebelumnya melemparkan System.IO.PathTooLongException karena jalur melebihi 260 karakter kini akan melemparkan System.IO.PathTooLongException hanya dalam kondisi berikut:

  • Panjang jalur lebih dari MaxValue (32,767) karakter.
  • Sistem operasi mengembalikan COR_E_PATHTOOLONG atau setara. Untuk aplikasi yang menargetkan .NET Framework 4.6.1 dan versi sebelumnya, runtime bahasa umum secara otomatis menampilkan System.IO.PathTooLongException setiap kali jalur melebihi 260 karakter.

Saran

Untuk aplikasi yang menargetkan .NET Framework 4.6.2, Anda dapat menolak dukungan jalur panjang jika tidak diinginkan dengan menambahkan hal-hal yang berikut ini ke bagian <runtime> file app.config Anda:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

Untuk aplikasi yang menargetkan versi .NET Framework yang lebih lama tetapi berjalan pada .NET Framework 4.6.2 atau yang lebih baru, Anda dapat memilih dukungan jalur panjang dengan menambahkan yang berikut ini ke bagian <runtime> file app.config Anda:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Nama Nilai
Cakupan Minor
Versi 4.6.2
Jenis Penargetan Ulang

Pemeriksaan titik dua jalur lebih ketat

Detail

Dalam .NET Framework 4.6.2, sejumlah perubahan dilakukan untuk mendukung jalur yang sebelumnya tidak didukung (panjang dan format). Pemeriksaan sintaks pemisah drive (titik dua) yang tepat dilakukan dengan lebih baik, yang memiliki efek samping pemblokiran beberapa jalur URI di beberapa API Jalur yang dipilih yang sebelumnya ditoleransi.

Saran

Jika meneruskan URI ke API yang terpengaruh, ubah string menjadi jalur legal terlebih dahulu.

  • Hapus skema dari URL secara manual (misalnya, hapus file:// dari URL).

  • Teruskan URI ke kelas Uri dan gunakan LocalPath.

Atau, Anda dapat menolak normalisasi jalur baru dengan mengatur tombol Switch.System.IO.UseLegacyPathHandling AppContext ke true.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Keamanan

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

Detail

Dalam versi .NET Framework sebelum 4.6.2, pelanggan dengan ukuran kunci non-standar untuk sertifikat RSA tidak dapat mengakses kunci tersebut melalui System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) metode System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) dan ekstensi. A System.Security.Cryptography.CryptographicException dengan pesan "Ukuran kunci yang diminta tidak didukung" dilemparkan. Dalam .NET Framework 4.6.2, masalah ini telah diperbaiki. Demikian pula, ImportParameters(RSAParameters) dan ImportParameters(RSAParameters) kini berfungsi dengan ukuran kunci non-standar tanpa melemparkan System.Security.Cryptography.CryptographicException.

Saran

Jika ada logika penanganan pengecualian yang bergantung pada perilaku sebelumnya di mana System.Security.Cryptography.CryptographicException dilemparkan saat ukuran kunci non-standar digunakan, pertimbangkan untuk menghapus logika.

Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

SignedXml.GetPublicKey mengembalikan RSACng di net462 (atau lightup) tanpa perubahan penargetan ulang

Detail

Dimulai dengan .NET Framework 4.6.2, jenis konkret objek yang dikembalikan oleh metode SignedXml.GetPublicKey berubah (tanpa quirk) dari implementasi CryptoServiceProvider ke implementasi Cng. Ini karena implementasi berubah dari menggunakan certificate.PublicKey.Key menjadi menggunakan certificate.GetAnyPublicKey internal yang diteruskan ke RSACertificateExtensions.GetRSAPublicKey.

Saran

Dimulai dengan aplikasi yang berjalan di .NET Framework 4.7.1, Anda dapat menggunakan implementasi CryptoServiceProvider yang digunakan secara default di .NET Framework 4.6.1 dan versi yang lebih lama dengan menambahkan tombol konfigurasi berikut ke bagian runtime bahasa umum pada file konfigurasi aplikasi Anda:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Communication Foundation (WCF)

Kebuntuan dapat terjadi ketika menggunakan layanan Reentrant

Detail

Kebuntuan dapat terhadi di layanan Reentrant, yang membatasi instans layanan ke satu rangkaian eksekusi pada satu waktu. Layanan yang rentan mengalami masalah ini akan memiliki ServiceBehaviorAttribute berikut dalam kode mereka:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Saran

Untuk mengatasi masalah ini, Anda dapat melakukan hal berikut:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Instal pembaruan terbaru .NET Framework 4.6.2, atau tingkatkan ke versi .NET Framework yang lebih baru. Tindakan ini akan menonaktifkan alur ExecutionContext di OperationContext.Current. Perilaku ini dapat dikonfigurasi; setara dengan menambahkan pengaturan aplikasi berikut ke file konfigurasi Anda:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Untuk layanan Reentrant, nilai Switch.System.ServiceModel.DisableOperationContextAsyncFlow tidak boleh diatur ke false.

Nama Nilai
Cakupan Minor
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

OperationContext.Current dapat mengembalikan null saat dipanggil dalam klausul penggunaan

Detail

OperationContext.Current dapat mengembalikan null dan NullReferenceException dapat dihasilkan jika semua kondisi berikut terpenuhi:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Saran

Untuk mengatasi masalah ini, Anda dapat melakukan hal berikut:

  • Ubah kode Anda sebagai berikut untuk membuat instans non-objek null Current baru:

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Instal pembaruan terbaru .NET Framework 4.6.2, atau tingkatkan ke versi .NET Framework yang lebih baru. Ini menonaktifkan alur ExecutionContext di dalam OperationContext.Current dan memulihkan perilaku aplikasi WCF di .NET Framework 4.6.1 dan versi yang lebih lama. Perilaku ini dapat dikonfigurasi; setara dengan menambahkan pengaturan aplikasi berikut ke file konfigurasi Anda:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Jika perubahan ini tidak diinginkan, dan aplikasi Anda bergantung pada konteks eksekusi yang mengalir di antara konteks operasi, Anda dapat mengaktifkan alurnya sebagai berikut:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Keamanan transportasi WCF mendukung sertifikat yang disimpan menggunakan CNG

Detail

Mulai dari aplikasi yang menargetkan .NET Framework 4.6.2, keamanan transportasi WCF mendukung sertifikat yang disimpan menggunakan Windows Cryptography Library (CNG). Dukungan ini terbatas untuk sertifikat dengan kunci umum yang memiliki eksponen dengan panjang tidak lebih dari 32 bit. Ketika aplikasi menargetkan .NET Framework 4.6.2, fitur ini akan aktif secara default. Dalam versi .NET Framework yang lebih lama, upaya untuk menggunakan sertifikat X509 dengan penyedia penyimpanan kunci CSG melemparkan pengecualian.

Saran

Aplikasi yang menargetkan .NET Framework 4.6.1 dan yang lebih lama tetapi berjalan pada .NET Framework 4.6.2 dapat mengaktifkan dukungan untuk sertifikat CNG dengan menambahkan baris berikut ke bagian <runtime> file app.config atau web.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Ini juga dapat dilakukan secara terprogram dengan kode berikut:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Perhatikan bahwa, karena perubahan ini, setiap kode penanganan pengecualian yang bergantung pada upaya untuk memulai komunikasi aman dengan sertifikat CNG yang gagal tidak akan dijalankan lagi.

Nama Nilai
Cakupan Minor
Versi 4.6.2
Jenis Penargetan Ulang

Formulir Windows

Penerapan MemberDescriptor.Equals yang salah

Detail

Penerapan asli dari metode MemberDescriptor.Equals membandingkan dua properti string yang berbeda dari objek yang dibandingkan: nama kategori dan string deskripsi. Cara mengatasinya adalah membandingkan Category objek pertama dengan Category objek kedua, dan Description objek pertama dengan Description objek kedua.

Saran

Jika aplikasi Anda bergantung pada MemberDescriptor.Equals yang terkadang mengembalikan false saat deskriptor setara, dan Anda menargetkan .NET Framework 4.6.2 atau versi yang lebih baru, Anda memiliki beberapa opsi:

  • Buat perubahan kode untuk membandingkan bidang Category dan Description secara manual selain dengan memanggil metode MemberDescriptor.Equals.
  • Tolak perubahan ini dengan menambahkan nilai berikut ke file app.config:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Jika aplikasi Anda menargetkan .NET Framework 4.6.1 atau yang lebih lama dan berjalan pada .NET Framework 4.6.2 atau yang lebih baru dan Anda ingin perubahan ini diaktifkan, Anda dapat mengatur pengalihan kompatibilitas ke false dengan menambahkan nilai berikut ke file app.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Nama Nilai
Cakupan Azure Stack Edge
Versi 4.6.2
Jenis Penargetan Ulang

API yang Terpengaruh

Windows Presentation Foundation (WPF)

CurrentCulture tidak dipertahankan di seluruh operasi Dispatcher WPF

Detail

Mulai dari .NET Framework 4.6, perubahan System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang dilakukan dalam System.Windows.Threading.Dispatcher akan hilang di akhir operasi dispatcher tersebut. Demikian pula, perubahan pada System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang dibuat di luar operasi Dispatcher mungkin tidak terlihat saat operasi tersebut dijalankan. Secara praktis, ini berarti bahwa perubahan System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture mungkin tidak mengalir antara panggilan balik antarmuka pengguna WPF dan kode lainnya dalam aplikasi WPF. Ini karena perubahan System.Threading.ExecutionContext yang menyebabkan System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture disimpan dalam konteks eksekusi yang dimulai dengan aplikasi yang menargetkan .NET Framework 4.6. Operasi dispatcher WPF menyimpan konteks eksekusi yang digunakan untuk memulai operasi dan memulihkan konteks sebelumnya ketika operasi selesai. Karena System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture kini merupakan bagian dari konteks tersebut, perubahan pada mereka dalam operasi dispatcher tidak dipertahankan di luar operasi.

Saran

Aplikasi yang terpengaruh oleh perubahan ini dapat mengatasinya dengan menyimpan System.Globalization.CultureInfo.CurrentCulture atau System.Globalization.CultureInfo.CurrentUICulture yang diinginkan dalam bidang dan memeriksa semua isi operasi Dispatcher (termasuk penangan panggilan balik peristiwa antarmuka pengguna) bahwa System.Globalization.CultureInfo.CurrentCulture dan System.Globalization.CultureInfo.CurrentUICulture yang benar telah diatur. Atau, karena perubahan ExecutionContext yang mendasari perubahan WPF ini hanya memengaruhi aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru, jeda ini dapat dihindari dengan menargetkan .NET Framework 4.5.2.Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru juga dapat mengatasi ini dengan mengatur sakelar kompatibilitas berikut:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Masalah ini telah diperbaiki oleh WPF di .NET Framework 4.6.2. Masalah ini juga telah diperbaiki dalam .NET Frameworks 4.6, 4.6.1 hingga KB 3139549. Aplikasi yang menargetkan .NET Framework 4.6 atau yang lebih baru akan otomatis mendapatkan perilaku yang tepat dalam aplikasi WPF - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) akan dipertahankan di seluruh operasi Dispatcher.

Nama Nilai
Cakupan Minor
Versi 4.6
Jenis Penargetan Ulang