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 le support technique du développeur Windows et obtenir l’approbation pour utiliser les packages d’éléments multimédias et le pliage de packages.

Les packages d’éléments multimédias peuvent réduire la taille globale de l’empaquetage et le temps de publication de vos applications dans le Windows Store. Vous pouvez en savoir plus sur les packages d’éléments multimédias et la façon dont il peut accélérer vos itérations de développement lors de l’introduction aux packages d’éléments multimédias.

Si vous envisagez d’utiliser des packages de ressources pour votre application ou que vous savez déjà que vous souhaitez l’utiliser, vous vous demandez probablement comment les packages d’actifs 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 pliage de package pour les packages d’éléments multimédias.

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 en premier 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 en d’autres packages (qui ne sont pas des packages d’architecture), vous ne pourrez pas accéder directement à ces fichiers par rapport à l’endroit où votre code s’exécute. Cela est dû au fait que ces packages sont tous installés dans différents répertoires à partir de l’emplacement d’installation de votre package d’architecture. Par exemple, si vous créez un jeu et que votre jeu est localisé en Français et en allemand et que vous avez créé pour les machines x86 et x64, vous devez disposer de ces fichiers de package d’application dans l’ensemble 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 . Par conséquent, pour un utilisateur Français exécutant Windows 64 bits, 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 seront pas installés (les packages x86 et allemands).

Pour cet utilisateur, l’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 de ce dossier. Pour accéder aux fichiers dans le dossier MyGame_1.0_language-fr , vous devez utiliser les API MRT ou les API PackageManager. Les API MRT peuvent sélectionner automatiquement le fichier le plus approprié dans les langues installées, vous pouvez en savoir plus sur les API MRT sur Windows.ApplicationModel.Resources.Core. Vous pouvez également trouver l’emplacement installé du package de langue Français à l’aide de la classe PackageManager. Vous ne devez jamais supposer l’emplacement installé des packages de votre application, car cela peut changer et varier entre les utilisateurs.

Pliage du package de ressources

Comment pouvez-vous accéder aux fichiers dans 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 d’éléments multimédias sont pliés dans votre package d’architecture lorsqu’ils sont installés via le processus de pliage du package. En outre, étant donné que les fichiers de package de ressources doivent initialement être des fichiers dans vos packages d’architecture, cela signifie que vous n’avez pas à modifier l’utilisation de l’API lorsque vous passez du déploiement de fichiers libres au déploiement empaqueté dans votre processus de développement.

Pour en savoir plus sur le fonctionnement du pliage des packages, 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 fractionner votre jeu en 3 packages : un package d’architecture x64, un package d’éléments multimédias pour les audios et un package de ressources pour les vidéos, votre jeu sera divisé en packages suivants :

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 toujours déployés dans leurs propres dossiers, tout comme MyGame_1.0_language-fr de notre exemple précédent. Toutefois, en raison du pliage de package, les fichiers de package de ressources sont également difficilement liés à apparaître dans le dossier MyGame_1.0_x64 (ainsi, même si les fichiers apparaissent à deux emplacements, ils ne prennent pas deux fois l’espace disque). L’emplacement dans lequel les fichiers du package d’éléments multimédias s’affichent est exactement l’emplacement auquel ils se trouvent par rapport à la racine du package. Voici à quoi ressemblera la disposition 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 pliage de package pour les packages d’éléments multimédias, vous pouvez toujours accéder aux fichiers que vous avez divisés en packages d’éléments multimédias de la même façon (notez que le dossier d’architecture a exactement la même structure que le dossier de projet d’origine), et vous pouvez ajouter des packages d’éléments multimédias ou déplacer des fichiers entre des packages d’éléments multimédias sans avoir d’impact sur votre code.

Maintenant, pour un exemple de pliage de package plus complexe. Supposons que vous souhaitez fractionner vos fichiers en fonction du niveau à la place et si vous souhaitez conserver la même structure que le dossier de 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 aux dossiers et fichiers Level1 du package MyGame_Level1 et aux dossiers et fichiers Level2 du package MyGame_Level2 d’être fusionnés dans les dossiers Audios et Vidéos pendant le pliage 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 que vous devez utiliser pour y accéder après le pliage du package.

Enfin, s’il existe deux fichiers dans des packages de ressources différents qui ont les mêmes chemins relatifs, cela entraîne une collision pendant le pliage du package. Si une collision se produit, le déploiement de votre application entraîne une erreur et échoue. En outre, étant donné que le pliage de package tire parti des liens durs, si vous utilisez des packages d’éléments multimédias, votre application ne sera pas en mesure d’ê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.