Partager via


Portage d’un projet Windows Runtime 8.x vers un projet UWP

Vous avez deux options lorsque vous commencez le processus de portage. Il s’agit de modifier une copie de vos fichiers projet existants, y compris le manifeste du package d’application (pour cette option, voir les informations sur la mise à jour de vos fichiers projet dans Migrer des applications vers le plateforme Windows universelle (UWP)). L’autre option consiste à créer un projet Windows 10 dans Visual Studio et à copier vos fichiers dans celui-ci. La première section de cette rubrique décrit cette deuxième option, mais le reste de la rubrique contient des informations supplémentaires applicables aux deux options. Vous pouvez également choisir de conserver votre nouveau projet Windows 10 dans la même solution que vos projets existants et partager des fichiers de code source à l’aide d’un projet partagé. Vous pouvez également conserver le nouveau projet dans une solution de ses propres fichiers de code source et partager des fichiers de code source à l’aide de la fonctionnalité fichiers liés dans Visual Studio.

Créer le projet et copier des fichiers vers celui-ci

Ces étapes se concentrent sur l’option permettant de créer un projet Windows 10 dans Visual Studio et de copier vos fichiers dans celui-ci. Certaines des spécificités relatives au nombre de projets que vous créez et aux fichiers que vous copiez dépendent des facteurs et décisions décrits dans If you have a Universal 8.1 app and the sections that follow it. Ces étapes supposent le cas le plus simple.

  1. Lancez Microsoft Visual Studio 2015 et créez un projet d’application vide (Windows Universelle). Pour plus d’informations, consultez Démarrage rapide de votre application Windows Runtime 8.x à l’aide de modèles (C#, C++, Visual Basic). Votre nouveau projet génère un package d’application (fichier appx) qui s’exécutera sur toutes les familles d’appareils.
  2. Dans votre projet d’application Universal 8.1, identifiez tous les fichiers de code source et les fichiers de ressources visuelles que vous souhaitez réutiliser. À l’aide de Explorateur de fichiers, copiez des modèles de données, affichez des modèles, des ressources visuelles, des dictionnaires de ressources, une structure de dossiers et tout autre élément que vous souhaitez réutiliser dans votre nouveau projet. Copiez ou créez des sous-dossiers sur le disque si nécessaire.
  3. Copiez également des vues (par exemple, MainPage.xaml et MainPage.xaml.cs) dans le nouveau projet. Là encore, créez de nouveaux sous-dossiers si nécessaire et supprimez les vues existantes du projet. Toutefois, avant de surécrire ou de supprimer une vue générée par Visual Studio, conservez une copie, car il peut être utile de la faire référence ultérieurement. La première phase de portage d’une application universelle 8.1 se concentre sur l’obtention de l’apparence et fonctionne correctement sur une famille d’appareils. Plus tard, vous attirerez votre attention sur la bonne adaptation des vues à tous les facteurs de forme, et éventuellement à l’ajout de tout code adaptatif pour tirer le meilleur parti d’une famille d’appareils particulière.
  4. Dans l’Explorateur de solutions, assurez-vous que l’option Afficher tous les fichiers est activée. Sélectionnez les fichiers que vous avez copiés, cliquez dessus avec le bouton droit, puis cliquez sur Inclure dans le projet. Cela inclut automatiquement leurs dossiers contenants. Vous pouvez ensuite désactiver l’option Afficher tous les fichiers si vous le souhaitez. Si vous préférez, un autre flux de travail consiste à utiliser la commande Ajouter un élément existant, ayant créé tous les sous-dossiers nécessaires dans visual Studio Explorateur de solutions. Vérifiez que vos ressources visuelles ont une action de génération définie sur Contenu et Copier dans le répertoire de sortie définie sur Ne pas copier.
  5. Vous êtes susceptible de voir certaines erreurs de build à ce stade. Toutefois, si vous savez ce que vous devez modifier, vous pouvez utiliser la commande Rechercher et remplacer de Visual Studio pour apporter des modifications en bloc à votre code source ; et dans l’éditeur de code impératif dans Visual Studio, utilisez les commandes Résoudre et organiser les utilisations dans le menu contextuel pour obtenir des modifications plus ciblées.

Optimisation du balisage et de la réutilisation du code

Vous constaterez que la refactorisation un peu, et/ou l’ajout de code adaptatif (expliqué ci-dessous), vous permettra d’optimiser le balisage et le code qui fonctionnent sur toutes les familles d’appareils. Voici plus de détails.

  • Les fichiers communs à toutes les familles d’appareils n’ont pas besoin d’une considération particulière. Ces fichiers seront utilisés par l’application sur toutes les familles d’appareils sur laquelle elle s’exécute. Cela inclut les fichiers de balisage XAML, les fichiers de code source impératifs et les fichiers de ressources.
  • Il est possible que votre application détecte la famille d’appareils sur laquelle elle s’exécute et accède à une vue conçue spécifiquement pour cette famille d’appareils. Pour plus d’informations, consultez Détection de la plateforme sur laquelle votre application s’exécute.
  • Une technique similaire que vous pouvez trouver utile s’il n’existe aucune alternative n’est donner un fichier de balisage ou un fichier ResourceDictionary (ou le dossier qui contient le fichier) un nom spécial de sorte qu’il soit automatiquement chargé lors de l’exécution uniquement lorsque votre application s’exécute sur une famille d’appareils particulière. Cette technique est illustrée dans l’étude de cas Bookstore1 .
  • Vous devriez pouvoir supprimer un grand nombre des directives de compilation conditionnelle dans le code source de votre application Universal 8.1 si vous n’avez besoin que de prendre en charge Windows 10. Consultez la compilation conditionnelle et le code adaptatif dans cette rubrique.
  • Pour utiliser des fonctionnalités qui ne sont pas disponibles sur toutes les familles d’appareils (par exemple, imprimantes, scanneurs ou bouton caméra), vous pouvez écrire du code adaptatif. Consultez le troisième exemple de compilation conditionnelle et de code adaptatif dans cette rubrique.
  • Si vous souhaitez prendre en charge Windows 8.1, Windows Phone 8.1 et Windows 10, vous pouvez conserver trois projets dans la même solution et partager du code avec un projet partagé. Vous pouvez également partager des fichiers de code source entre des projets. Voici comment : dans Visual Studio, cliquez avec le bouton droit sur le projet dans Explorateur de solutions, sélectionnez Ajouter un élément existant, sélectionnez les fichiers à partager, puis cliquez sur Ajouter en tant que lien. Stockez vos fichiers de code source dans un dossier commun sur le système de fichiers où les projets qui y sont liés peuvent les voir. Et n’oubliez pas de les ajouter au contrôle de code source.
  • Pour une réutilisation au niveau binaire, au lieu du niveau du code source, consultez Création de composants Windows Runtime en C# et Visual Basic. Il existe également des bibliothèques de classes portables qui prennent en charge le sous-ensemble d’API .NET disponibles dans le .NET Framework pour Windows 8.1, Windows Phone 8.1 et les applications Windows 10 (.NET Core) et .NET Framework complet. Les assemblys de bibliothèque de classes portables sont compatibles binaires avec toutes ces plateformes. Utilisez Visual Studio pour créer un projet qui cible une bibliothèque de classes portable. Consultez le développement multiplateforme avec la bibliothèque de classes portables.

Kits SDK d’extension

La plupart des API Windows Runtime que votre application universelle 8.1 appelle déjà sont implémentées dans l’ensemble d’API appelées famille d’appareils universelles. Toutefois, certains sont implémentés dans les kits SDK d’extension, et Visual Studio reconnaît uniquement les API implémentées par la famille d’appareils cible de votre application ou par les kits sdk d’extension que vous avez référencés.

Si vous obtenez des erreurs de compilation sur les espaces de noms ou les types ou les membres qui n’ont pas pu être trouvés, cela est probablement la cause. Ouvrez la rubrique de l’API dans la documentation de référence de l’API et accédez à la section Conditions requises : cela vous indiquera ce que la famille d’appareils implémente est. Si ce n’est pas votre famille d’appareils cible, pour rendre l’API disponible pour votre projet, vous aurez besoin d’une référence au Kit de développement logiciel (SDK) d’extension pour cette famille d’appareils.

Cliquez sur Project>Add Reference>Windows Universal>Extensions et sélectionnez le Kit de développement logiciel (SDK) d’extension approprié. Par exemple, si les API que vous souhaitez appeler sont disponibles uniquement dans la famille d’appareils mobiles et qu’elles ont été introduites dans la version 10.0.x.y, sélectionnez Extensions Windows Mobile pour UWP.

Cela ajoute la référence suivante à votre fichier projet :

<ItemGroup>
    <SDKReference Include="WindowsMobile, Version=10.0.x.y">
        <Name>Windows Mobile Extensions for the UWP</Name>
    </SDKReference>
</ItemGroup>

Le nom et le numéro de version correspondent aux dossiers situés à l’emplacement installé de votre Kit de développement logiciel (SDK). Par exemple, les informations ci-dessus correspondent au nom de ce dossier :

\Program Files (x86)\Windows Kits\10\Extension SDKs\WindowsMobile\10.0.x.y

Sauf si votre application cible la famille d’appareils qui implémente l’API, vous devez utiliser la classe ApiInformation pour tester la présence de l’API avant de l’appeler (il s’agit du code adaptatif). Cette condition sera ensuite évaluée partout où votre application s’exécute, mais elle ne sera évaluée que sur les appareils où l’API est présente et donc disponible pour appeler. Utilisez uniquement les kits SDK d’extension et le code adaptatif après avoir vérifié d’abord si une API universelle existe. Certains exemples sont fournis dans la section ci-dessous.

Consultez également le manifeste du package d’application.

Compilation conditionnelle et code adaptatif

Si vous utilisez la compilation conditionnelle (avec des directives de préprocesseur C#) afin que vos fichiers de code fonctionnent à la fois sur Windows 8.1 et Windows Phone 8.1, vous pouvez maintenant passer en revue cette compilation conditionnelle en fonction du travail de convergence effectué dans Windows 10. La convergence signifie que, dans votre application Windows 10, certaines conditions peuvent être supprimées. D’autres passent aux vérifications au moment de l’exécution, comme illustré dans les exemples ci-dessous.

Notez que si vous souhaitez prendre en charge Windows 8.1, Windows Phone 8.1 et Windows 10 dans un fichier de code unique, vous pouvez également le faire. Si vous examinez votre projet Windows 10 sur les pages de propriétés du projet, vous verrez que le projet définit WINDOWS_UAP comme symbole de compilation conditionnelle. Vous pouvez donc l’utiliser en combinaison avec WINDOWS_APP et WINDOWS_PHONE_APP. Ces exemples montrent le cas plus simple de supprimer la compilation conditionnelle d’une application 8.1 universelle et de remplacer le code équivalent pour une application Windows 10.

Ce premier exemple montre le modèle d’utilisation de l’API PickSingleFileAsync (qui s’applique uniquement à Windows 8.1) et l’API PickSingleFileAndContinue (qui s’applique uniquement à Windows Phone 8.1).

#if WINDOWS_APP
    // Use Windows.Storage.Pickers.FileOpenPicker.PickSingleFileAsync
#else
    // Use Windows.Storage.Pickers.FileOpenPicker.PickSingleFileAndContinue
#endif // WINDOWS_APP

Windows 10 converge sur l’API PickSingleFileAsync , ce qui simplifie votre code :

    // Use Windows.Storage.Pickers.FileOpenPicker.PickSingleFileAsync

Dans cet exemple, nous gérons le bouton Précédent matériel, mais uniquement sur Windows Phone.

#if WINDOWS_PHONE_APP
        Windows.Phone.UI.Input.HardwareButtons.BackPressed += this.HardwareButtons_BackPressed;
#endif // WINDOWS_PHONE_APP

...

#if WINDOWS_PHONE_APP
    void HardwareButtons_BackPressed(object sender, Windows.Phone.UI.Input.BackPressedEventArgs e)
    {
        // Handle the event.
    }
#endif // WINDOWS_PHONE_APP

Dans Windows 10, l’événement de bouton Précédent est un concept universel. Les boutons Précédents implémentés dans le matériel ou dans le logiciel déclenchent tous l’événement BackRequested , c’est-à-dire celui à gérer.

    Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested +=
        this.ViewModelLocator_BackRequested;

...

private void ViewModelLocator_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
{
    // Handle the event.
}

Cet exemple final est similaire à celui précédent. Ici, nous gérons le bouton de la caméra matérielle, mais là encore, uniquement dans le code compilé dans le package d’application Windows Phone.

#if WINDOWS_PHONE_APP
    Windows.Phone.UI.Input.HardwareButtons.CameraPressed += this.HardwareButtons_CameraPressed;
#endif // WINDOWS_PHONE_APP

...

#if WINDOWS_PHONE_APP
void HardwareButtons_CameraPressed(object sender, Windows.Phone.UI.Input.CameraEventArgs e)
{
    // Handle the event.
}
#endif // WINDOWS_PHONE_APP

Dans Windows 10, le bouton de la caméra matérielle est un concept particulier pour la famille d’appareils mobiles. Étant donné qu’un package d’application s’exécute sur tous les appareils, nous modifions notre condition de compilation en condition d’exécution à l’aide de ce qu’on appelle le code adaptatif. Pour ce faire, nous utilisons la classe ApiInformation pour interroger au moment de l’exécution la présence de la classe HardwareButtons. HardwareButtons est défini dans le Kit de développement logiciel (SDK) d’extension mobile. Nous devons donc ajouter une référence à ce Kit de développement logiciel (SDK) à notre projet pour que ce code soit compilé. Notez toutefois que le gestionnaire ne sera exécuté que sur un appareil qui implémente les types définis dans le Kit de développement logiciel (SDK) d’extension mobile et que c’est la famille d’appareils mobiles. Par conséquent, ce code est moralement équivalent au code 8.1 universel dans lequel il est prudent d’utiliser uniquement les fonctionnalités présentes, bien qu’il atteigne cela d’une manière différente.

    // Note: Cache the value instead of querying it more than once.
    bool isHardwareButtonsAPIPresent = Windows.Foundation.Metadata.ApiInformation.IsTypePresent
        ("Windows.Phone.UI.Input.HardwareButtons");

    if (isHardwareButtonsAPIPresent)
    {
        Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
            this.HardwareButtons_CameraPressed;
    }

    ...

private void HardwareButtons_CameraPressed(object sender, Windows.Phone.UI.Input.CameraEventArgs e)
{
    // Handle the event.
}

Consultez également La détection de la plateforme sur laquelle votre application s’exécute.

Manifeste du package de l’application

La rubrique Nouveautés de Windows 10 répertorie les modifications apportées à la référence de schéma de manifeste de package pour Windows 10, y compris les éléments qui ont été ajoutés, supprimés et modifiés. Pour obtenir des informations de référence sur tous les éléments, attributs et types dans le schéma, consultez Hiérarchie d’éléments. Si vous transférez une application Windows Phone Store ou si votre application est une mise à jour vers une application à partir du Windows Phone Store, vérifiez que l’élément mp :PhoneIdentity correspond au manifeste de l’application de votre application précédente (utilisez les mêmes GUID attribués à l’application par le Store). Cela garantit que les utilisateurs de votre application qui effectuent une mise à niveau vers Windows 10 ou Windows 11 recevront votre nouvelle application en tant que mise à jour, et non en double. Pour plus d’informations, consultez la rubrique de référence mp :PhoneIdentity.

Les paramètres de votre projet (y compris les références de kits sdk d’extension) déterminent la surface d’exposition de l’API que votre application peut appeler. Toutefois, votre manifeste de package d’application détermine l’ensemble réel d’appareils sur lequel vos clients peuvent installer votre application à partir du Windows Store. Pour plus d’informations, consultez des exemples dans TargetDeviceFamily.

Vous pouvez modifier le manifeste du package d’application pour définir différentes déclarations, fonctionnalités et autres paramètres dont certaines fonctionnalités ont besoin. Vous pouvez utiliser l’éditeur de manifeste du package d’application Visual Studio pour le modifier. Si la Explorateur de solutions n’est pas affichée, choisissez-la dans le menu Affichage. Double-cliquez sur Package.appxmanifest. La fenêtre de l’éditeur de manifeste s’ouvre. Sélectionnez l’onglet approprié pour apporter des modifications, puis enregistrez.

La rubrique suivante est La résolution des problèmes.