Strategia di migrazione globale

  • Articolo

Introduzione

Windows App SDK offre un ampio set di API Windows, con implementazioni separate dal sistema operativo e rilasciate agli sviluppatori tramite pacchetti NuGet. Gli sviluppatori con un'applicazione Piattaforma UWP (Universal Windows Platform) possono sfruttare al meglio il set di competenze esistente e il codice sorgente spostando l'app in Windows App SDK.

Con Windows App SDK è possibile incorporare le funzionalità di runtime, linguaggio e piattaforma più recenti nella tua app. Poiché ogni applicazione è diversa e quindi sono i requisiti e le preferenze, esistono molti modi diversi per affrontare il processo di migrazione del codice sorgente dell'app. Tuttavia, l'approccio generale e le modifiche al codice necessarie per varie aree di funzionalità sono simili. In questo argomento verranno quindi esaminate le strategie relative all'approccio alla migrazione dell'app, nonché altre informazioni (e limitazioni) su determinate aree di funzionalità. Si veda anche Elementi supportati durante la conversione da UWP a WinUI 3.

La maggior parte delle API di Windows Runtime (WinRT) può essere usata dalle app di Windows App SDK. Tuttavia, alcune non sono supportate nelle app desktop o hanno restrizioni.

  • Le API con dipendenze dalle funzionalità dell'interfaccia utente progettate per l'uso solo nelle app UWP.
  • API che richiedono l'identità del pacchetto. Questi API sono supportate solo nelle app desktop incluse in pacchetti con MSIX.

Per queste API, verranno visualizzate le alternative da usare. La maggior parte di queste alternative è disponibile in WinUI o tramite interfacce COM WinRT disponibili in Windows App SDK.

Ad esempio, verranno visualizzati alcuni scenari dell'interfaccia utente in cui è necessario tenere traccia dell'oggetto finestra principale e usare varie API basate su HWND e modelli di interoperabilità, ad esempio IInitializeWithWindow::Initialize.

Nota

Si veda inoltre API di Windows Runtime non supportate nelle app desktop. Le app Windows App SDK sono un tipo di app desktop. Altri tipi di app desktop includono app desktop .NET e app desktop Win32 C/C++. Il pubblico di questo argomento è costituito dagli sviluppatori che desiderano eseguire la migrazione a qualsiasi elemento nell'unione di questi diversi tipi di app desktop, tra cui (ma non solo) app di Windows App SDK.

Ci piacerebbe ricevere informazioni su questa guida alla migrazione e sull'esperienza di migrazione personalizzata. Usare la sezione Commenti e suggerimenti direttamente nella parte inferiore di questa pagina, come illustrato di seguito:

  • Per domande e per eventuali commenti e suggerimenti su Windows App SDK, o solo per avviare una discussione, usare il pulsante Questo prodotto. È anche possibile avviare una discussione in Scheda discussioni del repository di GitHub WindowsAppSDK. Usando questi canali, è possibile anche indicare quale problema si stia cercando di risolvere, come si è provato a risolverlo finora e qual è la soluzione ideale per l'app.
  • Per commenti e suggerimenti sulle informazioni mancanti o non corrette in questa guida alla migrazione, usare il pulsante Questa pagina .

Motivo per cui migrare da UWP a Windows App SDK

Windows App SDK offre l'opportunità di migliorare la propria app con nuove funzionalità della piattaforma, nonché con la moderna Libreria dell'interfaccia utente di Windows 3 (WinUI 3), sviluppata e progettata per soddisfare i propri utenti.

Inoltre, Windows App SDK è compatibile con le versioni precedenti; supporta le app fino a Windows 10 versione 1809 (10.0; Build 17763) nota anche come Aggiornamento di Windows 10 (ottobre 2018).

La proposta di valore di spostare Windows App SDK è un'operazione molto semplice. Ecco alcune considerazioni:

  • Piattaforma e controlli dell'interfaccia utente più recenti, ad esempio WinUI 3 e WebView2.
  • Un'unica superficie API su tutte le piattaforme di app desktop.
  • Frequenza di rilascio più frequente che viene rilasciata separatamente da Windows.
  • Un'esperienza coerente tra le versioni di Windows.
  • Compatibilità con .NET
  • Compatibile con le versioni precedenti fino a Windows 10 versione 1809.
  • Ambiente di runtime migliorato. Vedere Contenitore MSIX.

Per ulteriori informazioni, vedere Windows App SDK.

Panoramica del processo di migrazione

Nota

È possibile optare per la versione UWP dell'app di cui si intende eseguire la migrazione come soluzione/progetto di origine (è l'origine del processo di migrazione). La versione Windows app SDK è la soluzione di destinazione (è la destinazione del processo di migrazione).

Installare Windows App SDK VSIX

Scaricare il programma di installazione dell'estensione di Visual Studio Windows App SDK dal canale di versione stabile per Windows App SDK ed eseguirlo per l'installazione.

Crea un nuovo progetto

In Visual Studio creare il primo progetto WinUI 3. Ad esempio, usare il modello di progetto App vuota, inclusa nel pacchetto (WinUI 3 in Desktop).. È possibile trovare il modello di progetto nella finestra di dialogo Crea un nuovo progetto scegliendo il linguaggio: C# o C++; piattaforma: Windows App SDK; tipo di progetto: WinUI o Desktop.

Verranno visualizzati due progetti in Esplora soluzioni: il primo è qualificato come (desktop) e l'altro come (pacchetto).

Eseguire in primo luogo la migrazione del codice con meno dipendenze

Per illustrare questa raccomandazione, prendiamo come esempio il case study PhotoLab. Per l'app campione PhotoLab, un approccio forse ovvio potrebbe essere quello di iniziare eseguendo la migrazione di MainPage, in quanto è un elemento importante e prominente dell'app. Ma se si facesse questo, ci si accorgerebbe ben presto che MainPage ha una dipendenza dalla vista DetailPage; e che DetailPage ha una dipendenza dal modello Photo. Se fosse necessario seguire questo percorso, ci si potrebbe interrompere costantemente (passando a lavorare su ogni dipendenza appena individuata). Certamente non ci si aspetterebbe di ottenere una compilazione pulita fino a quando non avremmo inseguito ogni dipendenza, e essenzialmente si è portato l'intero progetto in un salto gigante.

Se d'altra parte si iniziasse con il pezzo del progetto che non dipende da nient'altro, e si lavorasse verso l'esterno (dal pezzo meno dipendente a quello più dipendente), ci si potrebbe concentrare su ogni pezzo uno alla volta. E si sarebbe anche in grado di ottenere una compilazione pulita dopo la migrazione di ogni pezzo e in questo modo verificare che il processo di migrazione sia sempre in corso.

Pertanto, quando si esegue la migrazione delle proprie app, è consigliabile eseguire prima la migrazione del codice con le dipendenze meno necessarie.

Copiare i file o copiare il contenuto del file?

Quando si esegue la migrazione, naturalmente si eseguirà la copia sui file di asset (e non sul contenuto del file di asset). Tuttavia, cosa dire dei file di codice sorgente? Ad esempio, prendiamo di nuovo la classe MainPage dal case study PhotoLab e dal case study Photo Editor.

C#. Nella versione C# (PhotoLab), MainPage è costituito dai file di codice sorgente MainPage.xaml e MainPage.xaml.cs.

C++/WinRT. Nella versione C++/WinRT (Editor foto), MainPage è costituito dai file di codice sorgente MainPage.xaml, MainPage.idl, MainPage.h e MainPage.cpp.

Quindi è possibile scegliere tra queste due opzioni:

  • (Scelta consigliata) è possibile copiare i file stessi (usando Esplora file) e quindi aggiungere le copie al progetto di destinazione. Le eccezioni a questa raccomandazione sono file come App.xaml e App.xaml.cs, poiché tali file esistono già nel progetto di destinazione e contengono il codice sorgente specifico di Windows App SDK. Per questi ultimi è necessario unire il codice sorgente già presente con quello del progetto sorgente.
  • In alternativa, è possibile usare Visual Studio per creare nuovi file di pagina (ad esempio MainPage.xaml e MainPage.xaml.cs) nel progetto di destinazione e quindi copiare il contenuto di tali file di codice sorgente dal progetto di origine al progetto di destinazione. Per un progetto C++/WinRT, questa opzione prevede molti altri passaggi.

Si veda anche la sezione MainPage e MainWindow.

Differenze tra cartella e nome file (C++/WinRT)

In un progetto UWP C++/WinRT i file code-behind per le visualizzazioni XAML sono denominati nel formato MainPage.h e MainPage.cpp. Ma in Windows App SDK C++/WinRT, sarà necessario rinominare gli elementi in MainPage.xaml.h e MainPage.xaml.cpp.

In un progetto UWP C++/WinRT, quando si esegue la migrazione di una visualizzazione XAML ipotetica (nel senso di modelli, visualizzazioni e modelli di visualizzazione) denominata MyPage, è MyPage.xaml.cpp necessario aggiungere #include "MyPage.g.cpp" immediatamente dopo #include "DetailPage.xaml.h". E per un modello ipotetico denominato MyModel, aggiungere MyModel.cpp #include "MyModel.g.cpp" immediatamente dopo #include "MyModel.h". Per un esempio, vedere Migrazione del codice sorgente detailPage.

Se si modifica il nome del progetto migrato

Durante la migrazione, è possibile scegliere di assegnare al progetto di destinazione un nome diverso da quello del progetto di origine. In tal caso, ciò influirà sullo spazio dei nomi predefinito all'interno del progetto di origine. Quando si copia il codice sorgente dal progetto di origine al progetto di destinazione, potrebbe essere necessario modificare i nomi degli spazi dei nomi indicati nel codice sorgente.

La modifica del nome del progetto (e di conseguenza il nome dello spazio predefinito) è qualcosa che viene fatta, ad esempio, nel case study Migrazione Windows App SDK dell'app campione PhotoLab UWP (C#). In questo case study, anziché copiare i contenuti del file dal progetto di origine a quello di destinazione, si copiano interi file usando Esplora file. Il nome del progetto/spazio dei nomi di origine è PhotoLab e il nome del progetto/spazio dei nomi di destinazione è PhotoLabWinUI3. Pertanto dobbiamo cercare PhotoLab nel contenuto di qualsiasi file di codice sorgente copiato e modificarlo in PhotoLabWinUI3

In questo case study specifico sono state apportate tali modifiche in App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.cs, e LoadedImageBrush.cs.

Installare gli stessi pacchetti NuGet installati nel progetto di origine

Un'attività durante il processo di migrazione consiste nell'identificare i pacchetti NuGet da cui il progetto di origine ha dipendenze. Installare quindi gli stessi pacchetti NuGet nel progetto di destinazione.

Ad esempio, nel case study Migrazione a Windows App SDK dell'app di esempio PhotoLab UWP (C#) il progetto di origine contiene riferimenti al pacchetto NuGet Microsoft.Graphics.Win2D. In questo case study si aggiungono quindi riferimenti allo stesso pacchetto NuGet al progetto di destinazione.