Требования к пакету приложений для приложения MSIX

Требования

Следуйте этим рекомендациям, чтобы подготовить пакеты приложения для отправки в Microsoft Store.

Прежде чем создавать пакет приложения для Microsoft Store

Обязательно протестируйте приложение с помощью комплекта сертификации приложений Windows. Мы также рекомендуем протестировать приложение на различных типах оборудования. Обратите внимание, что до тех пор, пока мы не сертифицируем приложение и сделаем его доступным из Microsoft Store, его можно установить и запустить только на компьютерах с лицензиями разработчика.

Создание пакета приложения с помощью Microsoft Visual Studio

Если вы используете Microsoft Visual Studio в качестве среды разработки, у вас уже есть встроенные средства, которые делают создание пакета приложения быстрым и простым процессом. Дополнительные сведения см. в разделе "Упаковка приложений".

Примечание.

Убедитесь, что все имена файлов используют ANSI.

При создании пакета в Visual Studio убедитесь, что вы вошли с той же учетной записью, связанной с учетной записью разработчика. Некоторые части манифеста пакета содержат конкретные сведения, связанные с вашей учетной записью. Эта информация обнаруживается и добавляется автоматически. Без дополнительных сведений, добавленных в манифест, могут возникнуть сбои отправки пакета.

При создании пакетов UWP приложения Visual Studio может создать MSIX или appx-файл, или MSIXupload или APPXUPLOAD-файл. Для приложений UWP рекомендуется всегда отправлять файл MSixupload или APPXupload на странице "Пакеты ". Дополнительные сведения об упаковке приложений UWP для Магазина см. в статье "Упаковка приложения UWP" с помощью Visual Studio.

Пакеты приложения не должны быть подписаны сертификатом, корневым в доверенном центре сертификации.

Пакеты приложений

Для приложений UWP Visual Studio может создать пакет приложений (MSIXbundle или .appxbundle), чтобы уменьшить размер приложения, скачиваемого пользователями. Это может быть полезно, если вы определили ресурсы, относящиеся к языку, различные ресурсы масштабирования изображений или ресурсы, которые применяются к определенным версиям Microsoft DirectX.

Примечание.

 Один пакет приложений может содержать пакеты для всех архитектур.

С пакетом приложений пользователь будет загружать только соответствующие файлы, а не все возможные ресурсы. Дополнительные сведения о пакетах приложений см. в статье "Упаковка приложений " и "Упаковка приложения UWP" с помощью Visual Studio.

Создание пакета приложения вручную

Если вы не используете Visual Studio для создания пакета, необходимо создать манифест пакета вручную.

Обязательно просмотрите документацию по манифесту пакета приложения для получения полных сведений о манифесте и требованиях. Манифест должен следовать схеме манифеста пакета, чтобы передать сертификацию.

Манифест должен содержать некоторые сведения о вашей учетной записи и приложении. Эти сведения можно найти, просмотрев сведения о удостоверении приложения в разделе "Управление продуктами" на странице обзора приложения на панели мониторинга.

Примечание.

 Значения в манифесте чувствительны к регистру. Пробелы и другие знаки препинания также должны соответствовать. Введите значения тщательно и просмотрите их, чтобы убедиться, что они верны.

Пакеты приложений (.msixbundle или .appxbundle) используют другой манифест. Ознакомьтесь с документацией по манифесту пакета для подробных сведений и требований к манифестам пакета приложений. Обратите внимание, что в msixbundle или appxbundle манифест каждого включенного пакета должен использовать те же элементы и атрибуты, за исключением атрибута ProcessorArchitecture элемента Identity.

Совет

 Перед отправкой пакетов обязательно запустите комплект сертификации приложений Windows. Это поможет определить, есть ли у манифеста какие-либо проблемы, которые могут вызвать сбои сертификации или отправки.

Требования к формату пакета

Пакеты приложения должны соответствовать этим требованиям.

Свойство пакета приложения	Требование
Размер пакета	.msixbundle или .appxbundle: 25 ГБ максимум на пакет .msix или .appx пакеты, предназначенные для Windows 10 или Windows 11: 25 ГБ максимум на пакет
Хэши карт блокировок	Алгоритм SHA2-256

Поддерживаемые версии

Для приложений UWP все пакеты должны быть ориентированы на версию Windows 10 или Windows 11, поддерживаемую Магазином. Версии, поддерживаемые пакетом, должны быть указаны в атрибутах MinVersion и MaxVersionTested элемента TargetDeviceFamily манифеста приложения.

XML-файл StoreManifest

StoreManifest.xml — это необязательный файл конфигурации, который может быть включен в пакеты приложений. Его целью является включение функций, таких как объявление приложения в качестве приложения устройства Microsoft Store или объявление требований, которые пакет зависит от применимости к устройству, что манифест пакета не охватывает. При использовании StoreManifest.xml отправляется с пакетом приложения и должен находиться в корневой папке основного проекта приложения. Дополнительные сведения см. в схеме StoreManifest.

Нумерирование версий пакета

Каждый предоставленный пакет должен иметь номер версии (указан в качестве значения в атрибуте Version элемента Package/Identity в манифесте приложения). Microsoft Store применяет определенные правила, связанные с номерами версий, которые работают несколько иначе в разных версиях ОС.

Примечание.

Этот раздел относится к "пакетам", но если не указано, те же правила применяются к номерам версий для файлов MSIX/.appx и MSIXbundle/.appxbundle.

Нумерирование версий для пакетов Windows 10 и 11

Внимание

Для пакетов Windows 10 или Windows 11 (UWP) последний (четвертый) номер версии зарезервирован для использования Магазина и должен быть оставлен как 0 при сборке пакета (хотя Магазин может изменить значение в этом разделе). Другие разделы должны иметь целое число от 0 до 65535 (за исключением первого раздела, которое не может быть 0).

При выборе пакета UWP из опубликованной отправки Microsoft Store всегда будет использовать самый высокий пакет, применимый к устройству Windows 10 или Windows 11 клиента. Это обеспечивает большую гибкость и позволяет контролировать, какие пакеты будут предоставляться клиентам на определенных типах устройств. Важно отметить, что эти пакеты можно отправлять в любом порядке; Вы не ограничиваетесь предоставлением более поздних версий пакетов с каждой последующей отправкой.

Вы можете предоставить несколько пакетов UWP с одинаковым номером версии. Однако пакеты, использующие номер версии, также не могут иметь ту же архитектуру, так как полное удостоверение, используемое Магазином для каждого пакета, должно быть уникальным. Дополнительные сведения см. в разделе "Удостоверение".

При предоставлении нескольких пакетов UWP, использующих один и тот же номер версии, архитектура (в порядке x64, x86, Arm, neutral) будет использоваться для выбора того, какой из них имеет более высокий рейтинг (когда Магазин определяет, какой пакет должен предоставляться устройству клиента). При ранжировании пакетов приложений, использующих тот же номер версии, самый высокий ранг архитектуры в пакете считается: пакет приложений, содержащий пакет x64, будет иметь более высокий ранг, чем один, содержащий только пакет x86.

Это обеспечивает большую гибкость для развития приложения с течением времени. Вы можете отправлять и отправлять новые пакеты, использующие более низкие номера версий для добавления поддержки устройств Windows 10 или Windows 11, которые ранее не поддерживаются, можно добавить более строгие версии пакетов с более строгими зависимостями, чтобы воспользоваться преимуществами компонентов оборудования или ОС, или добавить более высокие версии пакетов, которые служат обновлениями для некоторых или всех существующих клиентских баз.

В следующем примере показано, как управлять нумерированием версий для доставки предполагаемых пакетов клиентам по нескольким отправкам.

Пример. Переход к одному пакету по нескольким отправкам

Windows 10 позволяет создавать единую базу кода, которая выполняется везде. Это упрощает запуск нового кроссплатформенного проекта. Однако по ряду причин может не потребоваться объединить существующие базы кода, чтобы сразу создать один проект.

Правила управления версиями пакетов можно использовать для постепенного перемещения клиентов в один пакет для семейства универсальных устройств, при доставке ряда промежуточных обновлений для определенных семейств устройств (включая те, которые используют преимущества API Windows 10). В приведенном ниже примере показано, как одни и те же правила последовательно применяются к ряду отправки для одного и того же приложения.

Отправка	Содержимое	Интерфейс клиента
1	— Версия пакета: 1.1.10.0 — Семейство устройств: Windows.Desktop, minVersion 10.0.10240.0	— Устройства в Windows 10 и 11 Desktop сборки 10.0.10240.0 и выше получат 1.1.10.0 — Другие семейства устройств не смогут приобрести и установить приложение.
2	— Версия пакета: 1.1.10.0 — Семейство устройств: Windows.Desktop, minVersion 10.0.10240.0 — Версия пакета: 1.0.0.0.0 — Семейство устройств: Windows.Universal, minVersion 10.0.10240.0	— Устройства в Windows 10 и 11 Desktop сборки 10.0.10240.0 и выше получат 1.1.10.0 — Другие семейства устройств , отличные от настольных компьютеров, когда они появились, получат 1.0.0.0 — Настольные устройства, которые уже установили приложение, не увидят никаких обновлений (так как они уже имеют лучшую доступную версию 1.1.10.0 и выше 1.0.0.0).
3	— Версия пакета: 1.1.10.0 — Семейство устройств: Windows.Desktop, minVersion 10.0.10240.0 — Версия пакета: 1.1.5.0 — Семейство устройств: Windows.Universal, minVersion 10.0.10250.0 — Версия пакета: 1.0.0.0.0 — Семейство устройств: Windows.Universal, minVersion 10.0.10240.0	— Устройства в Windows 10 и 11 Desktop сборки 10.0.10240.0 и выше получат 1.1.10.0 — Другие семейства устройств ( не настольного компьютера) при вводе сборки 10.0.10250.0 и выше будут получать 1.1.1.5.0 - Другие (не классические) устройства при вводе сборки >=10.0.10240.0 и < 10.010250.0 получат 1.1.1.0.0 — Классические устройства, которые уже установили приложение, не увидят никаких обновлений (так как они уже имеют лучшую доступную версию 1.1.10.0, которая выше 1.1.5.0 и 1.0.0.0).
4	— Версия пакета: 2.0.0.0.0 — Семейство устройств: Windows.Universal, minVersion 10.0.10240.0	— Все клиенты всех семейств устройств в Windows 10 и 11 сборки версии 10.0.10240.0 и выше получат пакет 2.0.0.0.0.

Примечание.

 Во всех случаях клиентские устройства получат пакет с наибольшим числом версий, для которых они соответствуют. Например, в третьей отправке выше все настольные устройства получат версию 1.1.10.0, даже если у них есть ОС версии 10.0.10250.0 или более поздней версии, а также может принять версию 1.1.5.0. Так как 1.1.10.0 является самым высоким номером версии, доступным для них, то есть пакет, который они получат.

Использование нумерования версий для отката до ранее отправленного пакета для новых приобретений

Если вы храните копии пакетов, у вас будет возможность отката пакета приложения в Магазине до более раннего пакета Windows 10, если вы должны обнаружить проблемы с выпуском. Это временный способ ограничить прерывание работы клиентов во время устранения проблемы.

Для этого создайте новую отправку. Удалите проблемный пакет и отправьте старый пакет, который вы хотите предоставить в Магазине. Клиенты, которые уже получили пакет, который вы откатили, по-прежнему будут иметь проблемный пакет (так как старый пакет будет иметь более ранний номер версии). Но это остановит всех остальных от получения проблемного пакета, позволяя приложению по-прежнему быть доступным в Магазине.

Чтобы устранить проблему для клиентов, которые уже получили проблемный пакет, можно отправить новый пакет Windows 10 с более высоким номером версии, чем плохой пакет, как только вы сможете. После отправки все клиенты будут обновлены до нового пакета, так как у него будет более высокий номер версии.

Поддерживаемые языки

Приложения можно отправлять в Microsoft Store на более чем 100 языках.

Дополнительные сведения о настройке языков в приложениях см. в статье "Глобализация" и "Локализация" и "Общие сведения о языках профилей пользователей" и языках манифеста приложения. У нас также есть набор средств многоязычных приложений, которые помогают создавать приложения, поддерживающие несколько языков.

Список поддерживаемых языков

Это языки, поддерживаемые Microsoft Store. Ваше приложение должно поддерживать хотя бы один из этих языков.

Языковые коды, не включенные здесь, не поддерживаются магазином. Рекомендуется не включать пакеты, предназначенные для кодов языка, отличных от указанных ниже; такие пакеты не будут распространяться клиентами и могут привести к задержкам или сбоям в сертификации.

Имя языка	Коды поддерживаемых языков
Арабский	ar-sa, ar-ae, ar-bh, ar-dz, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ly, ar-om, ar-qa, ar-sy, ar-sn, ar-ye
Африкаанс	af, af-za
Албанский	sq, sq-al
Амхарский	am, am-et
Армянский	hy, hy-am
Ассамский	as, as-in
Азербайджанский	az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az
Баскский	eu, eu-es
Белорусский	be, be-by
Бенгальский	bn, bn-bd, bn-in
Боснийский	bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba
Болгарский	bg, bg-bg
Каталанский	ca, ca-es, ca-es-валенсия
Чероки	chr-cher, chr-cher-us, chr-latn
Китайский (упрощенное письмо)	zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg
Китайский, традиционное письмо	zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw
Хорватский	hr, hr-hr, hr-ba
чешский	cs, cs-cz
датский	da, da-dk
Дари	prs, prs-af, prs-arab
Голландский	nl, nl-nl, nl-be
Английский	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-mt, 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, en-014
Эстонский	et, et-ee
Филиппинский	fil, fil-latn, fil-ph
Финский	fi, fi-fi
Французский	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
Галисийский	gl, gl-es
Грузинский	ka, ka-ge
Немецкий	de, de-at, de-ch, de-de, de-lu, de-li
Греческий	el, el-gr
Гуджарати	gu, gu-in
Хауса	ha, ha-latn, ha-latn-ng
Иврит	он, he-il
Хинди	привет, привет, привет
Венгерский	hu, hu-hu
Исландский	is, is-is
Игбо	ig-latn, ig-ng
Индонезийский	id, id-id
Inuktitut (латиница)	iu-cans, iu-latn, iu-latn-ca
Ирландский	ga, ga-ie
Коса	xh, xh-za
Зулу	zu, zu-za
Итальянский	it-it, it-ch
Японский	ja, ja-jp
Каннада	kn, kn-in
Казахский	kk, kk-kz
Кхмерский	km, km-kh
K'iche'	quc-latn, qut-gt, qut-latn
Киньяруанда	rw, rw-rw
Суахили	sw, sw-ke
Конкани	кок, кок-ин
Корейский	ko, ko-kr
Курдский	ku-arab, ku-arab-iq
Киргизский	ky-kg, ky-cyrl
Лаосский	lo, lo-la
Латышский	lv, lv-lv
Литовский	lt, lt-lt
Люксембургский	lb, lb-lu
Macedonian	mk, mk-mk
Малайский	ms,ms-bn, ms-my
Малаялам	ml, ml-in
Мальтийский	mt, mt-mt
Маори	mi, mi-latn, mi-nz
Маратхи	mr, mr-in
Монгольский (кириллица)	mn-cyrl, mn-mong, mn-mn, mn-phag
Непальский	ne, ne-np
Норвежский	nb, nb-no, nn, nn-no, нет, нет, нет,
Ория	или или в
Персидский	fa, fa-ir
Польский	pl, pl-pl
Португальский (Бразилия)	pt-br
Португальский (Португалия)	pt, pt-pt
Панджаби	pa, pa-arab, pa-arab-pk, pa-deva, pa-in
Кечуа	quz, quz-bo, quz-ec, quz-pe
Румынский	ro, ro-ro
русский	ru, ru-ru
Гэльский	gd-gb, gd-latn
Сербский (латиница)	sr-Latn, sr-latn-cs, sr-latn-ba, sr-latn-me, sr-latn-rs
Сербский (кириллица)	sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs
Северный сото	nso, nso-za
Тсвана	tn, tn-bw, tn-za
Синдхи	sd-arab, sd-arab-pk, sd-deva
Сингальский	si, si-lk
Словацкий	sk, sk-sk
Словенский	sl, sl-si
Испанский	es, es-cl, es-co, es-es, es-mx, es-ar, es-bo, es-cr, es-do, es-ec, es-hn, es-hn, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us, es-uy, es-ve, es-019, es-419
Шведский	sv, sv-se, sv-fi
Таджикский (кириллица)	tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn
Тамильский	ta, ta-in
Татарский	tt-arab, tt-cyrl, tt-latn, tt-ru
Телугу	te, te-in
Тайский	th, th-th
Тигринья	ti, ti-et
Турецкий	tr, tr-tr
Туркменский	tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr
Украинский	uk, uk-ua
Урду	your, your-pk
Уйгурский	ug-arab, ug-cn, ug-cyrl, ug-latn
Узбекский (латиница)	uz, uz-cyrl, uz-latn, uz-latn-uz
Вьетнамский	vi, vi-vn
Валлийский	cy, cy-gb
Волоф	wo, wo-sn
Йоруба	yo-latn, yo-ng