Noms de ressources dans MRM

Article
10/16/2024

Chaque ressource dans MRM a un nom. Les noms de ressources sont des URI conformes à IETF RFC 3986.

Un nom de ressource dans MRM a la forme suivante :

ms-resource://<PackageFamilyName>/<Root>/<Rest...>

Où :

ms-resource est le schéma (scheme).
<PackageFamilyName> est l’autorité (authority) et correspond soit au nom de la famille du package de l’application qui utilisera les ressources, soit à la chaîne littérale "Application" pour les applications non empaquetées.
<Root> est un seul segment de chemin.
<Rest...> est un ou plusieurs autres segments de chemin séparés par des barres obliques.

Les parties requête (query) et fragment d’un URI ne sont pas autorisées.

Pour des raisons de concision, cette documentation fait généralement référence aux noms de ressources sans le scheme ou l’authority (par exemple « strings/foo » ou simplement « foo »).

Respect de la casse

Bien que le schéma ms-resource soit sensible à la casse, les chemins ne le sont pas.

Tous les exemples suivants sont équivalents :

ms-resource:///FILES/LOGO.PNG
ms-resource:///files/logo.png
ms-resource:///FiLeS/LoGo.PnG

Mais les exemples suivants sont tous deux des erreurs :

MS-RESOURCE:///files/logo.png
Ms-Resource:///files.logo.png

Si différents candidats de ressources utilisent des casses différentes, celui qui apparaît dans le fichier PRI dépend de l’implémentation. Cela n’a pas d’importance, car la recherche de ressources à l’exécution est également insensible à la casse.

Autorité

Pour plus de commodité, MRM permet aux URI de ressources d’omettre le <PackageFamilyName> lors de l’ajout de ressources à un indexeur. De plus, MRM permet de spécifier n’importe quelle autorité valide comme <PackageFamilyName> mais il sera remplacé par la valeur spécifiée comme packageFamilyName lors de la création de l’indexeur de ressources (veuillez consulter la section MrmCreateResourceIndexer pour plus d’informations).

Par exemple, en supposant que l’indexeur de ressources ait été créé avec le packageFamilyName de "MyApp", alors toutes les URI de ressources suivantes sont équivalentes :

ms-resource://MyApp/strings/foo     // Canonical form.
ms-resource:///strings/foo          // Omit the PFN.
ms-resource://App2/strings/foo      // PFN "App2" is ignored.

Chemin d’accès

Comme indiqué par la grammaire simplifiée ci-dessus, tous les noms de ressources dans MRM doivent avoir au moins deux segments de chemin, <Root> et <Rest...>. Il est incorrect d’avoir un seul segment de chemin dans le nom de la ressource ou de terminer le nom de la ressource par une barre oblique. Les exemples suivants sont des erreurs :

ms-resource///hello                 // Error, only one path segment
ms-resource///strings/hello/        // Error, ends with a slash

Il n’y a pas de limite pratique au nombre de segments de chemin que vous pouvez avoir, en dehors des limites sur la longueur totale d’un URI (généralement environ 2 000 caractères). Tous les exemples suivants sont des noms de ressources valides :

ms-resource:///strings/hello
ms-resource:///files/assets/logo.png
ms-resource:///food/baked/muffins/lemon.and.blueberry/gluten_free

Conventions

Bien que cela ne soit en aucun cas obligatoire, les conventions suivantes sont utilisées dans les fichiers PRI.

Les ressources de chaîne sont ajoutées aux « strings » <RootPath>.
Les ressources de fichier sont ajoutées aux « fichiers » <RootPath>.
Les ressources conteneurs (par exemple des ressources provenant d’un fichier resw) sont ajoutées aux « ressources » <RootPath>.

Notez que la localisation XAML dépend de la convention « ressources » (veuillez consulter la section directive x:Uid pour plus d’informations), et d’autres bibliothèques peuvent également dépendre de ces conventions.

Noms de ressources pour les bibliothèques

Lors de la création de fichiers PRI faisant partie d’une bibliothèque redistribuable, il est important de choisir des noms de ressources qui ne sont pas susceptibles de créer des conflits avec les noms de l’application parente (ou d’autres bibliothèques). Cela est dû au fait que toutes les ressources d’une application (y compris les ressources des bibliothèques dépendantes) sont fusionnées dans un seul fichier PRI au moment de la compilation - veuillez consulter la section MrmIndexResourceContainerAutoQualifiers pour plus d’informations. Si le même nom de ressource est utilisé par l’application principale et l’une de ses bibliothèques (ou par deux bibliothèques), une erreur se produira lors de la génération du fichier PRI.

Pour éviter cela, envisagez de nommer vos ressources en les plaçant dans un chemin qui inclut un segment unique, comme le nom DNS inversé de votre entreprise ou un GUID.

Partager via