Resursnamn i MRM
Varje resurs i MRM har ett namn. Resursnamn är URI:er som överensstämmer med IETF RFC 3986.
Ett resursnamn i MRM är av följande form:
ms-resource://<PackageFamilyName>/<Root>/<Rest...>
Var:
-
ms-resource
är -schemat. -
<PackageFamilyName>
är utfärdare och är antingen paketfamiljenamnet för den app som ska använda resurserna eller den literalsträng"Application"
för uppackade appar. -
<Root>
är ett enda sökvägssegment. -
<Rest...>
är ett eller flera andra sökvägssegment avgränsade med snedstreck.
Den frågan och fragment delar av en URI tillåts inte.
I korthet refererar den här dokumentationen vanligtvis till resursnamn utan schema eller utfärdare (till exempel "strängar/foo" eller bara "foo").
Skiftlägeskänslighet
Även om schemat ms-resource
är skiftlägeskänsligt är sökvägarna inte det.
Alla följande är lika med:
ms-resource:///FILES/LOGO.PNG
ms-resource:///files/logo.png
ms-resource:///FiLeS/LoGo.PnG
Men följande är båda felen:
MS-RESOURCE:///files/logo.png
Ms-Resource:///files.logo.png
Om olika resurskandidater använder olika höljen är den som visas i PRI-filen implementeringsberoende. Det spelar ingen roll eftersom körningsresurssökning också är skiftlägeskänslig.
Auktoritet
För enkelhetens skull tillåter MRM resurs-URI:er att utelämna <PackageFamilyName>
när du lägger till resurs i en indexerare. Dessutom kan MRM ange alla giltiga utfärdare som <PackageFamilyName>
men ersätts med värdet som anges som packageFamilyName när du skapar resursindexeraren (se MrmCreateResourceIndexer för mer information).
Anta till exempel att resursindexeraren skapades med packageFamilyName av "MyApp"
så är alla följande resurs-URI:er likvärdiga:
ms-resource://MyApp/strings/foo // Canonical form.
ms-resource:///strings/foo // Omit the PFN.
ms-resource://App2/strings/foo // PFN "App2" is ignored.
Stig
Enligt den förenklade grammatiken ovan måste alla resursnamn i MRM ha minst två sökvägssegment, <Root>
och <Rest...>
. Det är ett fel att ha ett enskilt sökvägssegment i resursnamnet eller att avsluta resursnamnet med ett snedstreck. Följande är fel:
ms-resource///hello // Error, only one path segment
ms-resource///strings/hello/ // Error, ends with a slash
Det finns ingen praktisk gräns för hur många sökvägssegment du kan ha, förutom begränsningar för den totala längden på en URI (vanligtvis cirka 2 000 tecken). Alla följande är giltiga resursnamn:
ms-resource:///strings/hello
ms-resource:///files/assets/logo.png
ms-resource:///food/baked/muffins/lemon.and.blueberry/gluten_free
Konventioner
Även om det inte krävs på något sätt används följande konventioner i PRI-filer.
- Strängresurser läggs till i "strängarna"
<RootPath>
. - Filresurser läggs till i "filer"
<RootPath>
. - Containerresurser (t.ex. resurser från en
resw
fil) läggs till i "resurser"<RootPath>
.
Observera att XAML-lokalisering är beroende av "resurskonventionen" (se x:Uid-direktiv för mer information), och andra bibliotek kan också vara beroende av dessa konventioner.
Namnge resurser för bibliotek
När du skapar PRI-filer som en del av ett omdistribuerbart bibliotek är det viktigt att välja resursnamn som sannolikt inte kommer att stå i konflikt med namnen på den överordnade appen (eller andra bibliotek). Det beror på att alla resurser för en app (inklusive resurser för beroende bibliotek) sammanfogas till en enskild PRI-fil vid byggtiden – se MrmIndexResourceContainerAutoQualifiers för mer information. Om samma resursnamn används av huvudappen och ett av dess bibliotek (eller av två bibliotek) uppstår ett fel när PRI genereras.
Undvik detta genom att överväga namnavstånd för dina resurser till en sökväg som innehåller ett unikt segment, till exempel företagets omvända DNS-namn eller ett GUID.