Développer avec des packages d’actifs et la mise en dossier des packages

Important

si vous envisagez de soumettre votre application au windows Store, vous devez contacter Windows support technique pour les développeurs et recevoir une approbation pour utiliser les packages d’actifs et le repli des packages.

Les packages de ressources peuvent réduire la taille globale de l’empaquetage et l’heure de publication de vos applications dans le Windows Store. Vous pouvez en savoir plus sur les packages d’actifs et savoir comment il peut accélérer vos itérations de développement à l' introduction des packages d’actifs.

Si vous envisagez d’utiliser des packages de ressources pour votre application ou si vous savez déjà que vous souhaitez les utiliser, vous vous demandez probablement comment les packages de ressources changeront votre processus de développement. En bref, le développement d’applications pour vous reste le même : cela est possible en raison du repli de package pour les packages d’actifs.

Accès aux fichiers après le fractionnement de votre application

Pour comprendre comment le repli de package n’a pas d’impact sur votre processus de développement, revenons tout d’abord pour comprendre ce qui se passe lorsque vous fractionnez votre application en plusieurs packages (avec des packages de ressources ou des packages de ressources).

À un niveau élevé, lorsque vous fractionnez certains fichiers de votre application dans d’autres packages (qui ne sont pas des packages d’architecture), vous ne pourrez pas accéder directement à ces fichiers par rapport à l’emplacement d’exécution de votre code. Cela est dû au fait que ces packages sont tous installés dans différents répertoires à partir desquels votre package d’architecture est installé. Par exemple, si vous faites un jeu et que votre jeu est localisé en français et en allemand et que vous avez créé pour les ordinateurs x86 et x64, vous devez disposer de ces fichiers de package d’application dans le bundle d’applications de votre jeu :

• MyGame_1.0_x86. AppX
• MyGame_1.0_x64. AppX
• MyGame_1.0_language-fr. AppX
• MyGame_1.0_language-de. AppX

Lorsque votre jeu est installé sur l’ordinateur d’un utilisateur, chaque fichier de package d’application aura son propre dossier dans le répertoire WindowsApps ainsi, pour un utilisateur français qui exécute 64 bits Windows, votre jeu se présente comme suit :

C:\Program Files\WindowsApps\
|-- MyGame_1.0_x64
|   `-- …
|-- MyGame_1.0_language-fr
|   `-- …
`-- …(other apps)

Notez que les fichiers de package d’application qui ne sont pas applicables à l’utilisateur ne sont pas installés (les packages x86 et allemand).

Pour cet utilisateur, le fichier exécutable principal de votre jeu se trouve dans le dossier MyGame_1.0 _x64 et s’exécute à partir de là, et normalement, il aura uniquement accès aux fichiers contenus dans ce dossier. Pour accéder aux fichiers contenus dans le dossier MyGame_1 0/b _language-fr , vous devez utiliser les API MRT ou les API packagemanager. Les API MRT peuvent sélectionner automatiquement le fichier le plus approprié à partir des langues installées. vous trouverez plus d’informations sur les API MRT sur Windows. ApplicationModel. resources. Core. Vous pouvez également trouver l’emplacement d’installation du package de langue française à l’aide de la classe packagemanager. Vous ne devez jamais supposer l’emplacement d’installation des packages de votre application, car cela peut changer et peut varier d’un utilisateur à l’autre.

Repli du package de ressources

Comment pouvez-vous accéder aux fichiers de vos packages de ressources ? Vous pouvez continuer à utiliser les API d’accès aux fichiers que vous utilisez pour accéder à n’importe quel autre fichier dans votre package d’architecture. Cela est dû au fait que les fichiers de package de ressources sont repliés dans votre package d’architecture lorsqu’ils sont installés par le biais du processus de pliage de package. En outre, étant donné que les fichiers de package de ressources doivent être initialement des fichiers dans vos packages d’architecture, cela signifie que vous n’aurez pas à modifier l’utilisation de l’API lorsque vous passerez du déploiement de fichiers libres au déploiement empaqueté dans votre processus de développement.

Pour en savoir plus sur le fonctionnement du repli de package, commençons par un exemple. Si vous avez un projet de jeu avec la structure de fichiers suivante :

MyGame
|-- Audios
|   |-- Level1
|   |   `-- ...
|   `-- Level2
|       `-- ...
|-- Videos
|   |-- Level1
|   |   `-- ...
|   `-- Level2
|       `-- ...
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe

Si vous souhaitez diviser votre jeu en 3 packages : un package d’architecture x64, un package de ressources audio et un package de ressources pour les vidéos, votre jeu sera divisé en ces packages :

MyGame_1.0_x64.appx
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe
MyGame_1.0_Audios.appx
`-- Audios
    |-- Level1
    |   `-- ...
    `-- Level2
        `-- ...
MyGame_1.0_Videos.appx
`-- Videos
    |-- Level1
    |   `-- ...
    `-- Level2
        `-- ...

Lorsque vous installez votre jeu, le package x64 est déployé en premier. Ensuite, les deux packages de ressources seront déployés dans leurs propres dossiers, tout comme MyGame_1 0.0 _language-fr de notre exemple précédent. Toutefois, en raison du repliement de package, les fichiers du package de ressources seront également liés en dur pour apparaître dans le dossier MyGame_1.0 _x64 (par conséquent, même si les fichiers apparaissent dans deux emplacements, ils n’occupent pas deux fois l’espace disque). L’emplacement dans lequel les fichiers du package de ressources apparaissent dans correspond exactement à l’emplacement où ils se trouvent, par rapport à la racine du package. Voici à quoi ressemble la mise en page finale du jeu déployé :

C:\Program Files\WindowsApps\
|-- MyGame_1.0_x64
|   |-- Audios
|   |   |-- Level1
|   |   |   `-- ...
|   |   `-- Level2
|   |       `-- ...
|   |-- Videos
|   |   |-- Level1
|   |   |   `-- ...
|   |   `-- Level2
|   |       `-- ...
|   |-- Engine
|   |   `-- ...
|   |-- XboxLive
|   |   `-- ...
|   `-- Game.exe
|-- MyGame_1.0_Audios
|   `-- Audios
|       |-- Level1
|       |   `-- ...
|       `-- Level2
|           `-- ...
|-- MyGame_1.0_Videos
|   `-- Videos
|       |-- Level1
|       |   `-- ...
|       `-- Level2
|           `-- ...
`-- …(other apps)

Lorsque vous utilisez le repli de package pour les packages d’actifs, vous pouvez toujours accéder aux fichiers que vous avez fractionnés dans les packages d’actifs de la même façon (Notez que le dossier architecture a exactement la même structure que le dossier de projet d’origine) et vous pouvez ajouter des packages d’actifs ou déplacer des fichiers entre des packages de ressources sans affecter votre code.

À présent, pour un exemple de pliage de package plus complexe. Supposons que vous souhaitiez fractionner vos fichiers en fonction du niveau et que si vous souhaitez conserver la même structure que le dossier du projet d’origine, vos packages doivent ressembler à ceci :

MyGame_1.0_x64.appx
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe
MyGame_Level1.appx
|-- Audios
|   `-- Level1
|       `-- ...
`-- Videos
    `-- Level1
        `-- ...

MyGame_Level2.appx
|-- Audios
|   `-- Level2
|       `-- ...
`-- Videos
    `-- Level2
        `-- ...

Cela permet de fusionner les dossiers et les fichiers de niveau1 dans le package MyGame_Level1 , ainsi que les fichiers et les dossiers de d’isolement2 dans le package MyGame_Level2 dans les dossiers audio et vidéo pendant le repli du package. Ainsi, en règle générale, le chemin d’accès relatif désigné pour les fichiers empaquetés dans le fichier de mappage ou la disposition d’empaquetage pour MakeAppx.exe est le chemin d’accès que vous devez utiliser pour y accéder après le repli du package.

Enfin, s’il existe deux fichiers dans différents packages de ressources qui ont les mêmes chemins d’accès relatifs, cela entraînera une collision lors du repli du package. Si une collision se produit, le déploiement de votre application génère une erreur et échoue. En outre, le pliage de package tirant parti des liens physiques, si vous utilisez des packages de ressources, votre application ne pourra pas être déployée sur des lecteurs non NTFS. Si vous savez que votre application sera probablement déplacée vers des lecteurs amovibles par vos utilisateurs, vous ne devez pas utiliser de packages de ressources.