Bagikan melalui

Strategi migrasi keseluruhan

  • Artikel

Pendahuluan

SDK Aplikasi Windows menyediakan serangkaian API Windows yang luas—dengan implementasi yang dipisahkan dari OS, dan dirilis ke pengembang melalui paket NuGet. Sebagai pengembang dengan aplikasi Platform Windows Universal (UWP), Anda dapat memanfaatkan set keterampilan yang ada dengan baik, dan kode sumber Anda, dengan memindahkan aplikasi Anda ke SDK Aplikasi Windows.

Dengan SDK Aplikasi Windows Anda dapat menggabungkan fitur runtime, bahasa, dan platform terbaru ke dalam aplikasi Anda. Karena setiap aplikasi berbeda, dan begitu juga kebutuhan dan preferensi Anda, ada banyak cara berbeda untuk mendekati proses migrasi kode sumber aplikasi Anda. Tetapi pendekatan tingkat tinggi, dan perubahan kode yang diperlukan untuk berbagai area fitur, serupa. Jadi dalam topik ini kami akan meninjau strategi tentang bagaimana Anda dapat mendekati migrasi aplikasi Anda, serta info lebih lanjut (dan batasan) tentang area fitur tertentu. Jadi lihat juga Apa yang didukung saat porting dari UWP ke WinUI 3.

Sebagian besar API Windows Runtime (WinRT) dapat digunakan oleh aplikasi SDK Aplikasi Windows. Tetapi ada beberapa yang tidak didukung di aplikasi desktop, atau memiliki batasan.

  • API yang memiliki dependensi pada fitur UI yang dirancang untuk digunakan hanya di aplikasi UWP.
  • API yang memerlukan identitas paket. API ini hanya didukung di aplikasi desktop yang dibungkus menggunakan MSIX.

Untuk API tersebut, kami akan menunjukkan kepada Anda alternatif apa yang akan digunakan. Sebagian besar alternatif tersebut tersedia di WinUI, atau melalui antarmuka WinRT COM yang tersedia di SDK Aplikasi Windows.

Misalnya, kita akan melihat skenario UI tertentu di mana Anda harus melacak objek jendela utama Anda, dan menggunakan berbagai API berbasis HWND dan pola interoperaksi, seperti IInitializeWithWindow::Initialize.

Catatan

Lihat juga API Windows Runtime yang tidak didukung di aplikasi desktop. SDK Aplikasi Windows aplikasi adalah salah satu jenis aplikasi desktop. Jenis aplikasi desktop lainnya termasuk aplikasi desktop .NET, dan aplikasi desktop C/C++ Win32. Audiens topik tersebut adalah pengembang yang ingin bermigrasi ke apa pun dalam persatuan berbagai jenis aplikasi desktop tersebut, termasuk (tetapi tidak terbatas pada) aplikasi SDK Aplikasi Windows.

Kami senang mendengar umpan balik Anda tentang panduan migrasi ini, dan tentang pengalaman migrasi Anda sendiri. Gunakan bagian Umpan Balik tepat di kaki halaman ini seperti ini:

  • Untuk pertanyaan dan umpan balik tentang SDK Aplikasi Windows, atau hanya untuk memulai diskusi, gunakan tombol Produk ini. Anda juga dapat memulai diskusi pada tab Diskusi dari repositori GitHub WindowsAppSDK. Dengan menggunakan saluran tersebut, Anda juga dapat memberi tahu kami masalah apa yang coba Anda selesaikan, bagaimana Anda telah mencoba menyelesaikannya sejauh ini, dan apa solusi ideal untuk aplikasi Anda.
  • Untuk umpan balik tentang informasi yang hilang atau salah dalam panduan migrasi ini, gunakan tombol Halaman ini.

Mengapa bermigrasi ke SDK Aplikasi Windows?

SDK Aplikasi Windows menawarkan Anda kesempatan untuk meningkatkan aplikasi Anda dengan fitur platform baru, serta dengan Pustaka Windows UI 3 modern (WinUI 3), yang dikembangkan dan dirancang untuk menyenangkan pengguna Anda.

Selain itu, SDK Aplikasi Windows kompatibel mundur; mendukung aplikasi hingga Windows 10, versi 1809 (10.0; Build 17763)—juga dikenal sebagai Pembaruan Windows 10 Oktober 2018.

Proposisi nilai pemindahan SDK Aplikasi Windows dimanifold. Berikut adalah beberapa pertimbangan:

  • Platform dan kontrol antarmuka pengguna (UI) terbaru seperti WinUI 3 dan WebView2.
  • Satu permukaan API di seluruh platform aplikasi desktop.
  • Irama rilis yang lebih sering dirilis secara terpisah dari Windows.
  • Pengalaman yang konsisten di seluruh versi Windows.
  • Kompatibilitas .NET.
  • Kompatibel mundur ke Windows 10, versi 1809.
  • Lingkungan runtime yang ditingkatkan. Lihat kontainer MSIX.

Untuk informasi selengkapnya, lihat SDK Aplikasi Windows.

Gambaran umum proses migrasi

Catatan

Anda dapat memikirkan versi UWP aplikasi yang ingin Anda migrasikan sebagai solusi/proyek sumber (ini adalah sumber proses migrasi). Versi SDK Aplikasi Windows adalah solusi target (ini adalah target proses migrasi).

Menginstal VSIX SDK Aplikasi Windows

Unduh penginstal ekstensi Visual Studio (VSIX) SDK Aplikasi Windows dari saluran rilis Stabil untuk SDK Aplikasi Windows, dan jalankan untuk menginstalnya.

Membuat proyek baru

Di Visual Studio, Buat proyek WinUI 3 pertama Anda. Misalnya, gunakan templat proyek Aplikasi Kosong, Dipaketkan (WinUI 3 di Desktop). Anda dapat menemukan templat proyek tersebut dalam dialog Buat proyek baru dengan memilih bahasa: C# atau C++; platform: SDK Aplikasi Windows; jenis proyek: WinUI atau Desktop.

Anda akan melihat dua proyek dalam Penjelajah Solusi—satu dikualifikasi sebagai (Desktop), dan yang lainnya sebagai (Paket).

Memigrasikan kode dengan dependensi paling sedikit terlebih dahulu

Untuk mengilustrasikan rekomendasi ini, mari kita ambil studi kasus PhotoLab sebagai contoh. Untuk aplikasi sampel PhotoLab, salah satu pendekatan yang mungkin jelas mungkin adalah memulai dengan memigrasikan MainPage—karena itu adalah bagian penting dan menonjol dari aplikasi. Tetapi jika kita harus melakukan itu, maka kita akan segera menyadari bahwa MainPage memiliki dependensi pada tampilan DetailPage; dan kemudian DetailPage tersebut memiliki dependensi pada model Foto. Jika kita mengikuti jalur itu, maka kita mungkin terus-menerus mengganggu diri kita sendiri (beralih untuk bekerja pada setiap dependensi yang baru ditemukan). Tentu saja kita tidak akan berharap untuk mendapatkan build yang bersih sampai kita akan mengejar setiap dependensi, dan pada dasarnya porting seluruh proyek dalam satu lompatan raksasa.

Jika di sisi lain kita memulai dengan potongan proyek yang tidak bergantung pada hal lain, dan bekerja keluar dari sana (dari bagian paling sedikit hingga paling tergantung), maka kita akan dapat fokus pada setiap bagian satu per satu. Dan kami juga dapat mencapai build yang bersih setelah memigrasikan setiap bagian, dan dengan cara itu mengonfirmasi bahwa proses migrasi tetap berjalan.

Jadi saat Anda memigrasikan aplikasi Anda sendiri, kami sarankan Anda memigrasikan kode dengan dependensi paling sedikit terlebih dahulu.

Salin file, atau salin isi file?

Saat bermigrasi, Anda tentu saja akan menyalin file aset (dan bukan konten file aset). Tapi bagaimana dengan file kode sumber? Sebagai contoh mari kita kembali mengambil kelas MainPage dari studi kasus PhotoLab dan studi kasus Editor Foto.

C#. Dalam versi C# (PhotoLab), MainPage terdiri dari file MainPage.xaml kode sumber dan MainPage.xaml.cs.

C++/WinRT. Dalam versi C++/WinRT (Editor Foto), MainPage terdiri dari file MainPage.xamlkode sumber , , MainPage.idl, MainPage.hdan MainPage.cpp.

Jadi Anda memiliki pilihan antara kedua opsi ini:

  • (Disarankan) Anda dapat menyalin file itu sendiri (menggunakan File Explorer), lalu menambahkan salinan ke proyek target. Pengecualian untuk rekomendasi ini adalah file seperti App.xaml dan App.xaml.cs, karena file tersebut sudah ada di proyek target, dan berisi kode sumber yang khusus untuk SDK Aplikasi Windows. Bagi mereka, Anda harus menggabungkan kode sumber yang sudah ada dengan kode sumber dari proyek sumber.
  • Atau Anda dapat menggunakan Visual Studio untuk membuat file Halaman baru (seperti MainPage.xaml dan MainPage.xaml.cs) di proyek target, lalu menyalin konten file kode sumber tersebut dari proyek sumber ke proyek target. Untuk proyek C++/WinRT, opsi ini melibatkan lebih banyak langkah.

Lihat juga bagian MainPage dan MainWindow.

Perbedaan nama folder dan file (C++/WinRT)

Dalam proyek C++/WinRT UWP, file code-behind untuk tampilan XAML diberi nama formulir MainPage.h dan MainPage.cpp. Tetapi dalam SDK Aplikasi Windows C++/WinRT, Anda harus mengganti nama menjadi MainPage.xaml.h dan MainPage.xaml.cpp.

Dalam proyek C++/WinRT UWP, saat memigrasikan tampilan XAML hipotetis (dalam arti model, tampilan, dan viewmodel) bernama MyPage, Anda MyPage.xaml.cpp harus menambahkan #include "MyPage.g.cpp" segera setelah #include "DetailPage.xaml.h". Dan untuk model hipotetis bernama MyModel, tambahkan MyModel.cpp #include "MyModel.g.cpp" segera setelah #include "MyModel.h". Misalnya, lihat Memigrasikan kode sumber DetailPage.

Jika Anda mengubah nama proyek yang dimigrasikan

Saat bermigrasi, Anda mungkin memilih untuk memberi proyek target Anda nama yang berbeda dari proyek sumber. Jika Anda melakukannya, maka itu akan memengaruhi namespace default dalam proyek sumber. Saat Menyalin kode sumber dari proyek sumber ke proyek target, Anda mungkin perlu mengubah nama namespace layanan yang disebutkan dalam kode sumber.

Mengubah nama proyek (dan akibatnya nama namespace default) adalah sesuatu yang kami lakukan, misalnya, dalam kasus studi A SDK Aplikasi Windows migrasi aplikasi sampel UWP PhotoLab (C#). Dalam studi kasus itu, alih-alih menyalin konten file dari sumber ke proyek target, kami menyalin seluruh file menggunakan File Explorer. Nama proyek/namespace sumber adalah PhotoLab, dan nama proyek/namespace target adalah PhotoLabWinUI3. Jadi kita perlu mencari PhotoLab dalam konten file kode sumber apa pun yang kita salin, dan mengubahnya menjadi PhotoLabWinUI3

Dalam studi kasus tertentu, kami membuat perubahan tersebut di App.xaml, , App.xaml.cs, MainPage.xamlMainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.cs, dan LoadedImageBrush.cs.

Instal paket NuGet yang sama yang diinstal dalam proyek sumber

Salah satu tugas selama proses migrasi adalah mengidentifikasi paket NuGet apa pun yang memiliki dependensi proyek sumber. Lalu instal paket NuGet yang sama dalam proyek target.

Misalnya, dalam studi kasus Migrasi SDK Aplikasi Windows aplikasi sampel UWP PhotoLab (C#), proyek sumber berisi referensi ke paket NuGet Microsoft.Graphics.Win2D. Jadi dalam studi kasus itu kami menambahkan referensi ke paket NuGet yang sama ke proyek target.