Nomes dos recursos em MRM

Artigo
09/23/2024

Cada recurso em MRM tem um nome. Os nomes de recursos são URIs em conformidade com o IETF RFC 3986.

Um nome de recurso no MRM tem o seguinte formato:

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

Em que:

ms-resource é o esquema.
<PackageFamilyName> é a autoridade e é o nome da família de pacotes do aplicativo que usará os recursos ou a cadeia de caracteres literal "Application" para aplicativos não empacotados.
<Root> é um único segmento de caminho.
<Rest...> é um ou mais outros segmentos de caminho separados por barras.

As partes de consulta e fragmento de um URI não são permitidas.

Para resumir, esta documentação normalmente se refere a nomes de recursos sem o esquema ou autoridade (por exemplo, "strings/foo" ou apenas "foo").

Diferenciar maiúsculas de minúsculas

Embora o esquema ms-resource diferencie maiúsculas de minúsculas, os caminhos não.

Todos os itens a seguir são iguais:

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

Mas os seguintes ambos são erros:

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

Se diferentes candidatos a recursos usarem maiúsculas e minúsculas diferentes, a que aparece no arquivo PRI depende da implementação. Isso não importa, pois a pesquisa de recursos de tempo de execução também não diferencia maiúsculas de minúsculas.

Autoridade

Por conveniência, o MRM permite que os URIs de recursos omitam o <PackageFamilyName> ao adicionar recurso a um indexador. Além disso, o MRM permite especificar qualquer válida autoridade como <PackageFamilyName> mas será substituído pelo valor especificado como packageFamilyName ao criar o indexador de recursos (consulte MrmCreateResourceIndexer para mais informação).

Por exemplo, supondo que o indexador de recursos tenha sido criado com o packageFamilyName de "MyApp", todos os URIs de recurso a seguir são equivalentes:

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

Caminho

Conforme indicado pela gramática simplificada acima, todos os nomes de recursos no MRM devem ter pelo menos dois segmentos de caminho <Root> e <Rest...>. É um erro ter um único segmento de caminho no nome do recurso ou terminar o nome do recurso com uma barra. Veja os seguintes erros:

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

Não há limite prático para o número de segmentos de caminho que você pode ter, além dos limites do comprimento total de um URI (normalmente em torno de 2.000 caracteres). Todos os seguintes itens são nomes de recursos válidos:

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

Convenções

Embora não seja necessário, as convenções a seguir são usadas em arquivos PRI.

Os recursos de cadeia de caracteres são adicionados às "cadeias de caracteres" <RootPath>.
Os recursos de arquivo são adicionados aos "arquivos" <RootPath>.
Recursos de contêiner (por exemplo, recursos de um arquivo resw) são adicionados aos "recursos" <RootPath>.

Observe que a localização XAML depende da convenção "recursos" (consulte a diretiva x:Uid para obter mais informações) e outras bibliotecas também podem depender dessas convenções.

Nomear recursos para bibliotecas

Ao criar arquivos PRI para fazer parte de uma biblioteca redistribuível, é importante escolher nomes de recursos que provavelmente não entrarão em conflito com os nomes do aplicativo pai (ou de outras bibliotecas). Isso ocorre porque todos os recursos de um aplicativo (incluindo recursos para bibliotecas dependentes) são mesclados em um único arquivo PRI no momento da compilação, consulte MrmIndexResourceContainerAutoQualifiers para obter mais informações. Se o mesmo nome de recurso for usado pelo aplicativo principal e por uma de suas bibliotecas (ou por duas bibliotecas), ocorrerá um erro ao gerar o PRI.

Para evitar isso, considere espaçar seus recursos em um caminho que inclua um segmento exclusivo, como o nome DNS reverso da sua empresa ou um GUID.

Compartilhar via