Gambaran umum peningkatan aplikasi Formulir Windows

Artikel ini membantu Anda memahami apa yang terlibat dalam meningkatkan aplikasi Formulir Windows dari .NET Framework ke .NET. Formulir Windows didukung pada .NET dan menerima investasi aktif, termasuk kontrol yang lebih baru, peningkatan DPI tinggi, dan pembaruan aksesibilitas. Jika Anda mempertahankan aplikasi Formulir Windows yang ada dan ingin memanfaatkan peningkatan tersebut atau beralih ke versi .NET yang didukung, artikel ini untuk Anda.

Artikel ini membahas alasan untuk meningkatkan, jalur peningkatan yang tersedia, dan pekerjaan persiapan yang membuat peningkatan berjalan lancar. Ini juga menjelaskan teknologi .NET Framework mana yang tidak memiliki padanan di .NET, cara mengatasi kekurangan API menggunakan Windows Compatibility Pack, dan bagaimana perubahan yang menyebabkan inkompatibilitas dapat memengaruhi aplikasi Anda.

Untuk contoh tentang cara meningkatkan, lihat Meningkatkan aplikasi Formulir Windows untuk .NET dengan modernisasi GitHub Copilot.

Mengapa peningkatan

.NET Framework adalah runtime sumber tertutup khusus Windows yang tidak lagi menerima pembaruan fitur. Meskipun terus menerima patch keamanan untuk versi yang didukung, itu tidak mendapat manfaat dari pekerjaan performa, peningkatan bahasa, atau investasi aktif yang .NET lakukan. Jika Anda mempertahankan aplikasi Windows di .NET Framework, meningkatkan ke .NET memberi Anda akses ke platform yang lebih cepat dan lebih mampu yang dikembangkan secara aktif di tempat terbuka.

Tetap terkini pada versi .NET juga penting. Setiap rilis .NET memiliki jendela dukungan yang ditentukan, dan aplikasi yang berjalan pada versi di luar dukungan berhenti menerima patch dan perbaikan keamanan. Lakukan upgrade sebelum dukungan berakhir agar tetap terlindungi.

.NET menawarkan peningkatan kinerja yang signifikan dalam hal waktu mulai runtime, throughput, dan penggunaan memori. Aplikasi desktop di .NET juga mendapat manfaat dari investasi fitur yang sedang berlangsung:

Kontrol terbaru, peningkatan aksesibilitas, dan penyempurnaan dukungan DPI tinggi.
Integrasi yang lebih baik dengan Windows. Beberapa fitur, seperti Mode Gelap pada Windows 11, hanya tersedia di .NET.
Fitur bahasa C# dan Visual Basic yang lebih baru serta alat yang ditingkatkan.
Ekosistem paket NuGet yang kaya yang menargetkan .NET.

.NET merilis versi utama baru setiap tahun, bergantian antara rilis dukungan jangka panjang (LTS) dan dukungan jangka standar (STS):

Rilis LTS didukung selama tiga tahun dan biasanya merupakan pilihan terbaik untuk aplikasi produksi yang lebih memilih stabilitas.
Rilis STS didukung selama 24 bulan dan berguna ketika Anda ingin mengadopsi fitur baru lebih cepat.

Rencanakan irama peningkatan Anda di sekitar tanggal ini sehingga aplikasi Anda selalu berada di versi yang didukung. Untuk versi dan tanggal akhir dukungan yang didukung saat ini, lihat .NET rilis, patch, dan dukungan.

Jalur Peningkatan

Sebagian besar peningkatan termasuk dalam salah satu dari dua kategori. Identifikasi jalur mana yang berlaku untuk aplikasi Anda, lalu gunakan panduan dan alat dalam artikel ini untuk menyelesaikan pekerjaan.

Dari .NET Framework ke .NET: Perubahan paling signifikan.

Format file proyek, beberapa API, dan teknologi tertentu berbeda. Tinjau prasyarat, evaluasi dependensi Anda, dan antisipasi kesenjangan API sebelum memulai.

Setelah aplikasi Anda dibangun dan berjalan di .NET, Anda dapat secara opsional mengadopsi pola yang lebih baru, seperti appsettings.json konfigurasi, injeksi dependensi, atau layanan cloud. Mengadopsi pola ini terpisah dari modernisasi ke .NET dan tidak diperlukan untuk menyelesaikan peningkatan. Untuk ide dan panduan, lihat Memodernisasi setelah meningkatkan ke .NET dari .NET Framework.
Dari versi .NET yang lebih lama ke versi yang lebih baru: Peningkatan cakupan yang lebih kecil.

Tugas utamanya adalah memperbarui moniker framework target, meninjau perubahan yang menyebabkan inkompatibilitas untuk versi yang Anda lewati saat proses upgrade, dan memperbarui dependensi NuGet.

Memutakhirkan dari .NET Framework ke .NET

Meningkatkan dari .NET Framework ke .NET adalah jalur peningkatan paling signifikan dan fokus utama dari bagian ini.

Penting

Meskipun .NET adalah teknologi lintas platform, aplikasi desktop Windows untuk .NET tetap hanya untuk Windows.

Satu perubahan adalah format file proyek. .NET menggunakan format proyek bergaya SDK, yang lebih ringkas daripada format warisan. Anda dapat mengonversi file proyek Anda ke format SDK meskipun masih menargetkan .NET Framework, yang akan mengurangi cakupan perubahan selama proses porting yang sebenarnya dan memberi Anda dasar awal yang lebih baik untuk dikerjakan.

Tidak semua API .NET Framework tersedia di .NET. Beberapa API tampak tersedia tetapi menghasilkan PlatformNotSupportedException saat runtime. Paket Kompatibilitas Windows (Microsoft.Windows.Compatibility paket NuGet) mengisi banyak celah ini dengan menyediakan akses ke API khusus Windows seperti Windows Registri, Windows Log Peristiwa, dan banyak lagi. Untuk detail selengkapnya, lihat Gunakan Paket Kompatibilitas Windows untuk mem-porting kode ke .NET.

Beberapa teknologi .NET Framework tidak setara dalam .NET dan memerlukan pendekatan alternatif, seperti Domain Aplikasi, Keamanan Akses Kode (CAS), dan Windows Workflow Foundation. Untuk informasi selengkapnya, lihat bagian Teknologi kerangka kerja .NET tidak tersedia.

Lakukan audit dependensi pihak ketiga Anda. Kontrol dan pustaka yang hanya menargetkan .NET Framework mungkin tidak berfungsi pada .NET. Pilih paket NuGet yang menargetkan .NET Standard 2.0 atau .NET secara langsung. Untuk paket yang belum di-port, cari alternatif komunitas atau periksa apakah Paket Kompatibilitas Windows mencakup API yang diperlukan.

Peningkatan antarversi .NET

Berpindah dari satu versi .NET ke versi lain—misalnya, dari .NET 9 ke .NET 10—biasanya merupakan upaya yang lebih kecil daripada memodernisasi dari .NET Framework. Tugas utamanya adalah memperbarui properti <TargetFramework> di file proyek Anda ke pengenal framework target yang baru. Misalnya, mengubah net9.0-windows ke net10.0-windows.

Sebelum memperbarui versi target, tinjau dokumentasi perubahan yang menyebabkan ketidakcocokan untuk setiap versi yang Anda lewati. Perubahan yang menyebabkan inkompatibilitas dapat berupa perubahan perilaku, memengaruhi kompatibilitas biner atau kode sumber, atau mengubah perilaku pada waktu desain. Bahkan perbedaan kecil pada versi dapat menyebabkan perubahan yang memengaruhi aplikasi Anda. Tinjau Perubahan yang Menyebabkan Gangguan Kompatibilitas di .NET dan filter berdasarkan rentang versi yang Anda lewati saat memutakhirkan.

Setelah memperbarui kerangka kerja target, perbarui dependensi NuGet Anda. Paket yang menargetkan versi .NET yang lebih lama mungkin memiliki rilis yang lebih baru yang memanfaatkan runtime saat ini. Periksa pembaruan dan utamakan paket yang menargetkan versi yang akan Anda tuju. Beberapa paket mungkin juga memiliki API yang tidak digunakan lagi atau mengubah perilaku dalam versi yang lebih baru, jadi tinjau catatan rilis saat memperbarui.

Modernisasi aplikasi GitHub Copilot

Agen modernisasi GitHub Copilot adalah alat yang direkomendasikan untuk meningkatkan aplikasi Formulir Windows dan WPF. Ini adalah pengalaman end-to-end yang didukung AI yang dibangun ke dalam GitHub Copilot yang menangani seluruh proses peningkatan.

Agen mengikuti alur kerja tiga tahap:

Penilaian. Copilot memeriksa struktur proyek, dependensi, dan pola kode Anda. Ini mengidentifikasi perubahan yang melanggar, masalah kompatibilitas API, pola yang tidak digunakan lagi, dan cakupan peningkatan keseluruhan. Kemudian menyajikan keputusan strategi, seperti urutan peningkatan dan penanganan kompatibilitas, bagi Anda untuk meninjau sebelum melanjutkan.
Perencanaan. Copilot mengonversi penilaian dan pilihan Anda yang dikonfirmasi menjadi rencana peningkatan terperinci, mendokumentasikan strategi peningkatan, pendekatan refaktor, jalur dependensi, dan mitigasi risiko.
Eksekusi. Copilot memecah rencana menjadi tugas berurutan dengan kriteria validasi, menerapkan perbaikan kode, dan menerapkan perubahan secara bertahap. Jika mengalami masalah, masalah tersebut tidak dapat diselesaikan secara otomatis, ia meminta bantuan Anda dan belajar dari koreksi.

Semua status peningkatan disimpan di .github/upgrades/ repositori Anda, sehingga Anda dapat menjeda dan melanjutkan di seluruh sesi atau beralih antar lingkungan pengembangan tanpa kehilangan kemajuan.

Agen mendukung jalur peningkatan ini:

.NET Framework (versi apa pun) ke .NET 8 atau yang lebih baru
.NET Core 1.x–3.x ke .NET 8 atau yang lebih baru
.NET 5-7 hingga .NET 8 atau yang lebih baru
Migrasi ke layanan Azure

Ini tersedia di Visual Studio 2026, Visual Studio 2022 17.14.16+, Visual Studio Code, dan GitHub CLI. Untuk memulai peningkatan di Visual Studio, klik kanan solusi atau proyek Anda di Penjelajah Solusi dan pilih Modernisasi, atau buka jendela Copilot Chat GitHub dan ketik @Modernize. Di Visual Studio Code, buka panel Copilot Chat GitHub dan ketik @modernize-dotnet.

Untuk detail penyiapan dan penggunaan, lihat Apa itu modernisasi GitHub Copilot?.

Teknologi kerangka kerja .NET tidak tersedia

Beberapa teknologi .NET Framework tidak setara dalam .NET dan memerlukan pendekatan alternatif sebelum aplikasi Anda dapat berjalan pada runtime baru. Identifikasi apakah aplikasi Anda bergantung pada salah satu teknologi ini lebih awal, karena mewakili kategori pekerjaan migrasi yang paling mengganggu. Untuk referensi lengkapnya, lihat teknologi .NET Framework yang tidak tersedia di .NET.

Domain aplikasi

AppDomain tidak didukung. Gunakan AssemblyLoadContext untuk pemuatan rakitan dinamis, dan gunakan proses atau kontainer terpisah untuk isolasi. Beberapa member API AppDomain ada, tetapi menghasilkan PlatformNotSupportedException saat runtime.
Jarak Jauh

.NET Remoting tidak didukung. Gunakan System.IO.Pipes atau MemoryMappedFile untuk IPC lokal, atau gRPC dan ASP.NET Core untuk komunikasi lintas komputer. Panggilan ke BeginInvoke() dan EndInvoke() pada objek delegasi juga melemparkan PlatformNotSupportedException.
Keamanan Akses Kode (CAS)

CAS tidak didukung dan bukan lagi batas keamanan. Gunakan batas keamanan tingkat OS seperti virtualisasi, kontainer, atau akun pengguna sebagai gantinya.
Transparansi keamanan

Transparansi keamanan, yang memisahkan kode terkotakpasir dari kode kritis keamanan, tidak lagi didukung sebagai batas keamanan. Seperti CAS, fitur ini bergantung pada penerapan runtime yang tidak disediakan .NET. Gunakan mekanisme isolasi tingkat OS sebagai gantinya.
Windows Workflow Foundation (WF)

WF tidak didukung di .NET. Jika aplikasi Anda menghosting atau menggunakan alur kerja, pertimbangkan CoreWF, port sumber terbuka dari runtime Windows Workflow Foundation yang menargetkan .NET.
System.EnterpriseServices (COM+)

System.EnterpriseServices tidak didukung. Aplikasi yang menggunakan layanan COM+ seperti pengumpulan objek, transaksi, atau keamanan System.EnterpriseServices berbasis peran perlu dirancang ulang untuk menggunakan alternatif. Untuk transaksi terdistribusi, pertimbangkan System.Transactions. Untuk skenario hosting layanan, pertimbangkan ASP.NET Core atau layanan pekerja.

Perlu diketahui bahwa beberapa API di area ini tersedia di .NET, tetapi melemparkan PlatformNotSupportedException saat runtime alih-alih gagal saat waktu kompilasi. Uji aplikasi Anda di .NET sejak awal migrasi untuk mengidentifikasi masalah ini sebelum Anda mengalokasikan sumber daya untuk proses porting penuh.

Sebelum Anda mulai memutakhirkan dari .NET Framework

Sebelum mulai memindahkan aplikasi ke .NET, selesaikan serangkaian langkah persiapan saat proyek Anda masih menargetkan .NET Framework. Melakukan persiapan awal ini terlebih dahulu akan mengurangi cakupan perubahan selama proses upgrade yang sebenarnya dan memberi Anda kondisi awal yang lebih rapi serta sudah tervalidasi untuk memulai. Untuk referensi lengkap, lihat Prasyarat untuk porting code dari .NET Framework.

Tingkatkan alat Anda.

Pastikan Anda menjalankan versi Visual Studio yang mendukung versi .NET yang ingin Anda targetkan. Versi SDK yang lebih baru mencakup dukungan migrasi yang ditingkatkan, penganalisis yang lebih baik, dan templat proyek yang diperbarui. Untuk hubungan antara versi .NET SDK, MSBuild, dan Visual Studio, lihat Hubungan penerapan versi antara SDK .NET, MSBuild, dan Visual Studio.
Target .NET Framework 4.7.2 atau yang lebih baru.

Targetkan ulang proyek Anda ke .NET Framework 4.7.2 atau yang lebih tinggi sebelum porting. Versi ini menyediakan permukaan kompatibilitas API terluas dengan .NET Standard 2.0, yang mengurangi jumlah celah API yang akan Anda temui selama peningkatan.

Di Visual Studio, klik kanan proyek, pilih Properti, lalu ubah dropdown Kerangka Kerja Target menjadi .NET Framework 4.7.2. Kompilasi ulang dan perbaiki masalah apa pun sebelum melanjutkan.
Konversi ke format PackageReference.

Jika proyek Anda menggunakan packages.config file untuk mengelola referensi NuGet, migrasikan ke PackageReference format. PackageReference adalah pendekatan modern dan terintegrasi langsung ke dalam format proyek gaya SDK yang akan Anda adopsi di langkah berikutnya.

Di Visual Studio, klik packages.config kanan di Penjelajah Solusi dan pilih Migrasikan packages.config ke PackageReference. Tinjau output migrasi dan atasi peringatan apa pun sebelum melanjutkan.
Konversi ke format proyek bergaya SDK.

Alihkan file proyek Anda ke format gaya SDK. Proyek gaya SDK lebih ringkas, mendukung beberapa target, dan diperlukan untuk .NET. Konversi ini dapat dilakukan sambil tetap menargetkan .NET Framework, jadi ini adalah langkah persiapan yang aman. Banyak alat konversi menangani ini secara otomatis, atau Anda dapat mengonversi secara manual dengan mengganti konten file proyek dengan setara gaya SDK dan menambahkan kembali properti yang diperlukan.
Perbarui dependensi NuGet.

Perbarui semua paket NuGet ke versi terbarunya dan pilih paket yang menargetkan .NET Standard 2.0, bukan paket yang hanya menargetkan .NET Framework. Ini mengurangi risiko kendala dependensi saat Anda mengubah kerangka kerja target. Tinjau catatan rilis paket untuk mengetahui apakah ada perubahan yang dapat menyebabkan ketidakcocokan yang diperkenalkan dalam versi yang lebih baru.

Semua saran sebelumnya memastikan bahwa proyek Anda dalam keadaan baik sebelum Anda meningkatkan ke .NET.

Paket Kompatibilitas Windows

Salah satu masalah paling umum saat porting dari .NET Framework adalah API yang hilang. .NET Standard sengaja mengecualikan teknologi yang tidak dapat berfungsi di semua platform—seperti Windows Registry, WMI, dan pancaran refleksi—sehingga API tersebut tidak tersedia secara default. Paket Microsoft.Windows.Compatibility NuGet mengisi kesenjangan tersebut. Ini menyediakan sekitar 20.000 API di seluruh area teknologi berikut:

Registri Windows
Log Peristiwa Windows
Instrumentasi Manajemen Windows (WMI)
Penghitung Kinerja Windows
Layanan Direktori
Daftar Kontrol Akses Windows (ACL)
Layanan Windows
Kriptografi Windows
Windows Communication Foundation (WCF)
Port, ODBC, CodeDom, dan banyak lagi

Paket ini berada di atas .NET Standard 2.0 dan sangat berguna saat memodernisasi secara bertahap. Ini memungkinkan Anda membuat aplikasi dan berjalan di .NET terlebih dahulu, lalu mengatasi pemfaktoran ulang yang lebih dalam nanti, tanpa harus menulis ulang penggunaan API khusus Windows di muka.

Untuk menambahkannya ke proyek Anda, instal Microsoft.Windows.Compatibility paket NuGet:

dotnet add package Microsoft.Windows.Compatibility

Untuk detail lengkap, lihat Menggunakan Paket Kompatibilitas Windows untuk mem-porting kode ke .NET.

Perubahan mendasar

Perubahan yang menyebabkan inkompatibilitas merupakan bagian yang umum terjadi dalam setiap pemutakhiran, baik Anda memigrasikan dari .NET Framework maupun berpindah antarversi .NET. Meninjau hal-hal tersebut sebelum Anda memulai akan mencegah kendala tak terduga di tahap akhir migrasi. Untuk referensi lengkap, lihat Melanggar perubahan saat memindah kode.

Perubahan yang memecah termasuk dalam beberapa kategori, dan tidak semuanya menyebabkan kesalahan waktu kompilasi:

Perubahan perilaku memengaruhi cara kerja API saat runtime. Tanda tangan tetap sama, tetapi output, pengecualian yang dilemparkan, atau perilaku internal berubah. Inilah yang paling sulit dideteksi karena tidak menghasilkan kesalahan build.
Perubahan kompatibilitas biner memengaruhi apakah rakitan yang dikompilasi yang ada terus berfungsi tanpa kompilasi ulang. Menghapus atau mengubah permukaan API publik merusak kompatibilitas biner.
Perubahan kompatibilitas sumber mengharuskan Anda mengubah kode sumber sebelum berhasil dikompilasi terhadap versi yang lebih baru.
Perubahan kompatibilitas pada waktu desain memengaruhi cara proyek dibuka dan berperilaku di Visual Studio atau lingkungan desain lainnya.

Saat melakukan porting dari .NET Framework, Anda melewati celah versi besar, sehingga daftar potensi perubahan lebih panjang. Saat meningkatkan antara versi .NET—misalnya, dari .NET 6 ke .NET 9—cakupannya lebih sempit, tetapi setiap versi di antaranya dapat memperkenalkan perubahan yang memengaruhi aplikasi Anda. Tinjau perubahan yang dapat menyebabkan inkompatibilitas pada setiap versi yang Anda lewati, bukan hanya versi target.

Perubahan yang menyebabkan inkompatibilitas yang khusus untuk Formulir Windows didokumentasikan dalam Perubahan yang menyebabkan inkompatibilitas untuk migrasi dari .NET Framework ke .NET. Filter referensi perubahan besar berdasarkan rentang versi yang Anda lewati saat memutakhirkan, lalu tinjau entri yang berlaku untuk API yang digunakan aplikasi Anda.

Tugas pasca-pemutakhiran

Setelah aplikasi Anda dibuat dan berjalan di .NET, selesaikan beberapa tugas pembersihan untuk menghapus artefak yang tersisa dari peningkatan.

Tinjau paket NuGet.

Proses peningkatan mungkin telah memperbarui paket ke versi yang lebih baru. Beberapa versi yang lebih baru tersebut menghapus dependensi yang diperlukan versi yang lebih lama. Setelah peningkatan, periksa setiap paket yang diperbarui dan hapus dependensi transitif yang tidak lagi diperlukan. Tinjau catatan rilis untuk paket yang diperbarui guna mengetahui perubahan perilaku yang tidak menyebabkan galat kompilasi.

Bersihkan artefak NuGet lama.

Jika proyek Anda menggunakan packages.config file untuk mengelola referensi NuGet, proyek tersebut tidak lagi diperlukan setelah bermigrasi ke PackageReference format. Hapus dari proyek Anda. Anda juga dapat menghapus folder lokal packages di direktori proyek atau solusi Anda—NuGet sekarang menyimpan paket di folder cache global di .nuget\packages profil pengguna Anda.

Perbarui System.Configuration referensi.

Sebagian besar aplikasi .NET Framework mereferensikan System.Configuration secara langsung. Setelah memutakhirkan, proyek Anda mungkin masih membawa referensi tersebut. System.Configuration pustaka membaca file app.config untuk konfigurasi runtime. Dalam .NET, gantikan dengan paket NuGet System.Configuration.ConfigurationManager, yang menyediakan cakupan API yang sama tanpa referensi langsung ke assembly framework.

Modernisasi setelah memutakhirkan

Setelah aplikasi berjalan di .NET, Anda dapat mengadopsi pola modern yang tidak tersedia di .NET Framework. Perubahan ini tidak diperlukan untuk menyelesaikan peningkatan, tetapi meningkatkan keberlanjutan dan memanfaatkan investasi aktif dalam .NET. Untuk serangkaian ide yang lebih luas, lihat Memodernisasi setelah meningkatkan ke .NET dari .NET Framework.

Migrasi dari App.config ke appsettings.json.

.NET Framework menggunakan App.config untuk pengaturan run-time seperti string koneksi dan konfigurasi pengelogan. aplikasi .NET biasanya menggunakan appsettings.json sebagai gantinyaMicrosoft.Extensions.Configuration, yang disediakan oleh Paket NuGet. Banyak pustaka—termasuk penyedia logging—tidak lagi mendukung App.config dan beralih ke appsettings.json. Migrasi menyelaraskan aplikasi Anda dengan ekosistem dan menyederhanakan konfigurasi saat Anda menambahkan dependensi baru.

App.config file terus bekerja di .NET melalui System.Configuration.ConfigurationManager paket NuGet, sehingga Anda dapat bermigrasi secara bertahap. Untuk panduan, lihat Konfigurasi di .NET.

Ganti kontrol WebBrowser dengan WebView2 (WPF).

Kontrol WebBrowser didasarkan pada Internet Explorer, yang tidak lagi didukung. WPF untuk .NET dapat menggunakan WebView2 kontrol berdasarkan Microsoft Edge sebagai gantinya. WebView2 menyediakan kontrol browser modern yang dikelola secara aktif dengan peningkatan performa, keamanan, dan dukungan standar web.

Microsoft.Web.WebView2 Tambahkan paket NuGet ke proyek Anda. Bergantung pada versi Windows yang dijalankan pengguna, mereka mungkin perlu menginstal runtime WebView2 secara terpisah. Untuk informasi selengkapnya, lihat Pengenalan Microsoft Edge WebView2.

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-06-26