Requisiti del pacchetto dell'app per l'app MSIX
Requisiti
Attenersi alle seguenti linee guida per preparare i pacchetti dell'app da inviare a Microsoft Store.
Prima di creare il pacchetto dell'app per Microsoft Store
Assicurarsi di testare l'app con il Kit di certificazione app Windows. Si consiglia inoltre di testare l'app su diversi tipi di hardware. Finché non sarà certificata e resa disponibile su Microsoft Store, l'app potrà essere installata ed eseguita solo su computer che dispongono di licenze per sviluppatori.
Creazione del pacchetto dell'app con Microsoft Visual Studio
Se si utilizza Microsoft Visual Studio come ambiente di sviluppo, sono già disponibili strumenti predefiniti che semplificano e accelerano la creazione di un pacchetto dell'app. Per ulteriori informazioni, vedere Creazione di pacchetti delle app.
Nota
Assicurarsi che tutti i nomi file siano ANSI.
Quando si crea il pacchetto in Visual Studio, assicurarsi di aver effettuato l'accesso con lo stesso account associato al proprio account di sviluppatore. Alcune parti del manifesto del pacchetto contengono dettagli specifici relativi al proprio account. Queste informazioni vengono rilevate e aggiunte automaticamente. Senza le informazioni supplementari aggiunte al manifesto, si possono verificare errori di caricamento del pacchetto.
Quando si creano i pacchetti UWP della propria app, Visual Studio può creare un file .msix o appx oppure un file .msixupload o .appxupload. Per le app UWP, si consiglia di caricare sempre il file .msixupload o .appxupload nella pagina Pacchetti. Per ulteriori informazioni sulla creazione di pacchetti di app UWP per lo Store, vedere Creare il pacchetto di un'app UWP con Visual Studio.
I pacchetti dell'app non devono essere firmati con un certificato rooted in un'autorità di certificazione attendibile.
Bundle dell'app
Per le app UWP, Visual Studio può generare un bundle di app (.msixbundle o .appxbundle) per ridurre le dimensioni dell'app scaricata dagli utenti. Questo può essere utile se sono state definite risorse specifiche per la lingua, una varietà di risorse a scala di immagine o risorse che si applicano a versioni specifiche di Microsoft DirectX.
Nota
Un bundle di app può contenere i pacchetti per tutte le architetture.
Con un bundle di app, l'utente scaricherà solo i file rilevanti, anziché tutte le risorse possibili. Per ulteriori informazioni sui bundle di app, vedere Creazione di pacchetti delle app e Creare il pacchetto di un'app UWP con Visual Studio.
Creazione manuale del pacchetto di app
Se non si utilizza Visual Studio per creare il pacchetto, è necessario creare manualmente il manifesto del pacchetto.
Assicurarsi di esaminare la documentazione del manifesto del pacchetto dell'appper informazioni dettagliate e requisiti completi sul manifesto. 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.
Nota
I valori nel manifesto fanno distinzione tra maiuscole e minuscole. Anche gli spazi e altri segni di punteggiatura devono corrispondere. Immettere attentamente i valori ed esaminarli per verificare che siano corretti.
I bundle di app (.msixbundle o appxbundle) utilizzano un manifesto diverso. Esaminare la documentazione del manifesto del bundle per informazioni dettagliate e requisiti per i manifesti del bundle dell'app. In un file con estensione .msixbundle o .appxbundle, il manifesto di ogni pacchetto incluso deve utilizzare gli stessi elementi e attributi, a eccezione dell'attributo ProcessorArchitecture dell'elemento Identity.
Suggerimento
Assicurarsi di eseguire il Kit di certificazione app Windows prima di inviare i pacchetti. In questo modo è possibile determinare se il manifesto presenta problemi che potrebbero causare errori di certificazione o di invio.
Requisiti per il formato dei pacchetti
I pacchetti dell'app devono essere conformi ai seguenti requisiti.
| Proprietà del pacchetto dell'app | Requisito |
|---|---|
| Dimensioni pacchetto | .msixbundle o .appxbundle: massimo 25 GB per bundle Pacchetti .msix o .appx per Windows 10 o Windows 11: massimo 25 GB per pacchetto |
| Hash della mappa a blocchi | Algoritmo SHA2-256 |
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 è quello di abilitare funzionalità, come la dichiarazione dell'app come app per dispositivi di Microsoft Store o la dichiarazione dei requisiti da cui dipende un pacchetto per essere applicabile 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 ulteriori informazioni, vedere Schema StoreManifest.
Numerazione delle versioni dei pacchetti
Ogni pacchetto specificato deve avere un numero di versione (fornito come valore nell'attributo Versione dell'elemento Package/Identity nel manifesto dell'app). Microsoft Store applica determinate regole relative ai numeri di versione, che funzionano in modo leggermente diverso in versioni diverse del sistema operativo.
Nota
Questo argomento si riferisce a "pacchetti", ma, se non specificato, le stesse regole si applicano ai numeri di versione per i file con estensione msix/.appx e msixbundle/.appxbundle.
Numerazione delle versioni per pacchetti Windows 10 e 11
Importante
Per i pacchetti di Windows 10 o Windows 11 (UWP), l'ultima (quarta) sezione del numero di versione è riservata all'uso dello Store e deve essere lasciata a 0 quando si crea il pacchetto (anche se lo Store può modificare il valore di questa sezione). Le altre sezioni devono essere impostate su un numero intero compreso tra 0 e 65535 (ad eccezione della prima sezione, che non può essere 0).
Quando si sceglie un pacchetto UWP tra quelli pubblicati, Microsoft Store utilizzerà sempre il pacchetto con la versione più recente 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 ulteriori informazioni, vedere 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 utilizzano numeri di versione inferiori per aggiungere il supporto per i dispositivi Windows 10 o Windows 11 non supportati in precedenza, aggiungere pacchetti con versione successiva con dipendenze più rigide per sfruttare le funzionalità dell'hardware o del sistema operativo, oppure aggiungere pacchetti con versione successiva che fungono da aggiornamenti per alcuni o tutti i clienti esistenti.
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 un'unica 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 utilizzare le regole di controllo delle versioni dei pacchetti per passare gradualmente i clienti a un unico pacchetto per la famiglia di dispositivi Universal, distribuendo al contempo una serie di aggiornamenti provvisori per famiglie di dispositivi specifiche (compresi quelli 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.
| Invio | Contenuto | Esperienza cliente |
|---|---|---|
| 1 | - Versione pacchetto: 1.1.10.0 - Famiglia di dispositivi: Windows.Desktop, minVersion 10.0.10240.0 |
- Dispositivi in Windows 10 e 11 Desktop build 10.0.10240.0 e versioni successive otterranno 1.1.10.0 - Per altre famiglie di dispositivi non sarà possibile acquistare e installare l'app |
| 2 | - Versione pacchetto: 1.1.10.0 - Famiglia di dispositivi: Windows.Desktop, minVersion 10.0.10240.0 - Versione pacchetto: 1.0.0.0 - Famiglia di dispositivi: Windows.Universal, minVersion 10.0.10240.0 |
- Dispositivi in Windows 10 e 11 Desktop build 10.0.10240.0 e versioni successive otterranno 1.1.10.0 - Altre famiglie di dispositivi (non desktop) quando vengono introdotte otterranno 1.0.0.0.0 - I dispositivi desktop che hanno già installato l'app non vedranno alcun aggiornamento (perché hanno già la versione 1.1.10.0 e sono superiori a 1.0.0.0) |
| 3 | - Versione pacchetto: 1.1.10.0 - Famiglia di dispositivi: Windows.Desktop, minVersion 10.0.10240.0 - Versione pacchetto: 1.1.5.0 - Famiglia di dispositivi: Windows.Universal, minVersion 10.0.10250.0 - Versione pacchetto: 1.0.0.0 - Famiglia di dispositivi: Windows.Universal, minVersion 10.0.10240.0 |
- Dispositivi in Windows 10 e 11 Desktop build 10.0.10240.0 e versioni successive otterranno 1.1.10.0 - Altre famiglie di dispositivi (non desktop) quando introdotte con build 10.0.10250.0 e versioni successive otterranno 1.1.5.0 - Altre famiglie di dispositivi (non desktop) quando introdotte con build >=10.0.10240.0 e < 10.010250.0 otterranno 1.1.0.0 - I dispositivi desktop che hanno già installato l'app non vedranno alcun aggiornamento (perché hanno già la versione 1.1.10.0 più recente di 1.1.5.0 e 1.0.0.0) |
| 4 | - Versione pacchetto: 2.0.0.0 - Famiglia di dispositivi: Windows.Universal, minVersion 10.0.10240.0 |
- Tutti i clienti in tutte le famiglie di dispositivi in Windows 10 e 11 build v10.0.10240.0 e versioni successive otterranno il pacchetto 2.0.0.0 |
Nota
In tutti i casi, i dispositivi dei clienti riceveranno il pacchetto con il numero di versione più alto possibile per cui si qualificano. Ad esempio, nel terzo invio precedente, tutti i dispositivi desktop otterranno la versione 1.1.10.0, anche se hanno la versione del sistema operativo 10.0.10250.0 o successiva, quindi potrebbero accettare anche v1.1.5.0. Poiché 1.1.10.0 è il numero di versione più alto disponibile, questo è il pacchetto che otterranno.
Utilizzo della numerazione delle versioni per tornare a un pacchetto precedentemente spedito per le nuove acquisizioni
Se si conservano copie dei pacchetti, sarà possibile ripristinare il pacchetto dell'app nello Store a un pacchetto di Windows 10 precedente se si dovessero riscontrare problemi con una release. Si tratta di un modo temporaneo per limitare i disagi per i clienti mentre si prende tempo per risolvere il problema.
A tale scopo, creare un nuovo invio. 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 di Windows 10 con un numero di versione superiore a quello del pacchetto difettoso 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
È possibile inviare app a Microsoft Store in oltre 100 lingue.
Per ulteriori informazioni sulla configurazione delle lingue nelle app, vedere Globalizzazione e localizzazione e Comprendere le lingue del profilo utente e lingue del manifesto dell'app. È disponibile anche un Multilingual App Toolkit per aiutare i clienti a scrivere app che supportano più lingue.
Elenco delle lingue supportate
Queste sono le lingue supportate da Microsoft Store. L'app deve supportare almeno una di queste lingue.
I codici lingua 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.
| Nome della lingua | Codici lingua supportati |
|---|---|
| arabo | ar, ar-sa, ar-ae, ar-bh, ar-dz, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sy, ar-tn, ar-ye |
| Afrikaans | af, af-za |
| Albanese | sq, sq-al |
| Amharico | am, am-et |
| Armeno | hy, hy-am |
| Assamese | as, as-in |
| Azero | az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az |
| Basco (Province basche) | eu, eu-es |
| Bielorusso | be, be-by |
| Bengalese | bn, bn-bd, bn-in |
| Bosniaco | bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba |
| Bulgaro | bg, bg-bg |
| Catalano | ca, ca-es, ca-es-valencia |
| Cherokee | chr-cher, chr-cher-us, chr-latn |
| Cinese semplificato | zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg |
| Cinese tradizionale | zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw |
| Croato | hr, hr-hr, hr-ba |
| Ceco | cs, cs-cz |
| Danese | da, da-dk |
| Dari | prs, prs-af, prs-arab |
| Olandese | nl, nl-nl, nl-be |
| italiano | en, en-au, en-ca, en-gb, en-ie, en-in, en-nz, en-sg, en-us, en-za, en-bz, en-hk, en-id, en-jm, en-kz, en-mt, en-my, en-ph, en-pk, en-tt, en-vn, en-zw, en-053, en-021, en-029, en-011, en-018, en-014 |
| Estone | et, et-ee |
| Pilipino | fil, fil-latn, fil-ph |
| Finlandese | fi, fi-fi |
| Francese | fr, fr-be, fr-ca, fr-ch, fr-fr, fr-lu, fr-015, fr-cd, fr-ci, fr-cm, fr-ht, fr-ma, fr-mc, fr-ml, fr-re, frc-latn, frp-latn, fr-155, fr-029, fr-021, fr-011 |
| Galiziano | gl, gl-es |
| Georgiano | ka, ka-ge |
| Tedesco | de, de-at, de-ch, de-de, de-lu, de-li |
| Greco | el, el-gr |
| Gujarati | gu, gu-in |
| Hausa | ha, ha-latn, ha-latn-ng |
| Ebraico | he, he-il |
| Hindi | hi, hi-in |
| Ungherese | hu, hu-hu |
| Islandese | is, is-is |
| Igbo | ig-latn, ig-ng |
| Indonesiano | id, id-id |
| Inuktitut (Latino) | iu-cans, iu-latn, iu-latn-ca |
| Irlandese | ga, ga-ie |
| isiXhosa | xh, xh-za |
| isiZulu | zu, zu-za |
| Italiano | it, it-it, it-ch |
| Giapponese | ja, ja-jp |
| Kannada | kn, kn-in |
| Kazako | kk, kk-kz |
| Khmer | km, km-kh |
| K'iche' | quc-latn, qut-gt, qut-latn |
| Kinyarwanda | rw, rw-rw |
| KiSwahili | sw, sw-ke |
| Konkani | kok, kok-in |
| Coreano | ko, ko-kr |
| Curdo | ku-arab, ku-arab-iq |
| Kirghiso | ky-kg, ky-cyrl |
| Lao | lo, lo-la |
| Lettone | lv, lv-lv |
| Lituano | lt, lt-lt |
| Lussemburghese | lb, lb-lu |
| Macedone | mk, mk-mk |
| Malese | ms, ms-bn, ms-my |
| Malayalam | ml, ml-in |
| Maltese | mt, mt-mt |
| Maori | mi, mi-latn, mi-nz |
| Marathi | mr, mr-in |
| Mongolo (cirillico) | mn-cyrl, mn-mong, mn-mn, mn-phag |
| Nepalese | ne, ne-np |
| Norvegese | nb, nb-no, nn, nn-no, no, no-no, |
| Odia | or, or-in |
| Persiano | fa, fa-ir |
| Polacco | pl, pl-pl |
| Portoghese (Brasile) | pt-br |
| Portoghese (Portogallo) | pt, pt-pt |
| Punjabi | pa, pa-arab, pa-arab-pk, pa-deva, pa-in |
| Quechua | quz, quz-bo, quz-ec, quz-pe |
| Rumeno | ro, ro-ro |
| Russo | ru, ru-ru |
| Scozzese Gaelico | gd-gb, gd-latn |
| Serbo (alfabeto latino) | sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs |
| Serbo (alfabeto cirillico) | sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs |
| Sotho del nord | nso, nso-za |
| Setswana | tn, tn-bw, tn-za |
| Sindhi | sd-arab, sd-arab-pk, sd-deva |
| Sinhala | si, si-lk |
| Slovacco | sk, sk-sk |
| Sloveno | sl, sl-si |
| Spagnolo | es, es-cl, es-co, es-es, es-mx, es-ar, es-bo, es-cr, es-do, es-ec, es-gt, es-hn, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us, es-uy, es-ve, es-019, es-419 |
| Svedese | sv, sv-se, sv-fi |
| Tagico (cirillico) | tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn |
| Tamil | ta, ta-in |
| Tataro | tt-arab, tt-cyrl, tt-latn, tt-ru |
| Telugu | te, te-in |
| Thai | th, th-th |
| Tigrino | ti, ti-et |
| Turco | tr, tr-tr |
| Turkmeno | tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr |
| Ucraino | uk, uk-ua |
| Urdu | ur, ur-pk |
| Uiguro | ug-arab, ug-cn, ug-cyrl, ug-latn |
| Uzbeco (alfabeto latino) | uz, uz-cyrl, uz-latn, uz-latn-uz |
| Vietnamita | vi, vi-vn |
| Gallese | cy, cy-gb |
| Wolof | wo, wo-sn |
| Yoruba | yo-latn, yo-ng |
