Requisiti pacchetto app per applicazione MSIX

Requisiti

Segui queste linee guida per preparare i pacchetti della tua app per l'invio al Microsoft Store.

Prima di compilare il pacchetto dell'app per il Microsoft Store

Assicurarsi di testare l'app con il Kit di certificazione app di Windows. Si consiglia inoltre di testare l'app su diversi tipi di hardware. Si noti che finché non si certifica l'app e la si rende disponibile dal Microsoft Store, può essere installata ed eseguita solo nei computer che dispongono di licenze per sviluppatori.

Compilazione del pacchetto dell'app con Microsoft Visual Studio

Se si usa Microsoft Visual Studio come ambiente di sviluppo, sono già disponibili strumenti predefiniti che semplificano la creazione di un pacchetto di app. Per altre info, vedi Creazione di pacchetti di app.

Quando si crea il progetto in Visual Studio, assicurarsi di essere connessi con lo stesso account associato all'account sviluppatore. Alcune parti del manifesto del pacchetto contengono informazioni specifiche relative al tuo account. Queste informazioni vengono rilevate e aggiunte automaticamente. Senza le informazioni supplementari aggiunte al manifesto, si possono verificare errori di caricamento del pacchetto.

Quando crei i pacchetti UWP della tua app, Visual Studio può creare un file .msix o .appx, oppure un file .msixupload o .appxupload. Per le app UWP, ti consigliamo di caricare sempre il file con estensione msixupload o appxupload nella pagina Pacchetti . Per altre info sulla creazione di pacchetti di app UWP per lo Store, vedi Pacchetto un'app UWP con Visual Studio.

Firma del codice per gli invii di Microsoft Store

I pacchetti MSIX e AppX non devono essere firmati con un certificato radicato in un'autorità di certificazione attendibile durante l'invio al Microsoft Store. Il Microsoft Store rifirmerà automaticamente i pacchetti MSIX/AppX con un certificato Microsoft durante il processo di pubblicazione dopo che l'app supera la certificazione. Ciò significa:

• Non è necessario acquistare un certificato di sottoscrizione del codice attendibile da una CA per l'invio su MSIX/AppX Store
• Non è necessario fornire un file pfx o .cer da un'autorità di certificazione per inviare pacchetti MSIX/AppX
• I token USB o i moduli di sicurezza hardware (HSM) non sono necessari per gli invii di MSIX/AppX Store
• Lo Store sostituisce qualsiasi firma esistente nei pacchetti MSIX/AppX con un certificato Microsoft, fornendo attendibilità e sicurezza ai clienti

Bundle delle app

Per le app UWP, Visual Studio può generare un bundle di app (con estensione msixbundle o appxbundle) per ridurre le dimensioni dell'app scaricata dagli utenti. Questo può essere utile se sono stati definiti asset specifici del linguaggio, un'ampia gamma di asset di scalabilità delle immagini o risorse applicabili a versioni specifiche di Microsoft DirectX.

Con un bundle di app, l'utente scaricherà solo i file rilevanti, anziché tutte le risorse possibili. Per altre info sui bundle di app, vedi Packaging apps and Package a UWP app with Visual Studio.

Creazione manuale del pacchetto di app

Se non si usa Visual Studio per creare il pacchetto, è necessario creare manualmente il manifesto del pacchetto.

Assicurarsi di esaminare la documentazione del manifest del pacchetto dell'app per dettagli completi e requisiti del manifest. Il manifesto deve seguire lo schema del manifesto del pacchetto per poter ottenere la certificazione.

Il manifesto deve includere alcune informazioni specifiche sull'account e sull'app. Per trovare queste informazioni, vedere Visualizzare i dettagli dell'identità dell'app nella sezione Gestione dei prodotti della pagina di panoramica dell'app nel dashboard.

I bundle di app (.msixbundle o appxbundle) utilizzano un manifesto diverso. Esaminare la documentazione del manifesto del bundle per informazioni dettagliate e requisiti dei manifesti dell'app. Si noti che in un file con estensione msixbundle o appxbundle il manifesto di ogni pacchetto incluso deve usare gli stessi elementi e attributi, ad eccezione dell'attributo ProcessorArchitecture dell'elemento Identity .

Requisiti per il formato dei pacchetti

I pacchetti dell'app devono essere conformi ai seguenti requisiti.

Versioni supportate

Per le app UWP, tutti i pacchetti devono essere destinati a una versione di Windows 10 o Windows 11 supportata dallo Store. Le versioni supportate dal pacchetto devono essere indicate negli attributi MinVersion e MaxVersionTested dell'elemento TargetDeviceFamily del manifesto dell'app.

File XML StoreManifest

StoreManifest.xml è un file di configurazione facoltativo che può essere incluso nei pacchetti dell'app. Il suo scopo è abilitare le funzionalità, ad esempio dichiarare l'app come app per dispositivi Microsoft Store o dichiarare i requisiti da cui dipende un pacchetto da applicare a un dispositivo, che il manifesto del pacchetto non copre. Se utilizzato, StoreManifest.xml viene inviato con il pacchetto dell'app e deve trovarsi nella cartella radice del progetto principale dell'app. Per altre info, vedi Schema StoreManifest.

Numerazione delle versioni dei pacchetti

Ogni pacchetto specificato deve avere un numero di versione (fornito come valore nell'attributo Version dell'elemento Package/Identity nel manifesto dell'app). Il Microsoft Store applica determinate regole correlate ai numeri di versione, che funzionano in modo leggermente diverso in versioni diverse del sistema operativo.

Numerazione delle versioni per i pacchetti Windows 10 e 11

Quando si sceglie un pacchetto UWP dalla tua pubblicazione, il Microsoft Store userà sempre il pacchetto con la versione più alta applicabile al dispositivo Windows 10 o Windows 11 del cliente. Questo offre una maggiore flessibilità e permette di controllare quali pacchetti verranno forniti ai clienti su determinati tipi di dispositivi. È importante notare che i pacchetti possono essere inviati in qualsiasi ordine; non si è limitati a fornire pacchetti con versioni superiori a ogni invio successivo.

È possibile fornire più pacchetti UWP con lo stesso numero di versione. Tuttavia, i pacchetti che condividono un numero di versione non possono avere la stessa architettura, perché l'identità completa che lo Store utilizza per ogni pacchetto deve essere univoca. Per altre info, vedi Identità.

Quando si forniscono più pacchetti UWP che utilizzano lo stesso numero di versione, l'architettura (nell'ordine x64, x86, Arm, neutral) verrà utilizzata per decidere quale è di livello superiore (quando lo Store determina quale pacchetto fornire al dispositivo di un cliente). Quando si classificano i bundle di app che utilizzano lo stesso numero di versione, si considera il livello di architettura più alto all'interno del bundle: un bundle di app che contiene un pacchetto x64 avrà un livello più alto di uno che contiene solo un pacchetto x86.

Questo offre grande flessibilità per evolvere l'app nel tempo. È possibile caricare e inviare nuovi pacchetti che usano numeri di versione inferiori per aggiungere il supporto per i dispositivi Windows 10 o Windows 11 che non sono stati supportati in precedenza, è possibile aggiungere pacchetti con versioni successive con dipendenze più restrittive per sfruttare i vantaggi delle funzionalità hardware o del sistema operativo oppure aggiungere pacchetti con versioni successive che fungono da aggiornamenti a una o a tutta la base clienti esistente.

L'esempio seguente illustra come gestire la numerazione delle versioni per fornire ai clienti i pacchetti previsti in più invii.

Esempio: passaggio a un singolo pacchetto su più invii

Windows 10 consente di scrivere una singola codebase che viene eseguita ovunque. In questo modo, l'avvio di un nuovo progetto multipiattaforma risulta molto più semplice. Tuttavia, per diversi motivi, potrebbe non essere necessario unire immediatamente codebase esistenti per creare un singolo progetto.

È possibile usare le regole di controllo delle versioni dei pacchetti per spostare gradualmente i clienti in un unico pacchetto per la famiglia di dispositivi universali, mentre si invierà una serie di aggiornamenti provvisori per famiglie di dispositivi specifiche (incluse quelle che sfruttano le API di Windows 10). L'esempio seguente illustra in che modo le stesse regole vengono applicate in modo coerente su una serie di invii per la stessa app.

Utilizzo della numerazione delle versioni per tornare a un pacchetto precedentemente spedito per le nuove acquisizioni

Se si conservano copie dei pacchetti, sarà possibile eseguire il rollback del pacchetto dell'app nello Store a un pacchetto Windows 10 precedente se si dovrebbero individuare problemi con una versione. Si tratta di un modo temporaneo per limitare i disagi per i clienti mentre si prende tempo per risolvere il problema.

Per fare ciò, crea una nuova sottomissione . Rimuovere il pacchetto problematico e caricare il pacchetto precedente che si desidera fornire nello Store. I clienti che hanno già ricevuto il pacchetto di cui si effettua il rollback avranno comunque il pacchetto problematico (poiché il pacchetto precedente avrà un numero di versione precedente). In questo modo, però, si impedirà a chiunque altro di acquisire il pacchetto problematico, consentendo al contempo all'app di essere ancora disponibile nello Store.

Per risolvere il problema per i clienti che hanno già ricevuto il pacchetto problematico, è possibile inviare un nuovo pacchetto Windows 10 con un numero di versione superiore rispetto al pacchetto non valido non appena possibile. Dopo che l'invio ha superato il processo di certificazione, a tutti i clienti verrà fornito il nuovo pacchetto, poiché avrà un numero di versione superiore.

Lingue supportate

Puoi inviare app al Microsoft Store in oltre 100 lingue.

Per altre informazioni sulla configurazione delle lingue nelle app, vedere Globalizzazione e localizzazione eInformazioni sulle lingue del profilo utente e sulle lingue del manifesto dell'app. Abbiamo anche un Multilingual App Toolkit per aiutarti a scrivere app che supportano più lingue.

Elenco delle lingue supportate

Queste sono le lingue supportate dal Microsoft Store. L'app deve supportare almeno una di queste lingue.

I codici delle lingue non inclusi qui non sono supportati dallo Store. Si consiglia di non includere pacchetti con codici lingua diversi da quelli elencati di seguito; tali pacchetti non saranno distribuiti ai clienti e potrebbero causare ritardi o errori di certificazione.