Usare il Sistema gestione risorse di Windows 10 in un'app legacy o in un gioco

Le app e i giochi .NET e Win32 vengono spesso localizzati in lingue diverse per espandere il loro mercato indirizzabile totale. Per altre informazioni sulla proposta di valore associata alla localizzazione dell'app, vedi Globalizzazione e localizzazione. Creando il pacchetto del gioco o dell'app .NET o Win32 come pacchetto .msix o .appx, puoi usare il sistema di gestione delle risorse per caricare le risorse dell'app personalizzate per il contesto di runtime. Questo argomento descrive dettagliatamente le tecniche.

Esistono molti modi per localizzare un'applicazione Win32 tradizionale, ma Windows 8 ha introdotto un nuovo sistema di gestione delle risorse che funziona tra i linguaggi di programmazione, tra i tipi di applicazioni e offre funzionalità oltre e sopra la semplice localizzazione. Questo sistema verrà definito "MRT" in questo argomento. Storicamente, che si trovava per "Modern Resource Technology" ma il termine "Modern" è stato sospeso. Resource Manager potrebbe anche essere noto come MRM (Modern Resource Manager) o PRI (Package Resource Index).

In combinazione con la distribuzione basata su MSIX o basata su .appx (ad esempio, da Microsoft Store), MRT può distribuire automaticamente le risorse più applicabili per un determinato utente/dispositivo che riduce al minimo le dimensioni di download e installazione dell'applicazione. Questa riduzione delle dimensioni può essere significativa per le applicazioni con una grande quantità di contenuto localizzato, ad esempio nell'ordine di diversi gigabyte per i giochi AAA. Altri vantaggi di MRT includono presentazioni localizzate in Windows Shell e Microsoft Store, logica di fallback automatico quando la lingua preferita di un utente non corrisponde alle risorse disponibili.

Questo documento descrive l'architettura generale di MRT e fornisce una guida alla conversione per spostare le applicazioni Win32 legacy in MRT con modifiche minime al codice. Una volta effettuato il passaggio a MRT, diventano disponibili per lo sviluppatore ulteriori vantaggi, ad esempio la possibilità di segmentare le risorse in base al fattore di scala o al tema del sistema. Si noti che la localizzazione basata su MRT funziona sia per le applicazioni UWP che per le applicazioni Win32 elaborate da Desktop Bridge (noto anche come "Centennial").

In molte situazioni, è possibile continuare a usare i formati di localizzazione esistenti e il codice sorgente durante l'integrazione con MRT per risolvere le risorse in fase di esecuzione e ridurre al minimo le dimensioni di download, non è un approccio all-or-nothing. La tabella seguente riepiloga il lavoro e il costo/vantaggio stimato di ogni fase. Questa tabella non include attività di non localizzazione, ad esempio la fornitura di icone dell'applicazione ad alta risoluzione o a contrasto elevato. Per altre info sulla fornitura di più asset per riquadri, icone e così via, vedi Adattare le risorse per lingua, scalabilità, contrasto elevato e altri qualificatori.

Lavoro	Vantaggio	Costo stimato
Localizzare il manifesto del pacchetto	Lavoro minimo necessario per visualizzare il contenuto localizzato nella shell di Windows e in Microsoft Store	Piccola
Usare MRT per identificare e individuare le risorse	Prerequisito per ridurre al minimo le dimensioni di download e installazione; fallback automatico del linguaggio	Medio
Creare pacchetti di risorse	Passaggio finale per ridurre al minimo le dimensioni di download e installazione	Piccola
Eseguire la migrazione a API e formati di risorse MRT	Dimensioni di file notevolmente inferiori (a seconda della tecnologia di risorse esistente)	Grande

Introduzione

La maggior parte delle applicazioni non semplici contiene elementi dell'interfaccia utente noti come risorse disaccoppiate dal codice dell'applicazione (a differenza dei valori hardcoded creati nel codice sorgente stesso). Esistono diversi motivi per preferire le risorse rispetto ai valori hardcoded, ad esempio la facilità di modifica da parte di non sviluppatori, ma uno dei motivi principali è consentire all'applicazione di selezionare rappresentazioni diverse della stessa risorsa logica in fase di esecuzione. Ad esempio, il testo da visualizzare su un pulsante (o l'immagine da visualizzare in un'icona) può variare a seconda delle lingue che l'utente capisce, delle caratteristiche del dispositivo di visualizzazione o se l'utente dispone di tecnologie di assistive technology abilitate.

Pertanto, lo scopo principale di qualsiasi tecnologia di gestione delle risorse consiste nel tradurre, in fase di esecuzione, una richiesta di un nome di risorsa logica o simbolica (ad esempio SAVE_BUTTON_LABEL) nel valore effettivo migliore possibile (ad esempio, "Salva") da un set di possibili candidati (ad esempio, "Salva", "Speichern" o "저장"). MRT fornisce una funzione di questo tipo e consente alle applicazioni di identificare i candidati alle risorse usando un'ampia gamma di attributi, denominati qualificatori, ad esempio la lingua dell'utente, il fattore di scala di visualizzazione, il tema selezionato dell'utente e altri fattori ambientali. MRT supporta anche qualificatori personalizzati per le applicazioni che ne hanno bisogno( ad esempio, un'applicazione potrebbe fornire asset grafici diversi per gli utenti che hanno eseguito l'accesso con un account o utenti guest, senza aggiungere esplicitamente questo controllo in ogni parte dell'applicazione). MRT funziona sia con le risorse stringa che con le risorse basate su file, in cui le risorse basate su file vengono implementate come riferimenti ai dati esterni (i file stessi).

Esempio

Ecco un semplice esempio di applicazione con etichette di testo su due pulsanti (openButton e saveButton) e un file PNG usato per un logo (logoImage). Le etichette di testo sono localizzate in inglese e tedesco e il logo è ottimizzato per i normali schermi desktop (fattore di scala del 100%) e telefoni ad alta risoluzione (fattore di scala del 300%). Si noti che questo diagramma presenta una visualizzazione concettuale di alto livello del modello; non esegue il mapping esattamente all'implementazione.

Nell'immagine il codice dell'applicazione fa riferimento ai tre nomi di risorse logiche. In fase di esecuzione, la GetResource pseudo-funzione usa MRT per esaminare i nomi delle risorse nella tabella delle risorse (noto come file PRI) e trovare il candidato più appropriato in base alle condizioni di ambiente (la lingua dell'utente e il fattore di scala della visualizzazione). Nel caso delle etichette, le stringhe vengono usate direttamente. Nel caso dell'immagine del logo, le stringhe vengono interpretate come nomi file e i file vengono letti fuori disco.

Se l'utente parla una lingua diversa dall'inglese o dal tedesco o ha un fattore di scala visualizzato diverso dal 100% o dal 300%, MRT seleziona il candidato corrispondente "più vicino" in base a un set di regole di fallback (vedere Sistema di gestione risorse per altre informazioni in background).

Si noti che MRT supporta risorse personalizzate per più qualificatori, ad esempio se l'immagine del logo conteneva testo incorporato che doveva essere localizzato, il logo avrebbe quattro candidati: EN/Scale-100, DE/Scale-100, EN/Scale-300 e DE/Scale-300.

Sezioni di questo documento

Le sezioni seguenti illustrano le attività generali necessarie per integrare MRT con l'applicazione.

Fase 0: Compilare un pacchetto dell'applicazione

Questa sezione illustra come ottenere la compilazione dell'applicazione desktop esistente come pacchetto dell'applicazione. In questa fase non vengono usate funzionalità MRT.

Fase 1: Localizzare il manifesto dell'applicazione

Questa sezione descrive come localizzare il manifesto dell'applicazione (in modo che venga visualizzato correttamente nella shell di Windows) mentre usa ancora il formato di risorsa legacy e l'API per creare il pacchetto e individuare le risorse.

Fase 2: Usare MRT per identificare e individuare le risorse

Questa sezione illustra come modificare il codice dell'applicazione (ed eventualmente il layout delle risorse) per individuare le risorse usando MRT, pur usando i formati di risorse e le API esistenti per caricare e utilizzare le risorse.

Fase 3: Creare pacchetti di risorse

Questa sezione descrive le modifiche finali necessarie per separare le risorse in pacchetti di risorse separati, riducendo al minimo le dimensioni di download (e installazione) dell'app.

Non trattato in questo documento

Dopo aver completato le fasi 0-3 precedenti, avrai un'applicazione "bundle" che può essere inviata a Microsoft Store e che ridurrà al minimo le dimensioni di download e installazione per gli utenti omettendo le risorse che non hanno bisogno (ad esempio, le lingue che non parlano). È possibile apportare ulteriori miglioramenti alle dimensioni e alle funzionalità dell'applicazione eseguendo un passaggio finale.

Fase 4: Eseguire la migrazione a API e formati di risorse MRT

Questa fase esula dall'ambito di questo documento; comporta lo spostamento delle risorse (in particolare di stringhe) da formati legacy, ad esempio DLL MUI o assembly di risorse .NET in file PRI. Questo può portare a ulteriori risparmi di spazio per il download & le dimensioni di installazione. Consente anche l'uso di altre funzionalità MRT, ad esempio ridurre al minimo il download e l'installazione dei file di immagine in base al fattore di scala, alle impostazioni di accessibilità e così via.

Fase 0: Compilare un pacchetto dell'applicazione

Prima di apportare modifiche alle risorse dell'applicazione, devi prima sostituire la tecnologia di creazione di pacchetti e installazione correnti con la tecnologia standard per la creazione di pacchetti e la distribuzione UWP. Ciò è possibile in tre modi:

• Se hai un'applicazione desktop di grandi dimensioni con un programma di installazione complesso o usi molti punti di estendibilità del sistema operativo, puoi usare lo strumento Desktop App Converter per generare il layout del file UWP e le informazioni sul manifesto dal programma di installazione dell'app esistente(ad esempio, un'identità del servizio gestito).
• Se si dispone di un'applicazione desktop più piccola con relativamente pochi file o un semplice programma di installazione e nessun hook di estendibilità, è possibile creare manualmente il layout del file e le informazioni sul manifesto.
• Se si esegue la ricompilazione dall'origine e si vuole aggiornare l'app come applicazione UWP pura, è possibile creare un nuovo progetto in Visual Studio e basarsi sull'IDE per eseguire molte operazioni.

Per usare Desktop App Converter, vedere Creare un pacchetto di un'applicazione desktop con Desktop App Converter per altre informazioni sul processo di conversione. Un set completo di esempi di Desktop Converter è disponibile nel repository GitHub di esempi da Desktop Bridge a UWP.

Se si vuole creare manualmente il pacchetto, sarà necessario creare una struttura di directory che includa tutti i file dell'applicazione (eseguibili e contenuto, ma non il codice sorgente) e un file manifesto del pacchetto (con estensione appxmanifest). Un esempio è disponibile nell'esempio Hello, World GitHub, ma un file manifesto del pacchetto di base che esegue l'eseguibile desktop denominato ContosoDemo.exe è il seguente, dove il testo evidenziato verrebbe sostituito dai propri valori.

<?xml version="1.0" encoding="utf-8" ?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
         xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
         xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
         xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
         IgnorableNamespaces="uap mp rescap">
    <Identity Name="Contoso.Demo"
              Publisher="CN=Contoso.Demo"
              Version="1.0.0.0" />
    <Properties>
    <DisplayName>Contoso App</DisplayName>
    <PublisherDisplayName>Contoso, Inc</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
  </Properties>
    <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" 
                        MaxVersionTested="10.0.14393.0" />
  </Dependencies>
    <Resources>
    <Resource Language="en-US" />
  </Resources>
    <Applications>
    <Application Id="ContosoDemo" Executable="ContosoDemo.exe" 
                 EntryPoint="Windows.FullTrustApplication">
    <uap:VisualElements DisplayName="Contoso Demo" BackgroundColor="#777777" 
                        Square150x150Logo="Assets\Square150x150Logo.png" 
                        Square44x44Logo="Assets\Square44x44Logo.png" 
        Description="Contoso Demo">
      </uap:VisualElements>
    </Application>
  </Applications>
    <Capabilities>
    <rescap:Capability Name="runFullTrust" />
  </Capabilities>
</Package>

Per altre informazioni sul file manifesto del pacchetto e sul layout del pacchetto, vedere Manifesto del pacchetto dell'app.

Infine, se si usa Visual Studio per creare un nuovo progetto ed eseguire la migrazione del codice esistente, vedere Creare un'app "Hello, world". Puoi includere il codice esistente nel nuovo progetto, ma probabilmente dovrai apportare modifiche significative al codice (in particolare nell'interfaccia utente) per essere eseguito come app UWP pura. Queste modifiche non rientrano nell'ambito di questo documento.

Fase 1: Localizzare il manifesto

Passaggio 1.1: Aggiornare stringhe & asset nel manifesto

Nella fase 0 è stato creato un file manifesto del pacchetto di base (con estensione appxmanifest) per l'applicazione (in base ai valori forniti al convertitore, estratto dall'identità del servizio gestito o immesso manualmente nel manifesto), ma non conterrà informazioni localizzate, né supporterà funzionalità aggiuntive come asset del riquadro Start ad alta risoluzione e così via.

Per assicurarsi che il nome e la descrizione dell'applicazione siano localizzati correttamente, è necessario definire alcune risorse in un set di file di risorse e aggiornare il manifesto del pacchetto per farvi riferimento.

Creazione di un file di risorse predefinito

Il primo passaggio consiste nel creare un file di risorse predefinito nella lingua predefinita (ad esempio, inglese statunitense). È possibile eseguire questa operazione manualmente con un editor di testo o tramite Progettazione risorse in Visual Studio.

Per creare manualmente le risorse:

1. Creare un file XML denominato resources.resw e inserirlo in una Strings\en-us sottocartella del progetto. Usare il codice BCP-47 appropriato se la lingua predefinita non è inglese statunitense.
2. Nel file XML aggiungere il contenuto seguente, in cui il testo evidenziato viene sostituito con il testo appropriato per l'app, nella lingua predefinita.

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="ApplicationDescription">
    <value>Contoso Demo app with localized resources (English)</value>
  </data>
  <data name="ApplicationDisplayName">
    <value>Contoso Demo Sample (English)</value>
  </data>
  <data name="PackageDisplayName">
    <value>Contoso Demo Package (English)</value>
  </data>
  <data name="PublisherDisplayName">
    <value>Contoso Samples, USA</value>
  </data>
  <data name="TileShortName">
    <value>Contoso (EN)</value>
  </data>
</root>

Se si vuole usare la finestra di progettazione in Visual Studio:

1. Creare la Strings\en-us cartella (o un'altra lingua in base alle esigenze) nel progetto e aggiungere un nuovo elemento alla cartella radice del progetto, usando il nome predefinito di resources.resw. Assicurarsi di scegliere File di risorse (con estensione resw) e non dizionario risorse. Un dizionario risorse è un file usato dalle applicazioni XAML.
2. Usando la finestra di progettazione immettere le stringhe seguenti (usare lo stesso Names ma sostituire con Values il testo appropriato per l'applicazione):

Aggiornare il manifesto per fare riferimento alle risorse

Dopo aver definito i valori nel file, il passaggio successivo consiste nell'aggiornare .resw il manifesto per fare riferimento alle stringhe di risorse. Anche in questo caso, è possibile modificare direttamente un file XML o fare affidamento su Progettazione manifesto di Visual Studio.

Se si modifica direttamente xml, aprire il AppxManifest.xml file e apportare le modifiche seguenti ai valori evidenziati: usare questo testo esatto , non il testo specifico dell'applicazione. Non è necessario usare questi nomi di risorse esatti, ma qualsiasi elemento scelto corrisponda esattamente a quello presente nel .resw file. Questi nomi devono corrispondere all'oggetto Names creato nel .resw file, preceduto dallo ms-resource: schema e dallo Resources/ spazio dei nomi .

<?xml version="1.0" encoding="utf-8"?>
<Package>
  <Properties>
    <DisplayName>ms-resource:Resources/PackageDisplayName</DisplayName>
    <PublisherDisplayName>ms-resource:Resources/PublisherDisplayName</PublisherDisplayName>
  </Properties>
  <Applications>
    <Application>
      <uap:VisualElements DisplayName="ms-resource:Resources/ApplicationDisplayName"
        Description="ms-resource:Resources/ApplicationDescription">
        <uap:DefaultTile ShortName="ms-resource:Resources/TileShortName">
          <uap:ShowNameOnTiles>
            <uap:ShowOn Tile="square150x150Logo" />
          </uap:ShowNameOnTiles>
        </uap:DefaultTile>
      </uap:VisualElements>
    </Application>
  </Applications>
</Package>

Se si usa la finestra di progettazione del manifesto di Visual Studio, aprire il file con estensione appxmanifest e modificare i valori evidenziati nella scheda *Applicazione e nella scheda Creazione pacchetti :

Passaggio 1.2: Compilare il file PRI, creare un pacchetto MSIX e verificare che funzioni

A questo punto dovrebbe essere possibile compilare il .pri file e distribuire l'applicazione per verificare che le informazioni corrette (nella lingua predefinita) siano visualizzate nel menu Start.

Se si compila in Visual Studio, è sufficiente premere Ctrl+Shift+B per compilare il progetto e quindi fare clic con il pulsante destro del mouse sul progetto e scegliere Deploy dal menu di scelta rapida.

Se si compila manualmente, seguire questa procedura per creare un file di configurazione per MakePRI lo strumento e generare il .pri file stesso (altre informazioni sono disponibili in Creazione manuale dei pacchetti di app):

1. Aprire un prompt dei comandi per sviluppatori dalla cartella Visual Studio 2017 o Visual Studio 2019 nel menu Start.

2. Passare alla directory radice del progetto (quella che contiene il file con estensione appxmanifest e la cartella Strings ).

3. Digitare il comando seguente, sostituendo "contoso_demo.xml" con un nome appropriato per il progetto e "en-US" con la lingua predefinita dell'app (o mantenerla en-US, se applicabile). Si noti che il file XML viene creato nella directory padre (non nella directory del progetto) perché non fa parte dell'applicazione (è possibile scegliere qualsiasi altra directory desiderata, ma assicurarsi di sostituirlo nei comandi futuri).

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
   

   È possibile digitare makepri createconfig /? per visualizzare le operazioni di ogni parametro, ma in riepilogo:

   • /cf imposta il nome file di configurazione (output di questo comando)
   • /dq imposta i qualificatori predefiniti, in questo caso la lingua en-US
   • /pv imposta la versione della piattaforma, in questo caso Windows 10
   • /o imposta la proprietà su Sovrascrivere il file di output, se esistente

4. Ora si dispone di un file di configurazione, eseguire MakePRI di nuovo per cercare effettivamente nel disco le risorse e crearne il pacchetto in un file PRI. Sostituire "contoso_demop.xml" con il nome file XML usato nel passaggio precedente e assicurarsi di specificare la directory padre per input e output:

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   

   È possibile digitare makepri new /? per visualizzare le operazioni di ogni parametro, ma in breve:

   • /pr imposta la radice del progetto (in questo caso, la directory corrente)
   • /cf imposta il nome file di configurazione creato nel passaggio precedente
   • /of imposta il file di output
   • /mf crea un file di mapping (in modo da poter escludere i file nel pacchetto in un passaggio successivo)
   • /o imposta la proprietà su Sovrascrivere il file di output, se esistente

5. Ora si dispone di un .pri file con le risorse della lingua predefinite (ad esempio en-US). Per verificare che funzioni correttamente, è possibile eseguire il comando seguente:

   makepri dump /if ..\resources.pri /of ..\resources /o
   

   È possibile digitare makepri dump /? per visualizzare le operazioni di ogni parametro, ma in breve:

   • /if imposta il nome file di input
   • /of imposta il nome file di output (.xml verrà aggiunto automaticamente)
   • /o imposta la proprietà su Sovrascrivere il file di output, se esistente

6. Infine, è possibile aprire ..\resources.xml in un editor di testo e verificare che elenchi i <NamedResource> valori (ad esempio ApplicationDescription e PublisherDisplayName) insieme <Candidate> ai valori per la lingua predefinita scelta (all'inizio del file sarà presente altro contenuto; ignorarlo per il momento).

È possibile aprire il file ..\resources.map.txt di mapping per verificare che contenga i file necessari per il progetto (incluso il file PRI, che non fa parte della directory del progetto). Importante, il file di mapping non includerà un riferimento al file resources.resw perché il contenuto del file è già stato incorporato nel file PRI. Conterrà tuttavia altre risorse come i nomi file delle immagini.

Compilazione e firma del pacchetto

Ora il file PRI è compilato, è possibile compilare e firmare il pacchetto:

1. Per creare il pacchetto dell'app, eseguire il comando seguente sostituendo contoso_demo.appx con il nome del file con estensione msix/.appx che si vuole creare e assicurandosi di scegliere una directory diversa per il file (questo esempio usa la directory padre, ma può essere ovunque ma non deve essere la directory del progetto).

   makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /o
   

   È possibile digitare makeappx pack /? per visualizzare le operazioni di ogni parametro, ma in breve:

   • /m imposta il file manifesto da usare
   • /f imposta il file di mapping da usare (creato nel passaggio precedente)
   • /p imposta il nome del pacchetto di output
   • /o imposta la proprietà su Sovrascrivere il file di output, se esistente

2. Dopo aver creato il pacchetto, deve essere firmato. Il modo più semplice per ottenere un certificato di firma consiste nel creare un progetto di Windows universale vuoto in Visual Studio e copiare il .pfx file creato, ma è possibile crearne uno manualmente usando le MakeCert utilità e Pvk2Pfx come descritto in Come creare un certificato di firma del pacchetto dell'app.

   Importante

   Se si crea manualmente un certificato di firma, assicurarsi di inserire i file in una directory diversa rispetto al progetto di origine o all'origine del pacchetto. In caso contrario, potrebbe essere incluso come parte del pacchetto, inclusa la chiave privata.

3. Per firmare il pacchetto, utilizzare il comando seguente. Si noti che l'oggetto Publisher specificato nell'elemento Identity di AppxManifest.xml deve corrispondere a Subject del certificato (non è l'elemento <PublisherDisplayName>, ovvero il nome visualizzato localizzato da visualizzare agli utenti). Come di consueto, sostituire i contoso_demo... nomi file con i nomi appropriati per il progetto e (molto importante) assicurarsi che il .pfx file non si trova nella directory corrente (altrimenti sarebbe stato creato come parte del pacchetto, inclusa la chiave di firma privata!):

   signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appx
   

   È possibile digitare signtool sign /? per visualizzare le operazioni di ogni parametro, ma in breve:

   • /fd imposta l'algoritmo File Digest (SHA256 è l'impostazione predefinita per .appx)
   • /a seleziona automaticamente il miglior certificato di firma.
   • /f specifica il file di input che contiene il certificato di firma

Infine, è ora possibile fare doppio clic sul .appx file per installarlo oppure, se si preferisce la riga di comando, è possibile aprire un prompt di PowerShell, passare alla directory contenente il pacchetto e digitare quanto segue (sostituendo contoso_demo.appx con il nome del pacchetto):

add-appxpackage contoso_demo.appx

Se si ricevono errori relativi al certificato non considerato attendibile, assicurarsi che venga aggiunto all'archivio computer (non all'archivio utenti). Per aggiungere il certificato all'archivio computer, è possibile usare la riga di comando o Esplora risorse.

Per utilizzare la riga di comando:

1. Eseguire un prompt dei comandi di Visual Studio 2017 o Visual Studio 2019 come amministratore.

2. Passare alla directory che contiene il .cer file (ricordarsi di assicurarsi che non si trova all'esterno delle directory di origine o di progetto!)

3. Digitare il comando seguente, sostituendo contoso_demo.cer con il nome del file:

   certutil -addstore TrustedPeople contoso_demo.cer
   

   È possibile avviare certutil -addstore /? per visualizzare le operazioni di ogni parametro, ma in breve:

   • -addstore aggiunge un nuovo certificato all'archivio certificati
   • TrustedPeople indica l'archivio in cui viene inserito il certificato

Usare Windows Explorer:

1. Passare alla cartella in cui è incluso il file .pfx.
2. Fare doppio clic sul .pfx file e verrà visualizzata l'Importazione guidata Certicicate
3. Scegli Local Machine e fai clic su Next
4. Accettare la richiesta di elevazione dell'elevazione dei privilegi di amministratore controllo account utente, se visualizzata e fare clic su Next
5. Immettere la password per la chiave privata, se presente, e fare clic su Next
6. Selezionare Place all certificates in the following store
7. Fare clic su Browsee scegliere la Trusted People cartella (non "Autori attendibili")
8. Cliccare su Next, quindi su Finish

Dopo aver aggiunto il certificato all'archivio Trusted People , provare a installare di nuovo il pacchetto.

Dovrebbe essere visualizzata l'app nell'elenco "Tutte le app" del menu Start, con le informazioni corrette del .resw / .pri file. Se viene visualizzata una stringa vuota o la stringa ms-resource:... , si è verificato un problema. Controllare le modifiche e assicurarsi che siano corrette. Se si fa clic con il pulsante destro del mouse sull'app nel menu Start, è possibile aggiungerla come riquadro e verificare che siano visualizzate anche le informazioni corrette.

Passaggio 1.3: Aggiungere altre lingue supportate

Dopo aver apportato le modifiche al manifesto del pacchetto e aver creato il file iniziale resources.resw , l'aggiunta di altre lingue è semplice.

Creare risorse localizzate aggiuntive

Creare prima di tutto i valori di risorsa localizzati aggiuntivi.

All'interno della Strings cartella creare cartelle aggiuntive per ogni lingua supportata usando il codice BCP-47 appropriato ,ad esempio Strings\de-DE. All'interno di ognuna di queste cartelle creare un resources.resw file (usando un editor XML o la finestra di progettazione di Visual Studio) che include i valori delle risorse tradotte. Si presuppone che le stringhe localizzate siano già disponibili da qualche parte e che sia sufficiente copiarle nel .resw file. Questo documento non tratta il passaggio di traduzione stesso.

Ad esempio, il Strings\de-DE\resources.resw file potrebbe essere simile al seguente, con il testo evidenziato modificato da en-US:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="ApplicationDescription">
    <value>Contoso Demo app with localized resources (German)</value>
  </data>
  <data name="ApplicationDisplayName">
    <value>Contoso Demo Sample (German)</value>
  </data>
  <data name="PackageDisplayName">
    <value>Contoso Demo Package (German)</value>
  </data>
  <data name="PublisherDisplayName">
    <value>Contoso Samples, DE</value>
  </data>
  <data name="TileShortName">
    <value>Contoso (DE)</value>
  </data>
</root>

I passaggi seguenti presuppongono che siano state aggiunte risorse sia per de-DE e fr-FR, ma lo stesso modello può essere seguito per qualsiasi lingua.

Aggiornare il manifesto del pacchetto per elencare le lingue supportate

Il manifesto del pacchetto deve essere aggiornato per elencare le lingue supportate dall'app. Desktop App Converter aggiunge la lingua predefinita, ma gli altri devono essere aggiunti in modo esplicito. Se si modifica direttamente il AppxManifest.xml file, aggiornare il Resources nodo come indicato di seguito, aggiungendo tutti gli elementi necessari e sostituendo le lingue appropriate supportate e assicurandosi che la prima voce nell'elenco sia la lingua predefinita (fallback). In questo esempio, il valore predefinito è Inglese (Stati Uniti) con supporto aggiuntivo sia per il tedesco (Germania) che per il francese (Francia):

<Resources>
  <Resource Language="EN-US" />
  <Resource Language="DE-DE" />
  <Resource Language="FR-FR" />
</Resources>

Se si usa Visual Studio, non è necessario eseguire alcuna operazione; se si esamina Package.appxmanifest il valore speciale di generazione x, che fa sì che il processo di compilazione inserisca i linguaggi trovati nel progetto (in base alle cartelle denominate con codici BCP-47). Si noti che questo non è un valore valido per un manifesto del pacchetto reale; funziona solo per i progetti di Visual Studio:

<Resources>
  <Resource Language="x-generate" />
</Resources>

Ripetere la compilazione con i valori localizzati

A questo punto è possibile compilare e distribuire di nuovo l'applicazione e, se si modifica la preferenza di lingua in Windows, i valori appena localizzati verranno visualizzati nella menu Start (istruzioni per modificare la lingua sono riportate di seguito).

Per Visual Studio, è possibile usare Ctrl+Shift+B di nuovo per compilare e fare clic con il pulsante destro del mouse sul progetto su Deploy.

Se si compila manualmente il progetto, seguire la stessa procedura descritta in precedenza, ma aggiungere le lingue aggiuntive, separate da caratteri di sottolineatura, all'elenco dei qualificatori predefiniti (/dq) durante la creazione del file di configurazione. Ad esempio, per supportare le risorse inglese, tedesco e francese aggiunte nel passaggio precedente:

makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_fr-FR /pv 10.0 /o

Verrà creato un file PRI che contiene tutte le lingue specificate che è possibile usare facilmente per il test. Se le dimensioni totali delle risorse sono ridotte o si supporta solo un numero ridotto di lingue, questo potrebbe essere accettabile per l'app di spedizione; è solo se si vogliono sfruttare al minimo le dimensioni di installazione/download per le risorse necessarie per la creazione di Language Pack separati.

Eseguire il test con i valori localizzati

Per testare le nuove modifiche localizzate, è sufficiente aggiungere una nuova lingua preferita dell'interfaccia utente a Windows. Non è necessario scaricare i Language Pack, riavviare il sistema o fare in modo che l'intera interfaccia utente di Windows venga visualizzata in una lingua straniera.

1. Eseguire l'Settingsapp (Windows + I)
2. Passare a Time & language
3. Passare a Region & language
4. Fare clic su Add a language
5. Digitare (o selezionare) la lingua desiderata (ad esempio Deutsch o German)

• Se sono presenti lingue secondarie, scegliere quella desiderata (ad esempio, Deutsch / Deutschland)

6. Selezionare la nuova lingua nell'elenco delle lingue
7. Fare clic su Set as default

A questo punto aprire il menu Start e cercare l'applicazione e dovrebbero essere visualizzati i valori localizzati per la lingua selezionata (potrebbero essere visualizzate anche altre app localizzate). Se il nome localizzato non viene visualizzato immediatamente, attendere alcuni minuti finché non viene aggiornata la cache del menu Start. Per tornare alla lingua nativa, è sufficiente impostarla come lingua predefinita nell'elenco delle lingue.

Passaggio 1.4: Localizzazione di più parti del manifesto del pacchetto (facoltativo)

È possibile localizzare altre sezioni del manifesto del pacchetto. Ad esempio, se l'applicazione gestisce le estensioni di file, deve avere un'estensione windows.fileTypeAssociation nel manifesto, usando il testo evidenziato in verde esattamente come illustrato (poiché farà riferimento alle risorse) e sostituendo il testo evidenziato giallo con informazioni specifiche per l'applicazione:

<Extensions>
  <uap:Extension Category="windows.fileTypeAssociation">
    <uap:FileTypeAssociation Name="default">
      <uap:DisplayName>ms-resource:Resources/FileTypeDisplayName</uap:DisplayName>
      <uap:Logo>Assets\StoreLogo.png</uap:Logo>
      <uap:InfoTip>ms-resource:Resources/FileTypeInfoTip</uap:InfoTip>
      <uap:SupportedFileTypes>
        <uap:FileType ContentType="application/x-contoso">.contoso</uap:FileType>
      </uap:SupportedFileTypes>
    </uap:FileTypeAssociation>
  </uap:Extension>
</Extensions>

È anche possibile aggiungere queste informazioni usando Progettazione manifesto di Visual Studio, usando la Declarations scheda , prendendo nota dei valori evidenziati:

Aggiungere ora i nomi delle risorse corrispondenti a ognuno dei .resw file, sostituendo il testo evidenziato con il testo appropriato per l'app (ricordarsi di eseguire questa operazione per ogni lingua supportata!):

... existing content...
<data name="FileTypeDisplayName">
  <value>Contoso Demo File</value>
</data>
<data name="FileTypeInfoTip">
  <value>Files used by Contoso Demo App</value>
</data>

Verrà quindi visualizzato in parti della shell di Windows, ad esempio Esplora file:

Compilare e testare il pacchetto come in precedenza, esercitando tutti i nuovi scenari che devono mostrare le nuove stringhe dell'interfaccia utente.

Fase 2: Usare MRT per identificare e individuare le risorse

La sezione precedente ha illustrato come usare MRT per localizzare il file manifesto dell'app in modo che La shell di Windows possa visualizzare correttamente il nome dell'app e altri metadati. Per questo motivo non sono state necessarie modifiche al codice; richiedeva semplicemente l'uso di .resw file e alcuni strumenti aggiuntivi. Questa sezione illustra come usare MRT per individuare le risorse nei formati di risorse esistenti e usare il codice di gestione delle risorse esistente con modifiche minime.

Presupposti sul layout del file esistente & sul codice dell'applicazione

Poiché esistono molti modi per localizzare le app desktop Win32, questo documento semplifica alcune ipotesi sulla struttura dell'applicazione esistente che dovrai mappare all'ambiente specifico. Potrebbe essere necessario apportare alcune modifiche alla codebase o al layout delle risorse esistente per conformarsi ai requisiti di MRT e tali modifiche non rientrano nell'ambito di questo documento.

Layout del file di risorse

Questo articolo presuppone che le risorse localizzate abbiano tutti gli stessi nomi file (ad esempio, contoso_demo.exe.mui o contoso_strings.dll ) contoso.strings.xmlma che siano posizionati in cartelle diverse con nomi BCP-47 (en-US, de-DEe così via). Non importa quanti file di risorse sono presenti, quali sono i nomi, quali sono i formati di file o le API associate e così via. L'unica cosa importante è che ogni risorsa logica abbia lo stesso nome file (ma inserito in una directory fisica diversa).

Come esempio di contatore, se l'applicazione usa una struttura di file flat con una singola Resources directory contenente i file english_strings.dll e french_strings.dll, non eseguirà il mapping corretto a MRT. Una struttura migliore sarebbe una Resources directory con sottodirectory e file en\strings.dll e fr\strings.dll. È anche possibile usare lo stesso nome di file di base, ma con qualificatori incorporati, ad esempio strings.lang-en.dll e strings.lang-fr.dll, ma l'uso di directory con i codici di linguaggio è concettualmente più semplice, quindi è ciò che ci concentreremo su.

Ad esempio, l'applicazione potrebbe avere un set di comandi dell'interfaccia utente personalizzati (usati per le etichette dei pulsanti e così via) in un semplice file di testo denominato ui.txt, disposto in una cartella UICommands :

+ ProjectRoot
|--+ Strings
|  |--+ en-US
|  |  \--- resources.resw
|  \--+ de-DE
|     \--- resources.resw
|--+ UICommands
|  |--+ en-US
|  |  \--- ui.txt
|  \--+ de-DE
|     \--- ui.txt
|--- AppxManifest.xml
|--- ...rest of project...

Codice di caricamento delle risorse

Questo articolo presuppone che a un certo punto del codice si voglia individuare il file che contiene una risorsa localizzata, caricarlo e quindi usarlo. Le API usate per caricare le risorse, le API usate per estrarre le risorse e così via non sono importanti. In pseudocodice esistono fondamentalmente tre passaggi:

set userLanguage = GetUsersPreferredLanguage()
set resourceFile = FindResourceFileForLanguage(MY_RESOURCE_NAME, userLanguage)
set resource = LoadResource(resourceFile) 
    
// now use 'resource' however you want

MRT richiede solo la modifica dei primi due passaggi di questo processo: come determinare le risorse candidate migliori e come individuarle. Non è necessario modificare il modo in cui si caricano o si usano le risorse (anche se offre funzionalità per farlo se si vuole sfruttarle).

Ad esempio, l'applicazione potrebbe usare l'API GetUserPreferredUILanguagesWin32 , la funzione sprintfCRT e l'API CreateFile Win32 per sostituire le tre funzioni pseudocodice precedenti, quindi analizzare manualmente il file di testo cercando name=value coppie. (I dettagli non sono importanti; si tratta semplicemente di illustrare che MRT non ha alcun impatto sulle tecniche usate per gestire le risorse una volta individuate).

Passaggio 2.1: Modifiche al codice per l'uso di MRT per individuare i file

Il passaggio del codice all'uso di MRT per l'individuazione delle risorse non è difficile. Richiede l'uso di alcuni tipi WinRT e alcune righe di codice. I tipi principali che verranno usati sono i seguenti:

• ResourceContext, che incapsula il set attivo di valori qualificatori (linguaggio, fattore di scala e così via)
• ResourceManager (la versione winRT, non la versione .NET), che consente l'accesso a tutte le risorse dal file PRI
• ResourceMap, che rappresenta un subset specifico delle risorse nel file PRI (in questo esempio le risorse basate su file e le risorse stringa)
• NamedResource, che rappresenta una risorsa logica e tutti i possibili candidati
• ResourceCandidate, che rappresenta una singola risorsa candidata concreta

Nello pseudo-codice, il modo in cui si risolve un determinato nome di file di risorse (come UICommands\ui.txt nell'esempio precedente) è il seguente:

// Get the ResourceContext that applies to this app
set resourceContext = ResourceContext.GetForViewIndependentUse()
    
// Get the current ResourceManager (there's one per app)
set resourceManager = ResourceManager.Current
    
// Get the "Files" ResourceMap from the ResourceManager
set fileResources = resourceManager.MainResourceMap.GetSubtree("Files")
    
// Find the NamedResource with the logical filename we're looking for,
// by indexing into the ResourceMap
set desiredResource = fileResources["UICommands\ui.txt"]
    
// Get the ResourceCandidate that best matches our ResourceContext
set bestCandidate = desiredResource.Resolve(resourceContext)
   
// Get the string value (the filename) from the ResourceCandidate
set absoluteFileName = bestCandidate.ValueAsString

Si noti in particolare che il codice non richiede una cartella di linguaggio specifica, ad esempio UICommands\en-US\ui.txt , anche se questo è il modo in cui i file esistono su disco. Richiede invece il nome file logico e si basa su MRT UICommands\ui.txt per trovare il file su disco appropriato in una delle directory del linguaggio.

Da qui, l'app di esempio può continuare a usare CreateFile per caricare le absoluteFileName coppie e analizzare le name=value coppie esattamente come in precedenza; nessuna di quella logica deve cambiare nell'app. Se si scrive in C# o C++/CX, il codice effettivo non è molto più complicato di questo (e in effetti molte delle variabili intermedie possono essere eliminate). Vedere la sezione Caricamento di risorse .NET, di seguito. Le applicazioni basate su C++/WRL saranno più complesse a causa delle API basate su COM di basso livello usate per attivare e chiamare le API WinRT, ma i passaggi fondamentali da eseguire sono gli stessi: vedere la sezione Caricamento delle risorse MUI Win32, di seguito.

Caricamento di risorse .NET

Poiché .NET dispone di un meccanismo predefinito per l'individuazione e il caricamento delle risorse (noto come "Assembly satellite"), non esiste alcun codice esplicito da sostituire come nell'esempio sintetico precedente, in .NET sono necessarie solo le DLL delle risorse nelle directory appropriate e si trovano automaticamente. Quando un'app viene inserita in un pacchetto come MSIX o .appx usando i Pacchetti di risorse, la struttura di directory è leggermente diversa, anziché avere le directory delle risorse come sottodirectory della directory principale dell'applicazione, sono peer di esso (o non sono presenti affatto se l'utente non ha la lingua elencata nelle preferenze).

Si supponga, ad esempio, che un'applicazione .NET con il layout seguente, in cui tutti i file esistano nella MainApp cartella:

+ MainApp
|--+ en-us
|  \--- MainApp.resources.dll
|--+ de-de
|  \--- MainApp.resources.dll
|--+ fr-fr
|  \--- MainApp.resources.dll
\--- MainApp.exe

Dopo la conversione in .appx, il layout avrà un aspetto simile al seguente, presupponendo en-US che fosse la lingua predefinita e che l'utente abbia sia il tedesco che il francese elencati nell'elenco delle lingue:

+ WindowsAppsRoot
|--+ MainApp_neutral
|  |--+ en-us
|  |  \--- MainApp.resources.dll
|  \--- MainApp.exe
|--+ MainApp_neutral_resources.language_de
|  \--+ de-de
|     \--- MainApp.resources.dll
\--+ MainApp_neutral_resources.language_fr
   \--+ fr-fr
      \--- MainApp.resources.dll

Poiché le risorse localizzate non esistono più nelle sottodirectory sotto il percorso di installazione dell'eseguibile principale, la risoluzione delle risorse .NET predefinita ha esito negativo. Fortunatamente, .NET ha un meccanismo ben definito per la gestione dei tentativi di caricamento degli assembly non riusciti, ovvero l'evento AssemblyResolve . Un'app .NET che usa MRT deve registrarsi per questo evento e fornire l'assembly mancante per il sottosistema di risorse .NET.

Un esempio conciso di come usare le API WinRT per individuare gli assembly satellite usati da .NET è il seguente; Il codice come presentato è intenzionalmente compresso per mostrare un'implementazione minima, anche se è possibile vederlo mappare strettamente allo pseudo-codice precedente, con il passato ResolveEventArgs fornendo il nome dell'assembly che è necessario individuare. Una versione eseguibile di questo codice (con commenti dettagliati e gestione degli errori) è disponibile nel file PriResourceRsolver.cs nell'esempio di Resolver di assembly .NET in GitHub.

static class PriResourceResolver
{
  internal static Assembly ResolveResourceDll(object sender, ResolveEventArgs args)
  {
    var fullAssemblyName = new AssemblyName(args.Name);
    var fileName = string.Format(@"{0}.dll", fullAssemblyName.Name);

    var resourceContext = ResourceContext.GetForViewIndependentUse();
    resourceContext.Languages = new[] { fullAssemblyName.CultureName };

    var resource = ResourceManager.Current.MainResourceMap.GetSubtree("Files")[fileName];

    // Note use of 'UnsafeLoadFrom' - this is required for apps installed with .appx, but
    // in general is discouraged. The full sample provides a safer wrapper of this method
    return Assembly.UnsafeLoadFrom(resource.Resolve(resourceContext).ValueAsString);
  }
}

Data la classe precedente, è necessario aggiungere quanto segue in una posizione iniziale nel codice di avvio dell'applicazione (prima che eventuali risorse localizzate debbano essere caricate):

void EnableMrtResourceLookup()
{
  AppDomain.CurrentDomain.AssemblyResolve += PriResourceResolver.ResolveResourceDll;
}

Il runtime .NET genererà l'evento AssemblyResolve ogni volta che non riesce a trovare le DLL delle risorse, a quel punto il gestore eventi fornito individua il file desiderato tramite MRT e restituisce l'assembly.

Caricamento delle risorse MUI Win32

Il caricamento delle risorse MUI Win32 equivale essenzialmente al caricamento di assembly satellite .NET, ma usando invece il codice C++/CX o C++/WRL. L'uso di C++/CX consente codice molto più semplice che corrisponde al codice C# precedente, ma usa estensioni del linguaggio C++, commutatori del compilatore e overheard di runtime aggiuntivo che si potrebbe voler evitare. In questo caso, l'uso di C++/WRL offre una soluzione a impatto molto inferiore a costi di codice più dettagliato. Tuttavia, se si ha familiarità con la programmazione ATL (o COM in generale), WRL dovrebbe sentirsi familiare.

La funzione di esempio seguente illustra come usare C++/WRL per caricare una DLL di risorse specifica e restituire un HINSTANCE oggetto che può essere usato per caricare altre risorse usando le consuete API delle risorse Win32. Si noti che a differenza dell'esempio C# che inizializza ResourceContext in modo esplicito con il linguaggio richiesto dal runtime .NET, questo codice si basa sul linguaggio corrente dell'utente.

#include <roapi.h>
#include <wrl\client.h>
#include <wrl\wrappers\corewrappers.h>
#include <Windows.ApplicationModel.resources.core.h>
#include <Windows.Foundation.h>
   
#define IF_FAIL_RETURN(hr) if (FAILED((hr))) return hr;
    
HRESULT GetMrtResourceHandle(LPCWSTR resourceFilePath,  HINSTANCE* resourceHandle)
{
  using namespace Microsoft::WRL;
  using namespace Microsoft::WRL::Wrappers;
  using namespace ABI::Windows::ApplicationModel::Resources::Core;
  using namespace ABI::Windows::Foundation;
    
  *resourceHandle = nullptr;
  HRESULT hr{ S_OK };
  RoInitializeWrapper roInit{ RO_INIT_SINGLETHREADED };
  IF_FAIL_RETURN(roInit);
    
  // Get Windows.ApplicationModel.Resources.Core.ResourceManager statics
  ComPtr<IResourceManagerStatics> resourceManagerStatics;
  IF_FAIL_RETURN(GetActivationFactory(
    HStringReference(
    RuntimeClass_Windows_ApplicationModel_Resources_Core_ResourceManager).Get(),
    &resourceManagerStatics));
    
  // Get .Current property
  ComPtr<IResourceManager> resourceManager;
  IF_FAIL_RETURN(resourceManagerStatics->get_Current(&resourceManager));
    
  // get .MainResourceMap property
  ComPtr<IResourceMap> resourceMap;
  IF_FAIL_RETURN(resourceManager->get_MainResourceMap(&resourceMap));
    
  // Call .GetValue with supplied filename
  ComPtr<IResourceCandidate> resourceCandidate;
  IF_FAIL_RETURN(resourceMap->GetValue(HStringReference(resourceFilePath).Get(),
    &resourceCandidate));
    
  // Get .ValueAsString property
  HString resolvedResourceFilePath;
  IF_FAIL_RETURN(resourceCandidate->get_ValueAsString(
    resolvedResourceFilePath.GetAddressOf()));
    
  // Finally, load the DLL and return the hInst.
  *resourceHandle = LoadLibraryEx(resolvedResourceFilePath.GetRawBuffer(nullptr),
    nullptr, LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE);
    
  return S_OK;
}

Fase 3: Creazione di pacchetti di risorse

Ora che si dispone di un "pacchetto fat" che contiene tutte le risorse, esistono due percorsi per la creazione di pacchetti principali e pacchetti di risorse separati per ridurre al minimo le dimensioni di download e installazione:

• Prendere un pacchetto grasso esistente ed eseguirlo tramite lo strumento Bundle Generator per creare automaticamente pacchetti di risorse. Questo è l'approccio preferito se si dispone di un sistema di compilazione che produce già un pacchetto fat e si vuole post-elaborare per generare i pacchetti di risorse.
• Produrre direttamente i singoli pacchetti di risorse e compilarli in un bundle. Questo è l'approccio preferito se si ha più controllo sul sistema di compilazione e può compilare direttamente i pacchetti.

Passaggio 3.1: Creazione del bundle

Uso dello strumento Generatore bundle

Per usare lo strumento Generatore bundle, il file di configurazione PRI creato per il pacchetto deve essere aggiornato manualmente per rimuovere la <packaging> sezione.

Se si usa Visual Studio, vedere Verificare che le risorse siano installate in un dispositivo indipendentemente dal fatto che un dispositivo richieda informazioni su come compilare tutte le lingue nel pacchetto principale creando i file priconfig.packaging.xml e priconfig.default.xml.

Se si modificano manualmente i file, seguire questa procedura:

1. Creare il file di configurazione come in precedenza, sostituendo il percorso corretto, il nome file e le lingue:

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_es-MX /pv 10.0 /o
   

2. Aprire manualmente il file creato .xml ed eliminare l'intera <packaging&rt; sezione (ma mantenere intatto tutto il resto):

   <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
   <resources targetOsVersion="10.0.0" majorVersion="1">
     <!-- Packaging section has been deleted... -->
     <index root="\" startIndexAt="\">
       <default>
       ...
       ...
   

3. Compilare il .pri file e il .appx pacchetto come in precedenza, usando il file di configurazione aggiornato e i nomi di file e directory appropriati (vedere sopra per altre informazioni su questi comandi):

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /o
   

4. AFter il pacchetto è stato creato, usare il comando seguente per creare il bundle usando i nomi di file e directory appropriati:

   BundleGenerator.exe -Package ..\contoso_demo.appx -Destination ..\bundle -BundleName contoso_demo
   

È ora possibile passare al passaggio finale, firmando (vedere di seguito).

Creazione manuale di pacchetti di risorse

La creazione manuale dei pacchetti di risorse richiede l'esecuzione di un set leggermente diverso di comandi per compilare file .pri e .appx separati. Questi sono tutti simili ai comandi usati in precedenza per creare pacchetti fat, quindi viene fornita una spiegazione minima. Nota: tutti i comandi presuppongono che la directory corrente sia la directory contenente il AppXManifest.xml file, ma tutti i file vengono inseriti nella directory padre (è possibile usare una directory diversa, se necessario, ma non è consigliabile inquinare la directory del progetto con uno di questi file). Come sempre, sostituire i nomi file "Contoso" con i propri nomi di file.

1. Usare il comando seguente per creare un file di configurazione che denomina solo la lingua predefinita come qualificatore predefinito, en-USin questo caso:

   makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
   

2. Creare un file .pri e .map.txt predefinito per il pacchetto principale, oltre a un set aggiuntivo di file per ogni lingua presente nel progetto, con il comando seguente:

   makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
   

3. Usare il comando seguente per creare il pacchetto principale (che contiene il codice eseguibile e le risorse della lingua predefinite). Come sempre, modificare il nome come previsto, anche se è necessario inserire il pacchetto in una directory separata per semplificare la creazione del bundle in un secondo momento (questo esempio usa la ..\bundle directory):

   makeappx pack /m .\AppXManifest.xml /f ..\resources.map.txt /p ..\bundle\contoso_demo.main.appx /o
   

4. Dopo aver creato il pacchetto principale, usare il comando seguente una volta per ogni lingua aggiuntiva (ad esempio, ripetere questo comando per ogni file di mapping della lingua generato nel passaggio precedente). Anche in questo caso, l'output deve trovarsi in una directory separata (uguale a quella del pacchetto principale). Si noti che la lingua è specificata sia sia nell'opzione /f sia nell'opzione /p e nell'uso del nuovo /r argument (which indicates a Resource Package is desired):

   makeappx pack /r /m .\AppXManifest.xml /f ..\resources.language-de.map.txt /p ..\bundle\contoso_demo.de.appx /o
   

5. Combinare tutti i pacchetti dalla directory bundle in un singolo .appxbundle file. La nuova /d opzione specifica la directory da usare per tutti i file nel bundle (ecco perché i .appx file vengono inseriti in una directory separata nel passaggio precedente):

   makeappx bundle /d ..\bundle /p ..\contoso_demo.appxbundle /o
   

Il passaggio finale per compilare il pacchetto è la firma.

Passaggio 3.2: Firma del bundle

Dopo aver creato il .appxbundle file (tramite lo strumento Generatore bundle o manualmente) si avrà un singolo file che contiene il pacchetto principale più tutti i pacchetti di risorse. Il passaggio finale consiste nel firmare il file in modo che Windows lo installi:

signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appxbundle

Verrà generato un file firmato .appxbundle che contiene il pacchetto principale più tutti i pacchetti di risorse specifici della lingua. Può essere fatto doppio clic come un file di pacchetto per installare l'app più tutte le lingue appropriate in base alle preferenze di lingua di Windows dell'utente.

Argomenti correlati

• Personalizzare le risorse di lingua, scala, contrasto elevato e altri qualificatori