Portage de projets Silverlight Windows Phone vers des projets UWP

Article
07/05/2024

La rubrique précédente était Les mappages d’espaces de noms et de classes.

Vous commencez le processus de portage en créant un projet Windows 10 dans Visual Studio et en copiant vos fichiers.

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

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.
Dans votre projet d’application Silverlight Windows Phone, 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.
Copiez également des vues (par exemple, MainPage.xaml et MainPage.xaml.cs) dans le nouveau nœud de 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 Silverlight Windows Phone se concentre sur son 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.
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.
Les différences entre les noms d’espace de noms et de classes génèrent de nombreuses erreurs de génération à ce stade. Par exemple, si vous ouvrez les vues générées par Visual Studio, vous verrez qu’elles sont de type Page, et non PhoneApplicationPage. Il existe de nombreuses différences de balisage XAML et de code impératif que les rubriques suivantes de ce guide de portage couvrent en détail. Toutefois, vous allez effectuer une progression rapide en suivant ces étapes générales : remplacez « clr-namespace » par « using » dans vos déclarations de préfixe d’espace de noms dans le balisage XAML ; utilisez la rubrique Espaces de noms et mappages de classes et la commande Rechercher et remplacer de Visual Studio pour apporter des modifications en bloc à votre code source (par exemple, remplacer « System.Windows » par « Windows.UI.Xaml ») ; et dans l’éditeur de code impératif de Visual Studio, utilisez les commandes Résoudre et organiser les utilisations dans le menu contextuel pour obtenir des modifications plus ciblées.

Kits SDK d’extension

La plupart des API plateforme Windows universelle (UWP) que votre application transférée appellera 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.

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 consiste à 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 .
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 Phone Silverlight et Windows 10, vous pouvez peut-être 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. Si vous pouvez facteurr votre code source impératif afin que la plupart, si ce n’est pas le cas, d’un fichier fonctionne sur les deux plateformes, vous n’avez pas besoin de disposer de deux copies. Vous pouvez encapsuler n’importe quelle logique spécifique à la plateforme dans le fichier à l’intérieur des directives de compilation conditionnelle, le cas échéant, ou des conditions d’exécution. Consultez la section suivante ci-dessous et les directives de préprocesseur C#.
Pour une réutilisation au niveau binaire, au lieu du niveau du code source, il existe des bibliothèques de classes portables, qui prennent en charge le sous-ensemble d’API .NET disponibles dans Windows Phone Silverlight ainsi que le sous-ensemble pour les applications Windows 10 (.NET Core). Les assemblys de bibliothèque de classes portables sont compatibles binaires avec ces plateformes .NET et bien plus encore. 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.

Compilation conditionnelle et code adaptatif

Si vous souhaitez prendre en charge Windows Phone Silverlight et Windows 10 dans un fichier de code unique, vous pouvez 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. En général, vous pouvez utiliser la logique suivante pour effectuer une compilation conditionnelle.

#if WINDOWS_UAP
    // Code that you want to compile into the Windows 10/11 app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // WINDOWS_UAP

Si vous avez du code que vous avez partagé entre une application Silverlight Windows Phone et une application Windows Runtime 8.x, vous avez peut-être déjà du code source avec une logique semblable à ceci :

#if NETFX_CORE
    // Code that you want to compile into the Windows Runtime 8.x app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // NETFX_CORE

Si c’est le cas, et si vous souhaitez maintenant prendre en charge Windows 10 en outre, vous pouvez également le faire.

#if WINDOWS_UAP
    // Code that you want to compile into the Windows 10/11 app.
#else
#if NETFX_CORE
    // Code that you want to compile into the Windows Runtime 8.x app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // NETFX_CORE
#endif // WINDOWS_UAP

Vous avez peut-être utilisé la compilation conditionnelle pour limiter la gestion du bouton Précédent matériel à Windows Phone. 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.
    }

Vous avez peut-être utilisé la compilation conditionnelle pour limiter la gestion du bouton caméra matérielle à Windows Phone. 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, le code suivant est prudent uniquement d’utiliser des fonctionnalités présentes, bien qu’elle l’atteigne d’une manière différente de celle de la compilation conditionnelle.

       // 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 d’application

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 Exemples dans TargetDeviceFamily.

Il vaut la peine de savoir comment modifier le manifeste du package d’application, car les rubriques qui suivent parlent de l’utiliser pour diverses 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 les modifications. Vous souhaiterez peut-être vous assurer que l’élément pm :PhoneIdentity dans le manifeste de l’application porté correspond à ce qui se trouve dans le manifeste de l’application que vous transférez (pour plus d’informations, consultez la rubrique pm :PhoneIdentity).

Consultez les informations de référence sur le schéma du manifeste de package pour Windows 10.

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

Partager via