Bagikan melalui

Membuat paket porting

  • Artikel

Sebaiknya gunakan Asisten Peningkatan .NET Visual Studio untuk memperbarui kode .NET Framework ke versi .NET terbaru. Untuk informasi selengkapnya, lihat blog Meningkatkan proyek .NET Anda dengan Visual Studio.

Penting

Port API tidak digunakan lagi untuk analisis biner dengan alat .NET Upgrade Assistant . Layanan backend Port API telah dimatikan, jadi untuk menggunakan alat ini, Anda harus menggunakannya secara offline. Untuk informasi selengkapnya, lihat .NET API Port README.

Sebelum Anda langsung masuk ke kode, luangkan waktu untuk melalui langkah-langkah pra-migrasi yang direkomendasikan. Artikel ini memberi Anda wawasan tentang jenis masalah yang mungkin Anda temui, dan membantu Anda memutuskan pendekatan yang paling masuk akal.

Port kode Anda

Pastikan Anda mengikuti prasyarat ke kode porting sebelum melanjutkan lebih lanjut. Bersiaplah untuk memutuskan pendekatan terbaik untuk Anda dan mulai kode porting.

Berurusan terutama dengan pengompilasi

Pendekatan ini berfungsi dengan baik untuk proyek atau proyek kecil yang tidak menggunakan banyak API .NET Framework. Pendekatannya sederhana:

  1. Secara opsional, jalankan ApiPort pada proyek Anda. Jika Anda menjalankan ApiPort, dapatkan pengetahuan dari laporan tentang masalah yang perlu Anda atasi.
  2. Salin semua kode Anda ke dalam proyek .NET baru.
  3. Meskipun mengacu pada laporan portabilitas (jika dihasilkan), selesaikan kesalahan pengkompilasi hingga proyek sepenuhnya dikompilasi.

Meskipun tidak terstruktur, pendekatan yang berfokus pada kode ini sering menyelesaikan masalah dengan cepat. Proyek yang hanya berisi model data mungkin merupakan kandidat yang ideal untuk pendekatan ini.

Tetap berada di .NET Framework hingga masalah portabilitas diselesaikan

Pendekatan ini mungkin yang terbaik jika Anda lebih suka memiliki kode yang dikompilasi selama seluruh proses. Pendekatannya adalah sebagai berikut:

  1. Jalankan ApiPort pada proyek.
  2. Atasi masalah dengan menggunakan API berbeda yang portabel.
  3. Perhatikan area apa pun tempat Anda dicegah menggunakan alternatif langsung.
  4. Ulangi langkah-langkah sebelumnya untuk semua proyek yang Anda porting hingga Anda yakin masing-masing siap untuk disalin ke dalam proyek .NET baru.
  5. Salin kode ke dalam proyek .NET baru.
  6. Selesaikan masalah apa pun di mana Anda mencatat bahwa alternatif langsung tidak ada.

Pendekatan yang cermat ini lebih terstruktur daripada sekadar mengatasi kesalahan kompilator, tetapi masih relatif berfokus pada kode dan memiliki manfaat selalu memiliki kode yang dikompilasi. Cara Anda menyelesaikan masalah tertentu yang tidak dapat diatasi hanya dengan menggunakan API lain sangat bervariasi. Anda mungkin menemukan bahwa Anda perlu mengembangkan rencana yang lebih komprehensif untuk proyek tertentu, yang tercakup dalam pendekatan berikutnya.

Mengembangkan rencana serangan yang komprehensif

Pendekatan ini mungkin terbaik untuk proyek yang lebih besar dan lebih kompleks, di mana restrukturisasi kode atau sepenuhnya menulis ulang area kode tertentu mungkin diperlukan untuk mendukung .NET. Pendekatannya adalah sebagai berikut:

  1. Jalankan ApiPort pada proyek.

  2. Pahami di mana setiap jenis non-portabel digunakan dan bagaimana hal itu memengaruhi portabilitas keseluruhan.

    • Pahami sifat jenis-jenis tersebut. Apakah jumlahnya kecil tetapi sering digunakan? Apakah jumlahnya besar tetapi jarang digunakan? Apakah penggunaannya terkonsentrasi, atau tersebar di seluruh kode Anda?
    • Apakah mudah untuk mengisolasi kode yang tidak portabel sehingga Anda dapat menanganinya lebih efektif?
    • Apakah Anda perlu merefaktor kode Anda?
    • Untuk jenis yang tidak portabel, apakah ada API alternatif yang menyelesaikan tugas yang sama? Misalnya, jika Anda menggunakan WebClient kelas , gunakan kelas sebagai gantinya HttpClient .
    • Apakah ada API portabel yang berbeda yang tersedia untuk menyelesaikan tugas, meskipun bukan pengganti drop-in? Misalnya, jika Anda menggunakan XmlSchema untuk mengurai XML tetapi tidak memerlukan penemuan skema XML, Anda dapat menggunakan System.Xml.Linq API dan menerapkan penguraian sendiri alih-alih mengandalkan API.

  3. Jika Anda memiliki rakitan yang sulit di-port, apakah layak untuk meninggalkannya di .NET Framework untuk saat ini? Beberapa hal yang perlu dipertimbangkan:

    • Anda mungkin memiliki beberapa fungsionalitas di pustaka Anda yang tidak kompatibel dengan .NET karena terlalu bergantung pada fungsionalitas .NET Framework atau khusus Windows. Apakah ada baiknya meninggalkan fungsionalitas tersebut untuk saat ini dan merilis versi .NET sementara pustaka Anda dengan lebih sedikit fitur hingga sumber daya tersedia untuk memindahkan fitur?
    • Apakah refaktor akan membantu?

  4. Apakah wajar untuk menulis implementasi Anda sendiri dari .NET Framework API yang tidak tersedia?

    Anda dapat mempertimbangkan untuk menyalin, memodifikasi, dan menggunakan kode dari sumber referensi .NET Framework. Kode sumber referensi dilisensikan di bawah Lisensi MIT, sehingga Anda memiliki kebebasan yang signifikan untuk menggunakan sumber sebagai dasar untuk kode Anda sendiri. Pastikan untuk mengaitkan Microsoft dengan benar dalam kode Anda.

  5. Ulangi proses ini sesuai kebutuhan untuk proyek yang berbeda.

Fase analisis bisa memakan waktu tergantung pada ukuran basis kode Anda. Menghabiskan waktu dalam fase ini untuk benar-benar memahami cakupan perubahan yang diperlukan dan untuk mengembangkan rencana biasanya menghemat waktu Anda pada akhirnya, terutama jika Anda memiliki basis kode yang kompleks.

Rencana Anda dapat melibatkan pembuatan perubahan signifikan pada basis kode Anda sambil tetap menargetkan .NET Framework 4.7.2. Ini adalah versi yang lebih terstruktur dari pendekatan sebelumnya. Cara Anda menjalankan paket bergantung pada basis kode Anda.

Pendekatan campuran

Kemungkinan Anda akan mencampur pendekatan di atas berdasarkan per proyek. Lakukan apa yang paling masuk akal bagi Anda dan untuk basis kode Anda.

Port pengujian Anda

Cara terbaik untuk memastikan semuanya berfungsi ketika Anda telah mem-port kode Anda adalah dengan menguji kode Anda saat Anda mentransfernya ke .NET. Untuk melakukan ini, Anda harus menggunakan kerangka kerja pengujian yang membangun dan menjalankan pengujian untuk .NET. Saat ini, Anda memiliki tiga opsi:

Pada akhirnya, upaya porting sangat bergantung pada bagaimana kode .NET Framework Anda disusun. Cara yang baik untuk mem-port kode Anda adalah dengan memulai dengan dasar pustaka Anda, yang merupakan komponen dasar dari kode Anda. Ini mungkin model data atau beberapa kelas dan metode dasar lainnya yang digunakan secara langsung atau tidak langsung.

  1. Port proyek pengujian yang menguji lapisan pustaka yang saat ini Anda porting.
  2. Salin di atas dasar pustaka Anda ke dalam proyek .NET baru dan pilih versi .NET Standard yang ingin Anda dukung.
  3. Buat perubahan apa pun yang diperlukan untuk mendapatkan kode untuk dikompilasi. Sebagian besar hal ini mungkin memerlukan penambahan dependensi paket NuGet ke file csproj Anda.
  4. Jalankan pengujian dan buat penyesuaian yang diperlukan.
  5. Pilih lapisan kode berikutnya untuk di-port dan ulangi langkah-langkah sebelumnya.

Jika Anda mulai dengan dasar pustaka Anda dan bergerak keluar dari dasar dan menguji setiap lapisan sesuai kebutuhan, porting adalah proses sistematis di mana masalah diisolasi ke satu lapisan kode pada satu waktu.

Langkah berikutnya