App-Paketanforderungen für MSIX-App
Anforderungen
Befolgen Sie diese Richtlinien, um die Pakete Ihrer App für die Übermittlung an den Microsoft Store vorzubereiten.
Vor dem Erstellen des App-Pakets für den Microsoft Store
Stellen Sie sicher, dass Sie Ihre App mit dem Windows App Certification Kit testen. Wir empfehlen Ihnen außerdem, Ihre App auf verschiedenen Hardwaretypen zu testen. Beachten Sie, dass sie nur auf Computern mit Entwicklerlizenzen installiert und ausgeführt werden kann, bis wir Ihre App zertifizieren und im Microsoft Store verfügbar machen.
Erstellen des App-Pakets mit Microsoft Visual Studio
Wenn Sie Microsoft Visual Studio als Entwicklungsumgebung verwenden, verfügen Sie bereits über integrierte Tools, mit denen Sie ein App-Paket schnell und einfach erstellen können. Weitere Informationen finden Sie unter Packen von Apps.
Hinweis
Achten Sie darauf, dass alle Ihre Dateinamen ANSI verwenden.
Wenn Sie Ihr Paket in Visual Studio erstellen, stellen Sie sicher, dass Sie mit demselben Konto angemeldet sind, das Ihrem Entwicklerkonto zugeordnet ist. Einige Teile des Paketmanifests enthalten spezifische Details im Zusammenhang mit Ihrem Konto. Diese Informationen werden automatisch erkannt und hinzugefügt. Ohne die zusätzlichen Informationen, die dem Manifest hinzugefügt wurden, treten möglicherweise Fehler beim Paketupload auf.
Wenn Sie die UWP-Pakete Ihrer App erstellen, kann Visual Studio eine .msix- oder .appx file-Datei oder eine .msixupload- oder appxupload-Datei erstellen. Für UWP-Apps empfehlen wir, dass Sie die .msixupload- oder .appxupload-Datei auf der Seite Pakete hochladen. Weitere Informationen zum Paketieren von UWP-Apps für den Store finden Sie unter Paketieren einer UWP-App mit Visual Studio.
Die Pakete Ihrer App müssen nicht mit einem Zertifikat signiert sein, das von einer vertrauenswürdigen Zertifizierungsstelle stammt.
App-Pakete
Für UWP-Apps kann Visual Studio ein App-Paket (.msixbundle oder .appxbundle) generieren, um die Größe der App zu verringern, die Benutzer herunterladen. Dies kann hilfreich sein, wenn Sie sprachspezifische Ressourcen, eine Vielzahl von Ressourcen zur Bildskalierung oder Ressourcen definiert haben, die für bestimmte Versionen von Microsoft DirectX gelten.
Hinweis
Ein App-Paket kann Ihre Pakete für alle Architekturen enthalten.
Bei einem App-Paket lädt ein Benutzer nur die relevanten Dateien und nicht alle möglichen Ressourcen herunter. Weitere Informationen zu App-Paketen finden Sie unter Paketieren von Apps und Paketieren einer UWP-App mit Visual Studio.
Manuelles Erstellen des App-Pakets
Wenn Sie Visual Studio nicht zum Erstellen des Pakets verwenden, müssen Sie Ihr Paketmanifest manuell erstellen.
Lesen Sie unbedingt die Dokumentation zum App-Paketmanifest , um vollständige Manifestdetails und Anforderungen zu erhalten. Ihr Manifest muss dem Paketmanifestschema folgen, um die Zertifizierung zu bestehen.
Ihr Manifest muss bestimmte Informationen zu Ihrem Konto und Ihrer App enthalten. Sie finden diese Informationen, indem Sie sich die Details zur App-Identität im Abschnitt Produktverwaltung auf der Übersichtsseite Ihrer App im Dashboard ansehen.
Hinweis
Bei Werten im Manifest wird zwischen Groß- und Kleinschreibung unterschieden. Leerzeichen und andere Interpunktionszeichen müssen ebenfalls übereinstimmen. Geben Sie die Werte sorgfältig ein, und überprüfen Sie sie, um sicherzustellen, dass sie korrekt sind.
App-Pakete (.msixbundle oder .appxbundle) verwenden ein anderes Manifest. Lesen Sie die Dokumentation Paketmanifest, um die Details und Anforderungen für App-Paketmanifeste zu erhalten. Beachten Sie, dass in einem .msixbundle- oder .appxbundle-Manifest für jedes enthaltene Paket dieselben Elemente und Attribute verwendet werden müssen, mit Ausnahme des Attributs ProcessorArchitecture des Elements Identität .
Tipp
Führen Sie unbedingt das Zertifizierungskit für Windows-Apps aus, bevor Sie Ihre Pakete übermitteln. Auf diese Weise können Sie ermitteln, ob Ihr Manifest Probleme hat, die zu Zertifizierungs- oder Übermittlungsfehlern führen können.
Anforderungen an das Paketformat
Die Pakete Ihrer App müssen diese Anforderungen erfüllen.
Eigenschaft des App-Pakets | Anforderung |
---|---|
Paketgröße | .msixbundle oder .appxbundle: maximal 25 GB pro Paket .msix- oder .appx-Pakete für Windows 10 oder Windows 11: maximal 25 GB pro Paket |
Blockzuordnungshashes | SHA2-256-Algorithmus |
Unterstützte Versionen
Für UWP-Apps müssen alle Pakete auf eine vom Store unterstützte Version von Windows 10 oder Windows 11 abzielen. Die von Ihrem Paket unterstützten Versionen müssen in den Attributen MinVersion und MaxVersionTested des Elements TargetDeviceFamily des App-Manifests angegeben werden.
StoreManifest-XML-Datei
StoreManifest.xml ist eine optionale Konfigurationsdatei, die in App-Paketen enthalten sein kann. Ihr Zweck besteht darin, Funktionen zu ermöglichen, z. B. das Deklarieren Ihrer App als Microsoft Store-Geräte-App oder das Deklarieren von Anforderungen, von denen ein Paket abhängt, um auf ein Gerät anwendbar zu sein, die das Paketmanifest nicht abdeckt. Bei Verwendung wird StoreManifest.xml mit dem App-Paket übermittelt und muss sich im Stammordner des Standardprojekts Ihrer App befinden. Weitere Informationen finden Sie im StoreManifest-Schema.
Paketversionsnummerierung
Jedes bereitgestellte Paket muss über eine Versionsnummer verfügen (als Wert im Attribut Version des Elements Paket/Identität im App-Manifest angegeben). Der Microsoft Store erzwingt bestimmte Regeln im Zusammenhang mit Versionsnummern, die in verschiedenen Betriebssystemversionen etwas anders funktionieren.
Hinweis
In diesem Thema wird auf „Pakete“ verwiesen, es sei denn, die gleichen Regeln gelten für Versionsnummern für .msix/.appx- und .msixbundle/.appxbundle-Dateien.
Versionsnummerierung für Windows 10- und Windows 11-Pakete
Wichtig
Für Windows 10- oder Windows 11-Pakete (UWP) ist der letzte (vierte) Abschnitt der Versionsnummer für die Store-Verwendung reserviert und muss beim Erstellen des Pakets 0 bleiben (obwohl der Store den Wert in diesem Abschnitt möglicherweise ändert). Die anderen Abschnitte müssen auf eine ganze Zahl zwischen 0 und 65535 festgelegt werden (mit Ausnahme des ersten Abschnitts, der nicht 0 sein kann).
Wenn Sie ein UWP-Paket aus Ihrer veröffentlichten Übermittlung auswählen, verwendet der Microsoft Store immer das Paket mit der höchsten Version, das für das Windows 10- oder Windows 11-Gerät des Kunden gilt. Dadurch erhalten Sie mehr Flexibilität und können steuern, welche Pakete Kunden auf bestimmten Gerätetypen zur Verfügung gestellt werden. Wichtig ist, dass Sie diese Pakete in beliebiger Reihenfolge übermitteln können. Sie sind nicht darauf beschränkt, Pakete mit höherer Version bei jeder nachfolgenden Übermittlung bereitzustellen.
Sie können mehrere UWP-Pakete mit derselben Versionsnummer bereitstellen. Pakete, die eine Versionsnummer gemeinsam nutzen, können jedoch nicht dieselbe Architektur aufweisen, da die vollständige Identität, die der Store für jedes Ihrer Pakete verwendet, eindeutig sein muss. Weitere Informationen finden Sie unter Identität.
Wenn Sie mehrere UWP-Pakete bereitstellen, die dieselbe Versionsnummer verwenden, wird die Architektur (in der Reihenfolge x64, x86, Arm, neutral) verwendet, um zu entscheiden, welches Paket höher ist (wenn der Store bestimmt, welches Paket für das Gerät eines Kunden bereitgestellt werden soll). Beim Bewerten von App-Paketen, die dieselbe Versionsnummer verwenden, wird der höchste Architekturrang innerhalb des Pakets berücksichtigt: Ein App-Paket, das ein x64-Paket enthält, hat eine höhere Rangfolge als ein Paket, das nur ein x86-Paket enthält.
Dies gibt Ihnen viel Flexibilität, Ihre App im Laufe der Zeit weiterzuentwickeln. Sie können neue Pakete hochladen und übermitteln, die niedrigere Versionsnummern verwenden, um Unterstützung für Windows 10- oder Windows 11-Geräte hinzuzufügen, die Sie zuvor nicht unterstützt haben, Sie können Pakete mit höherer Version hinzufügen, die strengere Abhängigkeiten haben, um Hardware- oder Betriebssystemfeatures zu nutzen, oder Sie können Pakete mit höherer Version hinzufügen, die als Updates für einige oder alle Kunden Ihrer vorhandenen Kundenbasis dienen.
Im folgenden Beispiel wird veranschaulicht, wie die Versionsnummerierung verwaltet werden kann, um die vorgesehenen Pakete über mehrere Übermittlungen an Ihre Kunden zu übermitteln.
Beispiel: Wechseln zu einem einzelnen Paket über mehrere Übermittlungen
Mit Windows 10 können Sie eine einzelne Codebasis schreiben, die überall ausgeführt wird. Dies erleichtert den Start eines neuen plattformübergreifenden Projekts. Aus verschiedenen Gründen möchten Sie vorhandene Codebasen jedoch möglicherweise nicht zusammenführen, um sofort ein einzelnes Projekt zu erstellen.
Sie können die Regeln zur Paketversionierung verwenden, um Ihre Kunden schrittweise in ein einzelnes Paket für die universelle Gerätefamilie zu verschieben, während sie eine Reihe von Zwischenupdates für bestimmte Gerätefamilien (einschließlich derer, die Windows 10-APIs nutzen) versenden. Das folgende Beispiel veranschaulicht, wie die gleichen Regeln konsistent auf eine Reihe von Übermittlungen für dieselbe App angewendet werden.
Übermittlung | Contents | Benutzerfreundlichkeit |
---|---|---|
1 | – Paketversion: 1.1.10.0 – Gerätefamilie: Windows.Desktop, minVersion 10.0.10240.0 |
– Geräte unter Windows 10 und Windows 11 Desktop Build 10.0.10240.0 und höher erhalten 1.1.10.0 – Andere Gerätefamilien können die App nicht kaufen und installieren. |
2 | – Paketversion: 1.1.10.0 – Gerätefamilie: Windows.Desktop, minVersion 10.0.10240.0 – Paketversion: 1.0.0.0 – Gerätefamilie: Windows.Universal, minVersion 10.0.10240.0 |
– Geräte unter Windows 10 und Windows 11 Desktop Build 10.0.10240.0 und höher erhalten 1.1.10.0 – Andere Gerätefamilien (keine Desktopgeräte) erhalten bei Einführung 1.0.0.0. – Desktopgeräten, auf denen die App bereits installiert ist, werden keine Updates angezeigt (da sie bereits über die beste verfügbare Version verfügen – 1.1.10.0 und sind höher als 1.0.0.0) |
3 | – Paketversion: 1.1.10.0 – Gerätefamilie: Windows.Desktop, minVersion 10.0.10240.0 – Paketversion: 1.1.5.0 – Gerätefamilie: Windows.Universal, minVersion 10.0.10250.0 – Paketversion: 1.0.0.0 – Gerätefamilie: Windows.Universal, minVersion 10.0.10240.0 |
– Geräte unter Windows 10 und Windows 11 Desktop Build 10.0.10240.0 und höher erhalten 1.1.10.0 - Andere Gerätefamilien (keine Desktopgeräte), die mit Build 10.0.10250.0 und höher eingeführt werden, erhalten 1.1.5.0 - Andere Gerätefamilien (ohne Desktop), wenn sie mit Build >=10.0.10240.0 und < 10.010250.0 eingeführt wurden, erhalten 1.1.0.0. – Desktopgeräten, auf denen die App bereits installiert ist, werden keine Updates angezeigt (da sie bereits über die beste verfügbare Version verfügen – 1.1.10.0, die höher als 1.1.5.0 und 1.0.0.0 ist) |
4 | – Paketversion: 2.0.0.0 – Gerätefamilie: Windows.Universal, minVersion 10.0.10240.0 |
– Alle Kunden auf allen Gerätefamilien unter Windows 10 und Windows 11 Build v10.0.10240.0 und höher erhalten Paket 2.0.0.0.0 |
Hinweis
In allen Fällen erhalten Kundengeräte das Paket mit der höchsten Versionsnummer, für die sie sich qualifizieren. In der dritten Übermittlung oben erhalten beispielsweise alle Desktopgeräte v1.1.10.0, auch wenn sie über die Betriebssystemversion 10.0.10250.0 oder höher verfügen und somit auch v1.1.5.0 akzeptieren können. Da 1.1.10.0 die höchste für sie verfügbare Versionsnummer ist, ist dies das Paket, das sie erhalten.
Verwenden der Versionsnummerierung zum Zurücksetzen auf ein zuvor bereitgestelltes Paket für neue Käufe
Wenn Sie Kopien Ihrer Pakete beibehalten, haben Sie die Möglichkeit, das App-Paket im Store auf ein früheres Windows 10-Paket zurückzusetzen, wenn Sie Probleme mit einer Version feststellen sollten. Dies ist eine vorübergehende Möglichkeit, die Beeinträchtigung Ihrer Kunden zu begrenzen, während Sie sich Zeit nehmen, das Problem zu beheben.
Erstellen Sie dazu eine neue Übermittlung. Entfernen Sie das problematische Paket, und laden Sie das alte Paket hoch, das Sie im Store bereitstellen möchten. Kunden, die das Paket, das Sie zurücksetzen, bereits erhalten haben, verfügen weiterhin über das problematische Paket (da Ihr älteres Paket eine frühere Versionsnummer hat). Dadurch wird jedoch verhindert, dass andere Personen das problematische Paket erwerben, während die App weiterhin im Store verfügbar ist.
Um das Problem für Kunden zu beheben, die das problematische Paket bereits erhalten haben, können Sie so schnell wie möglich ein neues Windows 10-Paket mit einer höheren Versionsnummer als das fehlerhafte Paket einreichen. Nachdem diese Übermittlung den Zertifizierungsprozess durchlaufen hat, werden alle Kunden auf das neue Paket aktualisiert, da es eine höhere Versionsnummer haben wird.
Unterstützte Sprachen
Sie können Apps in mehr als 100 Sprachen an den Microsoft Store übermitteln.
Weitere Informationen zum Konfigurieren von Sprachen in Ihren Apps finden Sie unter Globalisierung und Lokalisierung und Grundlegendes zu Sprachen für Benutzerprofil und App-Manifest. Außerdem verfügen wir über ein mehrsprachiges App-Toolkit, mit dem Sie Apps schreiben können, die mehrere Sprachen unterstützen.
Liste unterstützter Sprachen
Dies sind die Sprachen, die der Microsoft Store unterstützt. Ihre App muss mindestens eine dieser Sprachen unterstützen.
Sprachcodes, die hier nicht enthalten sind, werden vom Store nicht unterstützt. Es wird empfohlen, keine Pakete für andere Sprachcodes als die unten aufgeführten zu verwenden. Solche Pakete werden nicht an Kunden verteilt und können zu Verzögerungen oder Fehlern bei der Zertifizierung führen.
Name der Sprache | Unterstützte Sprachcodes |
---|---|
Arabisch | 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 |
Albanisch | sq, sq-al |
Amharisch | am, am-et |
Armenisch | hy, hy-am |
Assamesisch | as, as-in |
Aserbaidschanisch | az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az |
Baskisch (Baskisch) | eu, eu-es |
Belarussisch | be, be-by |
Bengalisch | bn, bn-bd, bn-in |
Bosnisch | bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba |
Bulgarisch | bg, bg-bg |
Katalanisch | ca, ca-es, ca-es-valencia |
Cherokee | chr-cher, chr-cher-us, chr-latn |
Chinesisch (vereinfacht) | zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg |
Chinesisch (traditionell) | zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw |
Kroatisch | hr, hr-hr, hr-ba |
Tschechisch | cs, cs-cz |
Dänisch | da, da-dk |
Dari | prs, prs-af, prs-arab |
Niederländisch | nl, nl-nl, nl-be |
Deutsch | 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 |
Estnisch | et, et-ee |
Filipino | fil, fil-latn, fil-ph |
Finnisch | fi, fi-fi |
Französisch | 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 |
Galicisch | gl, gl-es |
Georgisch | ka, ka-ge |
Deutsch | de, de-at, de-ch, de-de, de-lu, de-li |
Griechisch | el, el-gr |
Gujarati | gu, gu-in |
Haussa | ha, ha-latn, ha-latn-ng |
Hebräisch | he, he-il |
Hindi | hi, hi-in |
Ungarisch | hu, hu-hu |
Isländisch | is, is-is |
Igbo | ig-latn, ig-ng |
Indonesisch | id, id-id |
Inuktitut (Lateinisch) | iu-cans, iu-latn, iu-latn-ca |
Irisch | ga, ga-ie |
isi Xhosa | xh, xh-za |
isi Zulu | zu, zu-za |
Italienisch | it, it-it, it-ch |
Japanisch | ja , ja-jp |
Kannada | kn, kn-in |
Kasachisch | kk, kk-kz |
Khmer | km, km-kh |
K'iche' | quc-latn, qut-gt, qut-latn |
Kinyarwanda | rw, rw-rw |
Kisuaheli | sw, sw-ke |
Konkani | kok, kok-in |
Koreanisch | ko, ko-kr |
Kurdisch | ku-arab, ku-arab-iq |
Kirgisisch | ky-kg, ky-cyrl |
Laotisch | lo, lo-la |
Lettisch | lv, lv-lv |
Litauisch | lt, lt-lt |
Luxemburgisch | lb, lb-lu |
Mazedonisch | mk, mk-mk |
Malaiisch | ms, ms-bn, ms-my |
Malayalam | ml, ml-in |
Maltesisch | mt, mt-mt |
Maori | mi, mi-latn, mi-nz |
Marathi | mr, mr-in |
Mongolisch (Kyrillisch) | mn-cyrl, mn-mong, mn-mn, mn-phag |
Nepalesisch | ne, ne-np |
Norwegisch | nb, nb-no, nn, nn-no, no, no-no, |
Odia | or, or-in |
Persisch | fa, fa-ir |
Polnisch | pl, pl-pl |
Portugiesisch (Brasilien) | pt-br |
Portugiesisch (Portugal) | pt, pt-pt |
Pandschabi | pa, pa-arab, pa-arab-pk, pa-deva, pa-in |
Quechua | quz, quz-bo, quz-ec, quz-pe |
Rumänisch | ro, ro-ro |
Russisch | ru , ru-ru |
Schottisch-Gälisch | gd-gb, gd-latn |
Serbisch (Lateinisch) | sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs |
Serbisch (Kyrillisch) | sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs |
Nord-Sotho | nso, nso-za |
Tswana | tn, tn-bw, tn-za |
Sindhi | sd-arab, sd-arab-pk, sd-deva |
Singhalesisch | si, si-lk |
Slowakisch | sk, sk-sk |
Slowenisch | sl, sl-si |
Spanisch | 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 |
Schwedisch | sv, sv-se, sv-fi |
Tadschikisch (Kyrillisch) | tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn |
Tamilisch | ta, ta-in |
Tatarisch | tt-arab, tt-cyrl, tt-latn, tt-ru |
Telugu | te, te-in |
Thailändisch | th, th-th |
Tigrinya | ti, ti-et |
Türkisch | tr, tr-tr |
Turkmenisch | tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr |
Ukrainisch | uk, uk-ua |
Urdu | ur, ur-pk |
Uigurisch | ug-arab, ug-cn, ug-cyrl, ug-latn |
Usbekisch (Lateinisch) | uz, uz-cyrl, uz-latn, uz-latn-uz |
Vietnamesisch | vi, vi-vn |
Walisisch | cy, cy-gb |
Wolof | wo, wo-sn |
Yoruba | yo-latn, yo-ng |
Windows developer