Utiliser le système de gestion des ressources Windows 10 dans une application ou un jeu hérité

Les applications et jeux .NET et Win32 sont souvent localisés dans différentes langues pour développer leur marché adressable total. Pour plus d'informations sur la valeur ajoutée de la localisation de votre application, consultez Globalisation et localisation. En empaquetant votre application ou votre jeu .NET ou Win32 en tant que package .msix ou .appx, vous pouvez tirer parti du système de gestion des ressources pour charger les ressources d’application adaptées au contexte d’exécution. Cette rubrique détaillée décrit les techniques.

Il existe de nombreuses façons de localiser une application Win32 traditionnelle, mais Windows 8 a introduit un nouveau système de gestion des ressources qui fonctionne dans les langages de programmation, entre les types d’applications et fournit des fonctionnalités sur et au-dessus de la localisation simple. Ce système sera appelé « MRT » dans cette rubrique. Historiquement, cela signifiait « Modern Resource Technology » (Technologie moderne des ressources), mais le terme « Moderne » a été supprimé. Le gestionnaire de ressources peut également être appelé MRM (Modern Resource Manager) ou PRI (Package Resource Index).

Combiné à un déploiement basé sur MSIX ou .appx (par exemple, à partir du Microsoft Store), MRT peut fournir automatiquement les ressources les plus applicables pour un utilisateur/appareil donné, ce qui réduit la taille de téléchargement et d’installation de votre application. Cette réduction de taille peut être importante pour les applications avec une grande quantité de contenu localisé, peut-être sur l’ordre de plusieurs gigaoctets pour les jeux AAA. Les avantages supplémentaires de MRT incluent les descriptions localisées dans Windows Shell et le Microsoft Store, logique de secours automatique quand la langue préférée d’un utilisateur ne correspond pas à vos ressources disponibles.

Ce document décrit l’architecture générale de MRT et fournit un guide de portage pour aider à déplacer des applications Win32 héritées vers MRT avec des modifications de code minimales. Une fois le passage à MRT effectué, des avantages supplémentaires (tels que la possibilité de segmenter les ressources par facteur d’échelle ou thème système) deviennent disponibles pour le développeur. Notez que la localisation basée sur MRT fonctionne pour les applications UWP et Win32 traitées par le pont de bureau (appelé « Centennial »).

Dans de nombreuses situations, vous pouvez continuer à utiliser vos formats de localisation et votre code source existants tout en intégrant MRT pour résoudre les ressources au moment de l’exécution et réduire les tailles de téléchargement , ce n’est pas une approche tout ou rien. Le tableau suivant récapitule le travail et les coûts/avantages estimés de chaque étape. Ce tableau n’inclut pas de tâches de non-localisation, telles que la fourniture d’icônes d’application haute résolution ou à contraste élevé. Pour plus d’informations sur la fourniture de plusieurs ressources pour les vignettes, les icônes, etc., consultez Personnaliser vos ressources pour la langue, l’échelle, le contraste élevé et d’autres qualificateurs.

Présentation

La plupart des applications non triviales contiennent des éléments d’interface utilisateur appelés ressources découplées du code de l’application (contrairement aux valeurs codées en dur créées dans le code source lui-même). Il existe plusieurs raisons de préférer les ressources aux valeurs codées en dur ( facilité de modification par les non-développeurs, par exemple), mais l’une des principales raisons consiste à permettre à l’application de choisir différentes représentations de la même ressource logique au moment de l’exécution. Par exemple, le texte à afficher sur un bouton (ou l’image à afficher dans une icône) peut différer selon la ou les langues que l’utilisateur comprend, les caractéristiques de l’appareil d’affichage ou si l’utilisateur dispose de technologies d’assistance activées.

Ainsi, l’objectif principal de toute technologie de gestion des ressources consiste à traduire, au moment de l’exécution, une demande de nom de ressource logique ou symbolique (par SAVE_BUTTON_LABELexemple) en la meilleure valeur réelle possible (par exemple, « Enregistrer ») à partir d’un ensemble de candidats possibles (par exemple, « Save », « Speichern » ou « 저장 »). MRT fournit une telle fonction et permet aux applications d’identifier les candidats aux ressources à l’aide d’un large éventail d’attributs, appelés qualificateurs, tels que la langue de l’utilisateur, le facteur d’échelle d’affichage, le thème sélectionné par l’utilisateur et d’autres facteurs environnementaux. MRT prend même en charge les qualificateurs personnalisés pour les applications qui en ont besoin (par exemple, une application peut fournir différentes ressources graphiques pour les utilisateurs connectés avec un compte et les utilisateurs invités, sans ajouter explicitement cette vérification dans chaque partie de leur application). MRT fonctionne avec les ressources de chaîne et les ressources basées sur des fichiers, où les ressources basées sur des fichiers sont implémentées en tant que références aux données externes (les fichiers eux-mêmes).

Exemple :

Voici un exemple simple d’application qui a des étiquettes de texte sur deux boutons (openButton et saveButton) et un fichier PNG utilisé pour un logo (logoImage). Les étiquettes de texte sont localisées en anglais et en allemand, et le logo est optimisé pour les affichages de bureau normaux (facteur d’échelle de 100%) et les téléphones haute résolution (300% facteur d’échelle). Veuillez noter que ce diagramme présente une vue conceptuelle du modèle, il ne correspond pas exactement à l’implémentation.

Dans le graphique, le code de l’application fait référence aux trois noms de ressources logiques. Au moment de l’exécution, la GetResource pseudo-fonction utilise MRT pour rechercher ces noms de ressources dans la table de ressources (appelée fichier PRI) et trouver le candidat le plus approprié en fonction des conditions ambiantes (langue de l’utilisateur et facteur d’échelle de l’affichage). Dans le cas des étiquettes, les chaînes sont utilisées directement. Dans le cas de l’image du logo, les chaînes sont interprétées comme des noms de fichiers et les fichiers sont lus sur le disque.

Si l’utilisateur parle une langue autre que l’anglais ou l’allemand, ou a un facteur d’échelle d’affichage autre que 100% ou 300%, MRT choisit le candidat correspondant le plus proche en fonction d’un ensemble de règles de secours (voir Resource Management System pour plus d’arrière-plan).

Notez que MRT prend en charge les ressources adaptées à plusieurs qualificateurs ( par exemple, si l’image de logo contenait également du texte incorporé qui devait également être localisé, le logo aurait quatre candidats : EN/Scale-100, DE/Scale-100, EN/Scale-300 et DE/Scale-300.

Sections de ce document

Les sections suivantes décrivent les tâches générales requises pour intégrer MRT à votre application.

Phase 0 : Générer un package d’application

Cette section explique comment créer votre application de bureau existante en tant que package d’application. Aucune fonctionnalité MRT n’est utilisée à ce stade.

Phase 1 : Localiser le manifeste de l’application

Cette section explique comment localiser le manifeste de votre application (afin qu’il apparaisse correctement dans l’interpréteur de commandes Windows) tout en utilisant votre format de ressource hérité et votre API pour empaqueter et localiser des ressources.

Phase 2 : Utiliser MRT pour identifier et localiser les ressources

Cette section explique comment modifier votre code d’application (et éventuellement la disposition des ressources) pour localiser les ressources à l’aide de MRT, tout en utilisant vos formats de ressources et API existants pour charger et consommer les ressources.

Phase 3 : Créer des packs de ressources

Cette section décrit les dernières modifications nécessaires pour séparer vos ressources en packs de ressources distincts, ce qui réduit la taille de téléchargement (et d’installation) de votre application.

Non abordé dans ce document

Une fois les phases 0-3 ci-dessus terminées, vous disposez d’une application « bundle » qui peut être envoyée au Microsoft Store et qui réduit la taille du téléchargement et de l’installation pour les utilisateurs en omettant les ressources dont ils n’ont pas besoin (par exemple, les langues qu’ils ne parlent pas). D’autres améliorations de la taille et des fonctionnalités de l’application peuvent être apportées en effectuant une dernière étape.

Phase 4 : Migrer vers des formats de ressources MRT et des API

Cette phase dépasse le cadre de ce document ; cela implique de déplacer vos ressources (en particulier les chaînes) à partir de formats hérités tels que des DLL MUI ou des assemblys de ressources .NET dans des fichiers PRI. Cela peut entraîner d’autres économies d’espace pour les tailles de téléchargement et d’installation. Il permet également d’utiliser d’autres fonctionnalités MRT, telles que la réduction du téléchargement et de l’installation des fichiers image en fonction du facteur d’échelle, des paramètres d’accessibilité, etc.

Phase 0 : Générer un package d’application

Avant d’apporter des modifications aux ressources de votre application, vous devez d’abord remplacer votre technologie d’empaquetage et d’installation actuelle par la technologie de déploiement et d’empaquetage UWP standard. Il existe trois façons de procéder :

• Si vous disposez d’une application de bureau volumineuse avec un programme d’installation complexe ou si vous utilisez de nombreux points d’extensibilité du système d’exploitation, vous pouvez utiliser l’outil Desktop App Converter pour générer la disposition et les informations de manifeste de fichier UWP à partir de votre programme d’installation d’application existant (par exemple, une msi).
• Si vous disposez d’une application de bureau plus petite avec relativement peu de fichiers ou un programme d’installation simple et qu’aucun hook d’extensibilité n’est possible, vous pouvez créer manuellement les informations de disposition et de manifeste de fichier.
• Si vous régénérez à partir de la source et souhaitez mettre à jour votre application pour qu’elle soit une application UWP pure, vous pouvez créer un projet dans Visual Studio et vous appuyer sur l’IDE pour effectuer une grande partie du travail pour vous.

Si vous souhaitez utiliser le Desktop App Converter, consultez Emballer une application de bureau à l’aide du Desktop App Converter pour plus d’informations sur le processus de conversion. Vous trouverez un ensemble complet d’exemples Desktop Converter sur le référentiel GitHub d’exemples Pont du bureau vers UWP.

Si vous souhaitez créer manuellement le package, vous devez créer une structure de répertoires qui inclut tous les fichiers de votre application (exécutables et contenus, mais pas le code source) et un fichier manifeste de package (.appxmanifest). Vous trouverez un exemple dans l’exemple Hello, World GitHub, mais voici un fichier manifeste de package de base qui lance l’exécutable de bureau nommé ContosoDemo.exe, où le texte mis en surbrillance doit être remplacé par vos propres valeurs.

<?xml version="1.0" encoding="utf-8" ?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
         xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
         xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
         xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
         IgnorableNamespaces="uap mp rescap">
    <Identity Name="Contoso.Demo"
              Publisher="CN=Contoso.Demo"
              Version="1.0.0.0" />
    <Properties>
    <DisplayName>Contoso App</DisplayName>
    <PublisherDisplayName>Contoso, Inc</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
  </Properties>
    <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" 
                        MaxVersionTested="10.0.14393.0" />
  </Dependencies>
    <Resources>
    <Resource Language="en-US" />
  </Resources>
    <Applications>
    <Application Id="ContosoDemo" Executable="ContosoDemo.exe" 
                 EntryPoint="Windows.FullTrustApplication">
    <uap:VisualElements DisplayName="Contoso Demo" BackgroundColor="#777777" 
                        Square150x150Logo="Assets\Square150x150Logo.png" 
                        Square44x44Logo="Assets\Square44x44Logo.png" 
        Description="Contoso Demo">
      </uap:VisualElements>
    </Application>
  </Applications>
    <Capabilities>
    <rescap:Capability Name="runFullTrust" />
  </Capabilities>
</Package>

Pour plus d’informations sur le fichier manifeste de package et la disposition du package, consultez le manifeste du package d’application.

Enfin, si vous utilisez Visual Studio pour créer un projet et migrer votre code existant, consultez Créer une application « Hello, world ». Vous pouvez inclure votre code existant dans le nouveau projet, mais vous devrez probablement apporter des modifications significatives au code (en particulier dans l’interface utilisateur) afin de s’exécuter en tant qu’application UWP pure. Ces modifications sont en dehors de l’étendue de ce document.

Phase 1 : localiser le manifeste

Étape 1.1 : Mettre à jour les chaînes et les ressources dans le manifeste

Dans la phase 0, vous avez créé un fichier manifeste de package de base (.appxmanifest) pour votre application (en fonction des valeurs fournies au convertisseur, extraites de l’interface MSI ou saisies manuellement dans le manifeste), mais elle ne contiendra pas d’informations localisées, ni ne prendra en charge les fonctionnalités supplémentaires telles que les ressources de vignette de démarrage haute résolution, etc.

Pour vous assurer que le nom et la description de votre application sont correctement localisés, vous devez définir certaines ressources dans un ensemble de fichiers de ressources et mettre à jour le manifeste du package pour les référencer.

Création d’un fichier de ressources par défaut

La première étape consiste à créer un fichier de ressources par défaut dans votre langue par défaut (par exemple, anglais américain). Vous pouvez le faire manuellement avec un éditeur de texte ou via le Concepteur de ressources dans Visual Studio.

Si vous souhaitez créer les ressources manuellement :

1. Créez un fichier XML nommé resources.resw et placez-le dans un Strings\en-us sous-dossier de votre projet. Utilisez le code BCP-47 approprié si votre langue par défaut n’est pas l’anglais américain.
2. Dans le fichier XML, ajoutez le contenu suivant, où le texte mis en surbrillance est remplacé par le texte approprié pour votre application, dans votre langue par défaut.

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="ApplicationDescription">
    <value>Contoso Demo app with localized resources (English)</value>
  </data>
  <data name="ApplicationDisplayName">
    <value>Contoso Demo Sample (English)</value>
  </data>
  <data name="PackageDisplayName">
    <value>Contoso Demo Package (English)</value>
  </data>
  <data name="PublisherDisplayName">
    <value>Contoso Samples, USA</value>
  </data>
  <data name="TileShortName">
    <value>Contoso (EN)</value>
  </data>
</root>

Si vous souhaitez utiliser le concepteur dans Visual Studio :

1. Créez le Strings\en-us dossier (ou autre langue appropriée) dans votre projet et ajoutez un nouvel élément au dossier racine de votre projet, en utilisant le nom par défaut .resources.resw Veillez à choisir Le fichier de ressources (.resw) et non le dictionnaire de ressources . Un dictionnaire de ressources est un fichier utilisé par les applications XAML.
2. À l’aide du concepteur, entrez les chaînes suivantes (utilisez le même Names, mais remplacez le Values par le texte approprié pour votre application) :

Mettre à jour le manifeste pour référencer les ressources

Une fois les valeurs définies dans le .resw fichier, l’étape suivante consiste à mettre à jour le manifeste pour référencer les chaînes de ressources. Là encore, vous pouvez modifier un fichier XML directement ou vous appuyer sur le Concepteur de manifeste Visual Studio.

Si vous modifiez directement du code XML, ouvrez le fichier AppxManifest.xml et apportez les modifications suivantes aux valeurs mises en surbrillance. Utilisez ce texte exact, plutôt qu'un texte spécifique à votre application. Il n’est pas nécessaire d’utiliser ces noms de ressources exacts , vous pouvez choisir vos propres noms, mais ce que vous choisissez doit correspondre exactement à ce qui se trouve dans le .resw fichier. Ces noms doivent correspondre à ceux que vous avez créés dans le fichier Names, précédés du schéma .resw et de l’espace de noms ms-resource:.

<?xml version="1.0" encoding="utf-8"?>
<Package>
  <Properties>
    <DisplayName>ms-resource:Resources/PackageDisplayName</DisplayName>
    <PublisherDisplayName>ms-resource:Resources/PublisherDisplayName</PublisherDisplayName>
  </Properties>
  <Applications>
    <Application>
      <uap:VisualElements DisplayName="ms-resource:Resources/ApplicationDisplayName"
        Description="ms-resource:Resources/ApplicationDescription">
        <uap:DefaultTile ShortName="ms-resource:Resources/TileShortName">
          <uap:ShowNameOnTiles>
            <uap:ShowOn Tile="square150x150Logo" />
          </uap:ShowNameOnTiles>
        </uap:DefaultTile>
      </uap:VisualElements>
    </Application>
  </Applications>
</Package>

Si vous utilisez le concepteur de manifestes de Visual Studio, ouvrez le fichier .appxmanifest et modifiez les valeurs mises en surbrillance aux valeurs dans l’ongletApplication et l’onglet Paquetage :

Étape 1.2 : Générer un fichier PRI, créer un package MSIX et vérifier qu’il fonctionne

Vous devez maintenant être en mesure de générer le .pri fichier et de déployer l’application pour vérifier que les informations appropriées (dans votre langue par défaut) apparaissent dans le menu Démarrer.

Si vous générez dans Visual Studio, appuyez Ctrl+Shift+B simplement pour générer le projet, puis cliquez avec le bouton droit sur le projet et choisissez Deploy dans le menu contextuel.

Si vous construisez manuellement, suivez ces étapes pour créer un fichier de configuration pour l'outil MakePRI et générer le fichier .pri (vous trouverez plus d’informations dans conditionnement manuel d'application) :

1. Ouvrez une invite de commandes développeur à partir du dossier Visual Studio 2019 ou Visual Studio 2022 dans le menu Démarrer.

2. Basculez vers le répertoire racine du projet (celui qui contient le fichier .appxmanifest et le dossier Strings ).

3. Tapez la commande suivante, en remplaçant «contoso_demo.xml» par un nom adapté à votre projet, et «en-US» par la langue par défaut de votre application (ou conservez-la en-US le cas échéant). Notez que le fichier XML est créé dans le répertoire parent (pas dans le répertoire du projet), car il ne fait pas partie de l’application (vous pouvez choisir n’importe quel autre répertoire souhaité, mais veillez à remplacer cela dans les commandes ultérieures).

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
   

   Vous pouvez taper makepri createconfig /? pour voir ce que fait chaque paramètre, mais en résumé :

   • /cf définit le nom de fichier de configuration (la sortie de cette commande)
   • /dq définit les qualificateurs par défaut, dans ce cas la langue en-US
   • /pv définit la version de la plateforme, dans ce cas Windows 10
   • /o la définit pour remplacer le fichier de sortie s’il existe

4. Maintenant que vous disposez d’un fichier de configuration, réexécutez-les MakePRI pour rechercher les ressources et les empaqueter dans un fichier PRI. Remplacez «contoso_demop.xml» par le nom de fichier XML que vous avez utilisé à l’étape précédente et veillez à spécifier le répertoire parent pour l’entrée et la sortie :

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   

   Vous pouvez taper makepri new /? pour voir ce que fait chaque paramètre, mais en un mot :

   • /pr définit la racine du projet (dans ce cas, le répertoire actif)
   • /cf définit le nom de fichier de configuration, créé à l’étape précédente
   • /of définit le fichier de sortie
   • /mf crée un fichier de mappage (afin que nous puissions exclure des fichiers dans le package dans une étape ultérieure)
   • /o la définit pour remplacer le fichier de sortie s’il existe

5. Vous disposez maintenant d’un .pri fichier avec les ressources linguistiques par défaut (par exemple, en-US). Pour vérifier qu’elle a fonctionné correctement, vous pouvez exécuter la commande suivante :

   makepri dump /if ..\resources.pri /of ..\resources /o
   

   Vous pouvez taper makepri dump /? pour voir ce que fait chaque paramètre, mais en un mot :

   • /if définit le nom de fichier d’entrée
   • /of définit le nom de fichier de sortie (.xml sera ajouté automatiquement)
   • /o la définit pour remplacer le fichier de sortie s’il existe

6. Enfin, vous pouvez ouvrir ..\resources.xml dans un éditeur de texte et vérifier qu’il répertorie vos <NamedResource> valeurs (comme ApplicationDescription et PublisherDisplayName) ainsi <Candidate> que les valeurs de votre langue par défaut choisie (il y aura d’autres contenus au début du fichier ; ignorez-le pour l’instant).

Vous pouvez ouvrir le fichier de mappage pour vérifier qu’il contient les fichiers nécessaires pour votre projet (y compris le fichier ..\resources.map.txt PRI, qui ne fait pas partie du répertoire du projet). Il est important de noter que le fichier de mappage n'pas inclure une référence à votre fichier resources.resw, car le contenu de ce fichier a déjà été incorporé dans le fichier PRI. Toutefois, elle contiendra d’autres ressources telles que les noms de fichiers de vos images.

Création et signature du paquet

Maintenant que le fichier PRI est généré, vous pouvez générer et signer le package :

1. Pour créer le package d’application, exécutez la commande suivante en remplaçant contoso_demo.appx par le nom du fichier .msix/.appx que vous souhaitez créer et veillez à choisir un autre répertoire pour le fichier (cet exemple utilise le répertoire parent ; il peut être n’importe où, mais ne doit pas être le répertoire du projet).

   makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /o
   

   Vous pouvez taper makeappx pack /? pour voir ce que fait chaque paramètre, mais en un mot :

   • /m définit le fichier manifeste à utiliser
   • /f définit le fichier de mappage à utiliser (créé à l’étape précédente)
   • /p définit le nom du package de sortie
   • /o la définit pour remplacer le fichier de sortie s’il existe

2. Une fois le package créé, il doit être signé. Le moyen le plus simple d’obtenir un certificat de signature consiste à créer un projet Windows universel vide dans Visual Studio et à copier le .pfx fichier qu’il crée, mais vous pouvez en créer un manuellement à l’aide des MakeCert services et Pvk2Pfx des utilitaires, comme décrit dans Comment créer un certificat de signature de package d’application.

   Importante

   Si vous créez manuellement un certificat de signature, veillez à placer les fichiers dans un répertoire différent de celui de votre projet source ou de votre source de package. Sinon, il peut être inclus dans le cadre du package, y compris la clé privée !

3. Pour signer le package, utilisez la commande suivante. Notez que l’élément Publisher spécifié dans l’élément IdentityAppxManifest.xml doit correspondre au Subject certificat (il ne s’agit pas de l’élément <PublisherDisplayName> , qui est le nom complet localisé à afficher aux utilisateurs). Comme d’habitude, remplacez les contoso_demo... noms par les noms appropriés pour votre projet, et (très important) assurez-vous que le .pfx fichier n’est pas dans le répertoire actif (sinon il aurait été créé dans le cadre de votre package, y compris la clé de signature privée !) :

   signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appx
   

   Vous pouvez taper signtool sign /? pour voir ce que fait chaque paramètre, mais en un mot :

   • /fd définit l’algorithme File Digest (SHA256 est la valeur par défaut pour .appx)
   • /a sélectionne automatiquement le meilleur certificat
   • /f spécifie le fichier d’entrée qui contient le certificat de signature

Enfin, vous pouvez maintenant double-cliquer sur le .appx fichier pour l’installer, ou si vous préférez la ligne de commande, vous pouvez ouvrir une invite PowerShell, passer au répertoire contenant le package et taper ce qui suit (en remplaçant contoso_demo.appx par le nom de votre package) :

add-appxpackage contoso_demo.appx

Si vous recevez des erreurs indiquant que le certificat n'est pas approuvé, assurez-vous qu'il est ajouté au magasin d'ordinateurs (), et non pas dans le magasin d’utilisateurs (). Pour ajouter le certificat au magasin d’ordinateurs, vous pouvez utiliser la ligne de commande ou l’Explorateur Windows.

Pour utiliser la ligne de commande :

1. Exécutez une invite de commandes Visual Studio 2019 ou Visual Studio 2022 en tant qu’administrateur.

2. Basculez vers le répertoire qui contient le .cer fichier (n’oubliez pas de vous assurer que cela se trouve en dehors de vos répertoires source ou projet !)

3. Tapez la commande suivante, en remplaçant contoso_demo.cer par votre nom de fichier :

   certutil -addstore TrustedPeople contoso_demo.cer
   

   Vous pouvez exécuter certutil -addstore /? pour voir ce que fait chaque paramètre, mais en un mot :

   • -addstore ajoute un certificat à un magasin de certificats
   • TrustedPeople indique le magasin dans lequel le certificat est placé

Pour utiliser l’Explorateur Windows :

1. Accédez au dossier qui contient le .pfx fichier
2. Double-cliquez sur le .pfx fichier et l’Assistant Importation de certificat doit apparaître
3. Choisir Local Machine et cliquer Next
4. Acceptez, le cas échéant, l'invite d'élévation de l'administrateur du contrôle de compte d'utilisateur, puis cliquez sur Next
5. Entrez le mot de passe de la clé privée, s’il en existe un, puis cliquez sur Next
6. Sélectionnez Place all certificates in the following store
7. Cliquez sur Browse, puis choisissez le Trusted People dossier (et non « Éditeurs approuvés »)
8. Cliquez Next , puis Finish

Après avoir ajouté le certificat au Trusted People magasin, réessayez d’installer le package.

Vous devez maintenant voir votre application apparaître dans la liste « Toutes les applications » du menu Démarrer, avec les informations correctes du .resw / .pri fichier. Si vous voyez une chaîne vide ou la chaîne ms-resource:... , un problème s’est produit : vérifiez vos modifications et vérifiez qu’elles sont correctes. Si vous cliquez avec le bouton droit sur votre application dans le menu Démarrer, vous pouvez l’épingler en tant que vignette et vérifier que les informations appropriées s’affichent également.

Étape 1.3 : Ajouter d’autres langues prises en charge

Une fois que les modifications ont été apportées au manifeste du package et que le fichier initial resources.resw a été créé, l’ajout de langues supplémentaires est facile.

Créer des ressources localisées supplémentaires

Tout d’abord, créez les valeurs de ressources localisées supplémentaires.

Dans le Strings dossier, créez des dossiers supplémentaires pour chaque langue que vous prenez en charge à l’aide du code BCP-47 approprié (par exemple). Strings\de-DE Dans chacun de ces dossiers, créez un resources.resw fichier (à l’aide d’un éditeur XML ou du concepteur Visual Studio) qui inclut les valeurs de ressources traduites. Il est supposé que vous disposez déjà des chaînes localisées disponibles quelque part, et que vous devez simplement les copier dans le .resw fichier ; ce document ne couvre pas l’étape de traduction elle-même.

Par exemple, le fichier Strings\de-DE\resources.resw peut ressembler à ceci, avec le texte mis en surbrillance remplacé par en-US:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="ApplicationDescription">
    <value>Contoso Demo app with localized resources (German)</value>
  </data>
  <data name="ApplicationDisplayName">
    <value>Contoso Demo Sample (German)</value>
  </data>
  <data name="PackageDisplayName">
    <value>Contoso Demo Package (German)</value>
  </data>
  <data name="PublisherDisplayName">
    <value>Contoso Samples, DE</value>
  </data>
  <data name="TileShortName">
    <value>Contoso (DE)</value>
  </data>
</root>

Les étapes suivantes supposent que vous avez ajouté des ressources pour les deux de-DE et fr-FR, mais le même modèle peut être suivi pour n’importe quelle langue.

Mettre à jour le manifeste du package pour répertorier les langues prises en charge

Le manifeste du package doit être mis à jour pour répertorier les langues prises en charge par l’application. Desktop App Converter ajoute la langue par défaut, mais les autres doivent être ajoutés explicitement. Si vous modifiez directement le fichier AppxManifest.xml, mettez à jour le nœud Resources comme suit : ajoutez autant d’éléments que nécessaire et remplacez-les par les langues appropriées que vous supportez, en veillant à ce que la première entrée de la liste soit la langue par défaut (de repli). Dans cet exemple, la valeur par défaut est l’anglais (ÉTATS-Unis) avec une prise en charge supplémentaire pour l’allemand (Allemagne) et le français (France) :

<Resources>
  <Resource Language="EN-US" />
  <Resource Language="DE-DE" />
  <Resource Language="FR-FR" />
</Resources>

Si vous utilisez Visual Studio, vous n'avez pas besoin de faire quoi que ce soit ; si vous examinez Package.appxmanifest, vous devriez voir la valeur spéciale x-générer, ce qui fait que le processus de compilation insère les langues qu'il détecte dans votre projet (en fonction des dossiers nommés avec des codes BCP-47). Notez qu’il ne s’agit pas d’une valeur valide pour un manifeste de package réel ; il fonctionne uniquement pour les projets Visual Studio :

<Resources>
  <Resource Language="x-generate" />
</Resources>

Recréer avec les valeurs localisées

Vous pouvez maintenant générer et déployer votre application, à nouveau et si vous modifiez votre préférence de langue dans Windows, vous devez voir les valeurs nouvellement localisées s’afficher dans le menu Démarrer (des instructions pour modifier votre langue sont ci-dessous).

Pour Visual Studio, là encore, vous pouvez simplement utiliser Ctrl+Shift+B pour générer, puis cliquer avec le bouton droit sur le projet .Deploy

Si vous générez manuellement le projet, suivez les mêmes étapes que celles ci-dessus, mais ajoutez les langues supplémentaires, séparées par des traits de soulignement, à la liste des qualificateurs par défaut (/dq) lors de la création du fichier de configuration. Par exemple, pour prendre en charge les ressources anglaises, allemandes et françaises ajoutées à l’étape précédente :

makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_fr-FR /pv 10.0 /o

Cela crée un fichier PRI qui contient toutes les langues spécifiées que vous pouvez facilement utiliser pour les tests. Si la taille totale de vos ressources est réduite ou si vous ne prenez en charge qu’un petit nombre de langues, cela peut être acceptable pour votre application; c'est seulement si vous souhaitez minimiser la taille des fichiers lors de l'installation ou du téléchargement de vos ressources que vous devez entreprendre le travail supplémentaire de création de packs linguistiques distincts.

Tester avec les valeurs localisées

Pour tester les nouvelles modifications localisées, vous ajoutez simplement une nouvelle langue d’interface utilisateur préférée à Windows. Il n’est pas nécessaire de télécharger les modules linguistiques, de redémarrer le système ou d’afficher l’ensemble de votre interface utilisateur Windows dans une langue étrangère.

1. Exécuter l’application Settings (Windows + I)
2. Accédez à Time & language
3. Accédez à Region & language
4. Cliquez sur Add a language
5. Tapez (ou sélectionnez) la langue souhaitée (par exemple Deutsch ou German)
   • S’il existe des sous-langues, choisissez celle souhaitée (par exemple, Deutsch / Deutschland)
6. Sélectionnez la nouvelle langue dans la liste des langues
7. Cliquez sur Set as default

Ouvrez maintenant le menu Démarrer et recherchez votre application, et vous devez voir les valeurs localisées pour la langue sélectionnée (d’autres applications peuvent également apparaître localisées). Si vous ne voyez pas le nom localisé immédiatement, attendez quelques minutes jusqu’à ce que le cache du menu Démarrer soit actualisé. Pour revenir à votre langue native, il vous suffit de le rendre la langue par défaut dans la liste des langues.

Étape 1.4 : Localisation d’autres parties du manifeste de package (facultatif)

D’autres sections du manifeste de package peuvent être localisées. Par exemple, si votre application gère les extensions de fichiers, elle doit avoir une windows.fileTypeAssociation extension dans le manifeste, en utilisant le texte en surbrillance vert exactement comme indiqué (car elle fait référence à des ressources) et en remplaçant le texte en surbrillance jaune par des informations spécifiques à votre application :

<Extensions>
  <uap:Extension Category="windows.fileTypeAssociation">
    <uap:FileTypeAssociation Name="default">
      <uap:DisplayName>ms-resource:Resources/FileTypeDisplayName</uap:DisplayName>
      <uap:Logo>Assets\StoreLogo.png</uap:Logo>
      <uap:InfoTip>ms-resource:Resources/FileTypeInfoTip</uap:InfoTip>
      <uap:SupportedFileTypes>
        <uap:FileType ContentType="application/x-contoso">.contoso</uap:FileType>
      </uap:SupportedFileTypes>
    </uap:FileTypeAssociation>
  </uap:Extension>
</Extensions>

Vous pouvez également ajouter ces informations à l’aide du Concepteur de manifeste Visual Studio, à l’aide de l’onglet Declarations , en prenant note des valeurs mises en surbrillance :

Ajoutez maintenant les noms de ressources correspondants à chacun de vos .resw fichiers, en remplaçant le texte mis en surbrillance par le texte approprié pour votre application (n’oubliez pas de le faire pour chaque langue prise en charge !) :

... existing content...
<data name="FileTypeDisplayName">
  <value>Contoso Demo File</value>
</data>
<data name="FileTypeInfoTip">
  <value>Files used by Contoso Demo App</value>
</data>

Cela s’affiche ensuite dans des parties de l’interpréteur de commandes Windows, telles que l’Explorateur de fichiers :

Générez et testez le package comme avant, en faisant l’exercice de tous les nouveaux scénarios qui doivent afficher les nouvelles chaînes d’interface utilisateur.

Phase 2 : Utiliser MRT pour identifier et localiser les ressources

La section précédente a montré comment utiliser MRT pour localiser le fichier manifeste de votre application afin que Windows Shell puisse afficher correctement le nom de l’application et d’autres métadonnées. Aucune modification du code n’a été nécessaire pour cela ; il suffit d’utiliser des .resw fichiers et d’autres outils. Cette section montre comment utiliser MRT pour localiser des ressources dans vos formats de ressources existants et utiliser votre code de gestion des ressources existant avec des modifications minimales.

Hypothèses relatives à la disposition de fichier existante et au code d’application

Étant donné qu’il existe de nombreuses façons de localiser des applications Win32 Desktop, ce document simplifie certaines hypothèses sur la structure de l’application existante que vous devrez mapper à votre environnement spécifique. Vous devrez peut-être apporter des modifications à votre disposition de code ou de ressource existante pour respecter les exigences de MRT, et celles-ci sont largement hors de portée pour ce document.

Disposition des fichiers de ressources

Cet article suppose que vos ressources localisées ont tous les mêmes noms de fichiers (par exemple, contoso_demo.exe.mui ou contoso_strings.dllcontoso.strings.xml) mais qu’elles sont placées dans différents dossiers avec des noms BCP-47 (en-US, de-DEetc.). Il n’importe pas combien de fichiers de ressources vous avez, quels sont leurs noms, quels sont leurs formats de fichiers / API associées, etc. La seule chose qui importe est que chaque ressource logique a le même nom de fichier (mais placé dans un autre répertoire physique ).

À titre de contre-exemple, si votre application utilise une structure de fichiers plate avec un seul répertoire Resources contenant les fichiers english_strings.dll et french_strings.dll, elle ne s'adapterait pas bien à MRT. Une meilleure structure serait un Resources répertoire avec des sous-répertoires et des fichiers en\strings.dll et fr\strings.dll. Il est également possible d’utiliser le même nom de fichier de base, mais avec des qualificateurs incorporés, tels que strings.lang-en.dll et strings.lang-fr.dll, mais l’utilisation de répertoires avec les codes de langage est conceptuellement plus simple, c’est ce que nous allons nous concentrer sur.

Par exemple, l’application peut avoir un ensemble de commandes d’interface utilisateur personnalisées (utilisées pour les étiquettes de boutons, etc.) dans un fichier texte simple nommé ui.txt, disposé sous un dossier UICommands :

+ ProjectRoot
|--+ Strings
|  |--+ en-US
|  |  \--- resources.resw
|  \--+ de-DE
|     \--- resources.resw
|--+ UICommands
|  |--+ en-US
|  |  \--- ui.txt
|  \--+ de-DE
|     \--- ui.txt
|--- AppxManifest.xml
|--- ...rest of project...

Code de chargement des ressources

Cet article suppose qu’à un moment donné dans votre code, vous souhaitez localiser le fichier qui contient une ressource localisée, le charger, puis l’utiliser. Les API utilisées pour charger les ressources, les API utilisées pour extraire les ressources, etc. ne sont pas importantes. En pseudocode, il existe essentiellement trois étapes :

set userLanguage = GetUsersPreferredLanguage()
set resourceFile = FindResourceFileForLanguage(MY_RESOURCE_NAME, userLanguage)
set resource = LoadResource(resourceFile) 
    
// now use 'resource' however you want

MRT nécessite uniquement de modifier les deux premières étapes de ce processus : la façon dont vous déterminez les meilleures ressources candidates et la façon dont vous les trouvez. Il ne vous oblige pas à modifier la façon dont vous chargez ou utilisez les ressources (même s’il fournit des installations pour le faire si vous souhaitez en tirer parti).

Par exemple, l’application peut utiliser l’API GetUserPreferredUILanguagesWin32, la fonction sprintfCRT et l’API CreateFile Win32 pour remplacer les trois fonctions pseudocode ci-dessus, puis analyser manuellement le fichier texte à la recherche name=value de paires. (Les détails ne sont pas importants ; il s’agit simplement d’illustrer que mrT n’a aucun impact sur les techniques utilisées pour gérer les ressources une fois qu’elles ont été localisées).

Étape 2.1 : Modifications du code permettant d’utiliser MRT pour localiser les fichiers

Changer votre code pour la localisation des ressources avec MRT n’est pas difficile. Il nécessite l’utilisation d’un certain nombre de types WinRT et de quelques lignes de code. Les principaux types que vous utiliserez sont les suivants :

• ResourceContext, qui encapsule l’ensemble actif de valeurs de qualificateur (langage, facteur d’échelle, etc.)
• ResourceManager (version WinRT, et non la version .NET), qui permet d’accéder à toutes les ressources à partir du fichier PRI
• ResourceMap, qui représente un sous-ensemble spécifique des ressources dans le fichier PRI (dans cet exemple, les ressources basées sur les fichiers et les ressources de chaîne)
• NamedResource, qui représente une ressource logique et l'ensemble de ses candidats possibles
• ResourceCandidate, qui représente une seule ressource candidate concrète

Dans le pseudo-code, la façon dont vous devez résoudre un nom de fichier de ressource donné (comme UICommands\ui.txt dans l’exemple ci-dessus) est la suivante :

// Get the ResourceContext that applies to this app
set resourceContext = ResourceContext.GetForViewIndependentUse()
    
// Get the current ResourceManager (there's one per app)
set resourceManager = ResourceManager.Current
    
// Get the "Files" ResourceMap from the ResourceManager
set fileResources = resourceManager.MainResourceMap.GetSubtree("Files")
    
// Find the NamedResource with the logical filename we're looking for,
// by indexing into the ResourceMap
set desiredResource = fileResources["UICommands\ui.txt"]
    
// Get the ResourceCandidate that best matches our ResourceContext
set bestCandidate = desiredResource.Resolve(resourceContext)
   
// Get the string value (the filename) from the ResourceCandidate
set absoluteFileName = bestCandidate.ValueAsString

Notez en particulier que le code n'pas demander un dossier de langage spécifique, comme UICommands\en-US\ui.txt, même si c’est la façon dont les fichiers existent sur disque. Plutôt, il demande le nom de fichier logique UICommands\ui.txt et s’appuie sur MRT pour trouver le fichier approprié sur disque dans l’un des répertoires de langues.

À partir de là, l’exemple d’application peut continuer à utiliser CreateFile pour charger et analyser les paires absoluteFileName de la même manière qu'avant ; aucune de cette logique n'a besoin d'être modifiée dans l’application. Si vous écrivez en C# ou C++/CX, le code réel n’est pas beaucoup plus compliqué que cela (et, en fait, la plupart des variables intermédiaires peuvent être supprimées) - consultez la section sur le chargement des ressources .NET, ci-dessous. Les applications basées sur C++/WRL seront plus complexes en raison des API COM de bas niveau utilisées pour activer et appeler les API WinRT, mais les étapes fondamentales que vous effectuez sont les mêmes : consultez la section sur le chargement des ressources MUI Win32, ci-dessous.

Chargement des ressources .NET

Étant donné que .NET dispose d’un mécanisme intégré pour localiser et charger des ressources (appelées « Assemblys satellites »), il n’existe aucun code explicite à remplacer comme dans l’exemple synthétique ci-dessus : dans .NET, vous avez simplement besoin de dll de ressources dans les répertoires appropriés et ils sont automatiquement situés pour vous. Lorsqu’une application est empaquetée en tant que MSIX ou .appx à l’aide de packs de ressources, la structure de répertoires est un peu différente , au lieu d’avoir les répertoires de ressources sous-répertoires du répertoire d’application principal, ils sont homologues de celui-ci (ou ne sont pas présents du tout si l’utilisateur n’a pas la langue répertoriée dans leurs préférences).

Par exemple, imaginez une application .NET avec la disposition suivante, où tous les fichiers existent sous le MainApp dossier :

+ MainApp
|--+ en-us
|  \--- MainApp.resources.dll
|--+ de-de
|  \--- MainApp.resources.dll
|--+ fr-fr
|  \--- MainApp.resources.dll
\--- MainApp.exe

Après la conversion en .appx, la disposition ressemble à ceci, en supposant que en-US la langue par défaut était la langue par défaut et que l’utilisateur a à la fois l’allemand et le français répertoriés dans leur liste de langues :

+ WindowsAppsRoot
|--+ MainApp_neutral
|  |--+ en-us
|  |  \--- MainApp.resources.dll
|  \--- MainApp.exe
|--+ MainApp_neutral_resources.language_de
|  \--+ de-de
|     \--- MainApp.resources.dll
\--+ MainApp_neutral_resources.language_fr
   \--+ fr-fr
      \--- MainApp.resources.dll

Étant donné que les ressources localisées n’existent plus dans les sous-répertoires sous l’emplacement d’installation du fichier exécutable principal, la résolution de ressources .NET intégrée échoue. Heureusement, .NET dispose d’un mécanisme bien défini pour gérer les tentatives de chargement d’assembly ayant échoué : l’événement AssemblyResolve . Une application .NET utilisant MRT doit s’inscrire pour cet événement et fournir l’assembly manquant pour le sous-système de ressources .NET.

Voici un exemple concis d’utilisation des API WinRT pour localiser les assemblys satellites utilisés par .NET ; le code tel qu’il est présenté est intentionnellement compressé pour afficher une implémentation minimale, bien que vous puissiez le voir mapper étroitement au pseudo-code ci-dessus ResolveEventArgs , avec le passage en fournissant le nom de l’assembly que nous devons localiser. Vous trouverez une version exécutable de ce code (avec des commentaires détaillés et une gestion des erreurs) dans le fichier PriResourceRsolver.cs dans l’exemple de la résolution d’assembly .NET sur GitHub.

static class PriResourceResolver
{
  internal static Assembly ResolveResourceDll(object sender, ResolveEventArgs args)
  {
    var fullAssemblyName = new AssemblyName(args.Name);
    var fileName = string.Format(@"{0}.dll", fullAssemblyName.Name);

    var resourceContext = ResourceContext.GetForViewIndependentUse();
    resourceContext.Languages = new[] { fullAssemblyName.CultureName };

    var resource = ResourceManager.Current.MainResourceMap.GetSubtree("Files")[fileName];

    // Note use of 'UnsafeLoadFrom' - this is required for apps installed with .appx, but
    // in general is discouraged. The full sample provides a safer wrapper of this method
    return Assembly.UnsafeLoadFrom(resource.Resolve(resourceContext).ValueAsString);
  }
}

Étant donné la classe ci-dessus, vous ajouteriez ce qui suit quelque part tôt dans le code de démarrage de votre application (avant que des ressources localisées ne doivent être chargées) :

void EnableMrtResourceLookup()
{
  AppDomain.CurrentDomain.AssemblyResolve += PriResourceResolver.ResolveResourceDll;
}

Le runtime .NET déclenche l’événement AssemblyResolve chaque fois qu’il ne trouve pas les DLL de ressource, à quel moment le gestionnaire d’événements fourni localisera le fichier souhaité via MRT et retournera l’assembly.

Chargement des ressources MUI Win32

Le chargement des ressources MUI Win32 est essentiellement identique au chargement d’assemblys satellites .NET, mais à l’aide de code C++/CX ou C++/WRL à la place. L'utilisation de C++/CX permet d'écrire un code beaucoup plus simple qui correspond étroitement au code C# ci-dessus, mais il utilise des extensions de langage C++, des commutateurs de compilateur, ainsi qu'une surcharge d'exécution supplémentaire que vous pourriez vouloir éviter. Si c’est le cas, l’utilisation de C++/WRL offre une solution à impact beaucoup plus faible au coût d’un code plus détaillé. Néanmoins, si vous êtes familiarisé avec la programmation ATL (ou COM en général), WRL devrait vous sembler familier.

L’exemple de fonction suivant montre comment utiliser C++/WRL pour charger une DLL de ressource spécifique et retourner une HINSTANCE ressource qui peut être utilisée pour charger d’autres ressources à l’aide des API de ressources Win32 habituelles. Notez que contrairement à l’exemple C# qui initialise explicitement la ResourceContext langue demandée par le runtime .NET, ce code s’appuie sur le langage actuel de l’utilisateur.

#include <roapi.h>
#include <wrl\client.h>
#include <wrl\wrappers\corewrappers.h>
#include <Windows.ApplicationModel.resources.core.h>
#include <Windows.Foundation.h>
   
#define IF_FAIL_RETURN(hr) if (FAILED((hr))) return hr;
    
HRESULT GetMrtResourceHandle(LPCWSTR resourceFilePath,  HINSTANCE* resourceHandle)
{
  using namespace Microsoft::WRL;
  using namespace Microsoft::WRL::Wrappers;
  using namespace ABI::Windows::ApplicationModel::Resources::Core;
  using namespace ABI::Windows::Foundation;
    
  *resourceHandle = nullptr;
  HRESULT hr{ S_OK };
  RoInitializeWrapper roInit{ RO_INIT_SINGLETHREADED };
  IF_FAIL_RETURN(roInit);
    
  // Get Windows.ApplicationModel.Resources.Core.ResourceManager statics
  ComPtr<IResourceManagerStatics> resourceManagerStatics;
  IF_FAIL_RETURN(GetActivationFactory(
    HStringReference(
    RuntimeClass_Windows_ApplicationModel_Resources_Core_ResourceManager).Get(),
    &resourceManagerStatics));
    
  // Get .Current property
  ComPtr<IResourceManager> resourceManager;
  IF_FAIL_RETURN(resourceManagerStatics->get_Current(&resourceManager));
    
  // get .MainResourceMap property
  ComPtr<IResourceMap> resourceMap;
  IF_FAIL_RETURN(resourceManager->get_MainResourceMap(&resourceMap));
    
  // Call .GetValue with supplied filename
  ComPtr<IResourceCandidate> resourceCandidate;
  IF_FAIL_RETURN(resourceMap->GetValue(HStringReference(resourceFilePath).Get(),
    &resourceCandidate));
    
  // Get .ValueAsString property
  HString resolvedResourceFilePath;
  IF_FAIL_RETURN(resourceCandidate->get_ValueAsString(
    resolvedResourceFilePath.GetAddressOf()));
    
  // Finally, load the DLL and return the hInst.
  *resourceHandle = LoadLibraryEx(resolvedResourceFilePath.GetRawBuffer(nullptr),
    nullptr, LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE);
    
  return S_OK;
}

Phase 3 : Création de packs de ressources

Maintenant que vous disposez d’un « fat pack » qui contient toutes les ressources, il existe deux chemins vers la création de packages principaux et de packages de ressources distincts afin de réduire les tailles de téléchargement et d’installation :

• Prenez un fat pack existant et exécutez-le via l’outil Bundle Generator pour créer automatiquement des packs de ressources. Il s’agit de l’approche recommandée si vous avez un système de build qui produit déjà un package intégré et que vous souhaitez le post-traiter pour générer les packs de ressources.
• Produisez directement les paquets de ressources individuels et intégrez-les dans un ensemble. Il s’agit de l’approche recommandée si vous avez plus de contrôle sur votre système de build et que vous pouvez générer les packages directement.

Étape 3.1 : Création de l’offre groupée

Utilisation de l’outil Bundle Generator

Pour utiliser l’outil Bundle Generator, le fichier de configuration PRI créé pour le package doit être mis à jour manuellement pour supprimer la <packaging> section.

Si vous utilisez Visual Studio, reportez-vous à Assurez-vous que les ressources sont installées sur un appareil, indépendamment de si l’appareil en a besoin pour plus d’informations sur la manière d'intégrer toutes les langues dans le package principal en créant les fichiers priconfig.packaging.xml et priconfig.default.xml.

Si vous modifiez manuellement des fichiers, procédez comme suit :

1. Créez le fichier de configuration de la même façon que précédemment, en remplaçant le chemin d’accès, le nom de fichier et les langues appropriés :

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_es-MX /pv 10.0 /o
   

2. Ouvrez manuellement le fichier créé .xml et supprimez l’intégralité <packaging&rt; de la section (mais conservez tout le reste intact) :

   <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
   <resources targetOsVersion="10.0.0" majorVersion="1">
     <!-- Packaging section has been deleted... -->
     <index root="\" startIndexAt="\">
       <default>
       ...
       ...
   

3. Générez le .pri fichier et le .appx package comme avant, à l’aide du fichier de configuration mis à jour et du répertoire et des noms de fichiers appropriés (voir ci-dessus pour plus d’informations sur ces commandes) :

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /o
   

4. Une fois le package créé, utilisez la commande suivante pour créer le bundle à l’aide du répertoire et des noms de fichiers appropriés :

   BundleGenerator.exe -Package ..\contoso_demo.appx -Destination ..\bundle -BundleName contoso_demo
   

Vous pouvez maintenant passer à l’étape finale, signature (voir ci-dessous).

Création manuelle de packages de ressources

La création manuelle de packages de ressources nécessite l’exécution d’un ensemble légèrement différent de commandes pour générer des fichiers distincts .pri et .appx. Ces commandes sont toutes similaires à celles utilisées ci-dessus pour créer des packages volumineux, et une explication minimale est fournie. Remarque : toutes les commandes supposent que le répertoire actif est le répertoire contenant le AppXManifest.xml fichier, mais tous les fichiers sont placés dans le répertoire parent (vous pouvez utiliser un autre répertoire, si nécessaire, mais vous ne devez pas polluer le répertoire du projet avec l’un de ces fichiers). Comme toujours, remplacez les noms de fichiers « Contoso » par vos propres noms de fichiers.

1. Utilisez la commande suivante pour créer un fichier de configuration qui nomme uniquement la langue par défaut comme qualificateur par défaut , dans ce cas : en-US

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
   

2. Créez un fichier .pri et .map.txt par défaut pour le package principal, ainsi qu’un ensemble supplémentaire de fichiers pour chaque langue trouvée dans votre projet, avec la commande suivante :

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   

3. Utilisez la commande suivante pour créer le package principal (qui contient le code exécutable et les ressources linguistiques par défaut). Comme toujours, modifiez le nom comme vous le voyez, bien que vous deviez placer le package dans un répertoire distinct pour faciliter la création du bundle plus tard (cet exemple utilise le ..\bundle répertoire) :

   makeappx pack /m .\AppXManifest.xml /f ..\resources.map.txt /p ..\bundle\contoso_demo.main.appx /o
   

4. Une fois le package principal créé, utilisez la commande suivante une fois pour chaque langue supplémentaire (par exemple, répétez cette commande pour chaque fichier de mappage de langue généré à l’étape précédente). Là encore, la sortie doit se trouver dans un répertoire distinct (identique à celui du package principal). Notez que la langue est spécifiée à la fois dans l’option /f et dans l’option /p , ainsi que l’utilisation du nouvel /r argument (ce qui indique qu’un package de ressources est souhaité) :

   makeappx pack /r /m .\AppXManifest.xml /f ..\resources.language-de.map.txt /p ..\bundle\contoso_demo.de.appx /o
   

5. Combinez tous les packages du répertoire de bundle dans un seul .appxbundle fichier. La nouvelle /d option spécifie le répertoire à utiliser pour tous les fichiers du bundle (c’est pourquoi les .appx fichiers sont placés dans un répertoire distinct à l’étape précédente) :

   makeappx bundle /d ..\bundle /p ..\contoso_demo.appxbundle /o
   

La dernière étape de création du package est la signature.

Étape 3.2 : Signature de l’offre groupée

Une fois que vous avez créé le .appxbundle fichier (via l’outil Bundle Generator ou manuellement), vous disposez d’un fichier unique qui contient le package principal et tous les packages de ressources. La dernière étape consiste à signer le fichier afin que Windows l’installe :

signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appxbundle

Cela produit un fichier signé .appxbundle qui contient le package principal ainsi que tous les packages de ressources spécifiques à la langue. Il peut être double-cliqué comme un fichier de package pour installer l’application, ainsi que toutes les langues appropriées en fonction des préférences de langue Windows de l’utilisateur.

Contenu connexe

• Personnaliser vos ressources pour la langue, l’échelle, le contraste élevé et d’autres qualificateurs