Partage via

Stratégie de migration globale

  • Article

Introduction

Le kit SDK Windows App fournit un large éventail d’API Windows dont les implémentations sont découplées de l’OS et mises à disposition des développeurs via des packages NuGet. En tant que développeur d’une application Universal Windows Platform (UWP), vous pouvez faire un excellent usage de vos compétences existantes, et de votre code source, en transférant votre application vers le Windows App SDK.

Avec le Windows App SDK, vous pouvez intégrer les dernières fonctionnalités du runtime, du langage et de la plateforme dans votre application. Chaque application étant différente, tout comme vos exigences et vos préférences, il existe de nombreuses façons d’aborder le processus de migration du code source de votre application. Mais l’approche de haut niveau et les changements de code nécessaires pour les différentes fonctionnalités sont similaires. Dans cette rubrique, nous allons donc passer en revue les applications que vous pouvez utiliser pour migrer votre application, ainsi que plus d’informations (et des limitations) sur certaines fonctionnalités. Consultez également la page Éléments pris en charge lors du portage de UWP vers WinUI 3.

La plupart des API de Windows Runtime (WinRT) peuvent être utilisées par les applications du SDK Windows App. Cependant, certaines API ne sont pas prises en charge dans les applications de bureau, ou sont soumises à des restrictions.

  • Les API qui comprennent des dépendances à des fonctionnalités de l’interface utilisateur qui ont été conçues pour être utilisées uniquement dans les applications UWP.
  • API nécessitant l’identité du package. Ces API ne sont prises en charge que dans les applications de bureau qui sont packagées à l’aide de MSIX.

Pour ces API, nous vous indiquerons les alternatives à utiliser. La plupart de ces alternatives sont disponibles dans WinUI 2, ou par le biais d’interfaces COM WinRT qui sont disponibles dans le SDK d'application Windows.

Par exemple, nous verrons certains scénarios d’interface utilisateur dans lesquels vous devrez suivre votre objet fenêtre principal et utiliser diverses API et modèles d’interopérabilité basés sur les HWND, tels que IInitializeWithWindow::Initialize.

Remarque

Consultez également la section API du moteur d’exécution Windows non prises en charge dans les applications de bureau. Les applications Windows App SDK sont un type d’application de bureau. Les autres types d’applications de bureau comprennent les applications de bureau .NET et les applications de bureau Win32 C/C++. Cette rubrique s’adresse aux développeurs souhaitant migrer vers tout ce qui fait partie de l’union de ces différents types d’applications de bureau, y compris (mais sans s’y limiter) les applications Windows App SDK.

Nous serions ravis de recevoir vos commentaires sur ce guide de migration et sur votre propre expérience de migration. Utilisez la section « Commentaires » au bas de cette page comme suit :

  • Pour toute question ou réaction concernant le Windows App SDK, ou simplement pour entamer une discussion, utilisez le bouton Ce produit. Vous pouvez également lancer une discussion sur l’onglet Discussions du référentiel GitHub de WindowsAppSDK. En utilisant ces chaînes, vous pourriez également nous dire quel problème vous essayez de résoudre, comment vous avez essayé de le résoudre jusqu’à présent, et quelle serait la solution idéale pour votre application.
  • Pour signaler des informations manquantes ou incorrectes dans ce guide de migration, utilisez le bouton Cette page.

Pourquoi migrer vers le Windows App SDK ?

Le SDK Windows App vous offre la possibilité d’améliorer votre application avec les nouvelles fonctionnalités de la plateforme, ainsi qu’avec la bibliothèque moderne Windows UI 3 (WinUI 3), qui est développée et conçue pour ravir vos utilisateurs.

En outre, le Windows App SDK est rétrocompatible ; il prend en charge les applications jusqu’à Windows 10, version 1809 (10.0 ; Build 17763) - également connu sous le nom de Windows 10 October 2018 Update.

La proposition de valeur liée à la migration du SDK Windows App est multiple. Voici quelques éléments à prendre en compte :

  • Plate-forme d’interface utilisateur (IU) et contrôles les plus récents tels que WinUI 3 et WebView2.
  • Une surface d’API unique à travers les plateformes d’applications de bureau.
  • Une cadence de publication plus fréquente et séparée de Windows.
  • Une expérience cohérente entre les différentes versions de Windows.
  • Compatibilité .NET.
  • Rétrocompatibilité jusqu’à Windows 10, version 1809.
  • Environnement d’exécution amélioré. Voir conteneur MSIX.

Pour plus d’informations, voir Windows App SDK.

Vue d’ensemble du processus de migration

Remarque

Vous pouvez considérer la version UWP de l’application que vous souhaitez migrer comme la solution/le projet source (c’est la source du processus de migration). La version du Windows App SDK est la solution cible (c’est la cible du processus de migration).

Installez le kit de développement d’applications Windows VSIX.

Téléchargez le programme d’installation de l’extension Windows App SDK Visual Studio (VSIX) à partir de la chaîne de distribution Stable pour le Windows App SDK, et exécutez-le pour l’installer.

Créer un projet

Dans Visual Studio, créez votre premier projet WinUI 3. Par exemple, utilisez le modèle de projet « Blank App, Packaged (WinUI 3 in Desktop) ». Vous pouvez trouver ce modèle de projet dans la boîte de dialogue Créer un nouveau projet en choisissant le langage : C# ou C++ ; plateforme : SDK Windows App ; type de projet : WinUI ou Desktop.

Vous verrez deux projets dans l’Explorateur de solutions : l’un est qualifié de (Desktop) et l’autre de (Package).

Migrez d’abord le code avec le moins de dépendances.

Pour illustrer cette recommandation, prenons l’exemple de l’étude de cas PhotoLab. Pour l’exemple d’application PhotoLab, une approche peut-être évidente consisterait à commencer par migrer la MainPage, puisqu’il s’agit d’un élément important et proéminent de l’application. Mais si nous faisions cela, nous nous rendrions vite compte que MainPage dépend de la vue DetailPage et que DetailPage dépend du modèle Photo. Si nous devions suivre cette voie, alors nous risquerions de nous interrompre constamment (en basculant pour travailler sur chaque nouvelle dépendance détectée). Il est certain que nous ne nous attendrions pas à obtenir un build propre avant d’avoir traqué toutes les dépendances et d’avoir porté l’ensemble du projet d’un seul coup.

En revanche, si nous commençons par la partie du projet qui ne dépend d’aucune autre, et que nous progressons à partir de là (de la partie la moins dépendante à la plus dépendante), nous pourrons nous concentrer sur chaque partie, l’une après l’autre. Nous pourrions ainsi nous concentrer sur chaque élément, un par un, et obtenir une compilation propre après avoir migré chaque élément, ce qui nous permettrait de confirmer que le processus de migration est sur la bonne voie.

Ainsi, lorsque vous migrez vos propres applications, nous vous recommandons de migrer d’abord le code ayant le moins de dépendances.

Copier les fichiers, ou copier le contenu des fichiers ?

Lors de la migration, vous copierez bien entendu les fichiers de ressources (et non leur contenu). Mais qu’en est-il des fichiers de code source ? À titre d’exemple, reprenons la classe MainPage de l’étude de cas PhotoLab et de l’étude de cas Éditeur de photos.

C#. Dans la version C# (PhotoLab), MainPage se compose des fichiers de code source MainPage.xaml et MainPage.xaml.cs.

C++/WinRT. Dans la version C++/WinRT (Photo Editor), MainPage est composée des fichiers de code source MainPage.xaml, MainPage.idl, MainPage.h et MainPage.cpp.

Vous avez le choix entre ces deux options :

  • (Recommandé) vous pouvez copier les fichiers eux-mêmes (à l’aide de l’Explorateur de fichiers), puis ajouter les copies au projet cible. Les exceptions à cette recommandation sont les fichiers tels que App.xaml et App.xaml.cs, étant donné que ces fichiers existent déjà dans le projet cible et qu’ils contiennent du code source spécifique au SDK Windows App. Pour ces derniers, vous devrez fusionner le code source déjà présent avec le code source du projet source.
  • Vous pouvez également utiliser Visual Studio pour créer de nouveaux fichiers Page (tels que MainPage.xaml et MainPage.xaml.cs) dans le projet cible, puis copier le contenu de ces fichiers de code source du projet source vers le projet cible. Pour un projet C++/WinRT, cette option implique beaucoup plus d’étapes.

Voir également la section MainPage et MainWindow.

Différences de noms de dossiers et de fichiers (C++/WinRT)

Dans un projet C++/WinRT UWP, les fichiers de code-behind pour les vues XAML sont nommés de la forme MainPage.h et MainPage.cpp. Mais dans un SDK Windows App C++/WinRT, vous devrez les renommer en MainPage.xaml.h et MainPage.xaml.cpp.

Dans un projet C++/WinRT UWP, lors de la migration d’une vue XAML hypothétique (au sens de modèles, vues et modèles de vue) nommée MyPage, dans MyPage.xaml.cpp vous devrez ajouter #include "MyPage.g.cpp" immédiatement après #include "DetailPage.xaml.h". Et pour un modèle hypothétique nommé MyModel, dans MyModel.cpp ajoutez #include "MyModel.g.cpp" immédiatement après #include "MyModel.h". Pour un exemple, voir Migrer le code source de DetailPage.

Si vous changez le nom de votre projet migré

Lors de la migration, vous pouvez choisir de donner à votre projet cible un nom différent de celui du projet source. Si vous le faites, cela affectera l’espace de noms par défaut dans le projet source. Lorsque vous copiez le code source du projet source vers le projet cible, il se peut que vous deviez modifier les noms des espaces de noms mentionnés dans le code source.

Changer le nom du projet (et par conséquent le nom de l’espace de noms par défaut) est quelque chose que nous faisons, par exemple, dans l’étude de cas Une migration Windows App SDK de l’application UWP PhotoLab (C#). Dans cette étude de cas, au lieu de copier le contenu des fichiers du projet source vers le projet cible, nous copions des fichiers entiers à l’aide de l’Explorateur de fichiers. Le nom du projet/espace de noms source est PhotoLab, et le nom du projet/espace de noms cible est PhotoLabWinUI3. Nous devons donc rechercher PhotoLab dans le contenu de tous les fichiers de code source que nous avons copiés, et le remplacer par PhotoLabWinUI3

Dans cette étude de cas particulière, nous avons effectué ces changements dans App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.cs et LoadedImageBrush.cs.

Installez les mêmes packages NuGet que ceux installés dans le projet source

L’une des tâches du processus de migration consiste à identifier tous les packages NuGet dont le projet source dépend. Puis d’installer ces mêmes packages NuGet dans le projet cible.

Par exemple, dans l’étude de cas Une migration Windows App SDK de l’application UWP PhotoLab (C#), le projet source contient des références au package NuGet Microsoft.Graphics.Win2D. Dans cette étude de cas, nous ajoutons une référence au même package NuGet dans le projet cible.