Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Requisitos
Siga estas instrucciones para preparar los paquetes de la aplicación para su envío al Microsoft Store.
Antes de compilar el paquete de la aplicación para el Microsoft Store
Asegúrate de testar tu aplicación con el Kit de certificación de Aplicación de Windows. También se recomienda probar la aplicación en diferentes tipos de hardware. Tenga en cuenta que hasta que certifiquemos la aplicación y la hagamos disponible desde la Microsoft Store, solo se puede instalar y ejecutar en equipos que tengan licencias de desarrollador.
Compilación del paquete de la aplicación mediante Microsoft Visual Studio
Si usa Microsoft Visual Studio como entorno de desarrollo, ya tiene herramientas integradas que hacen que la creación de un paquete de aplicación sea un proceso rápido y sencillo. Para más información, vea Empaquetado de aplicaciones.
Nota:
Asegúrese de que todos los nombres de archivo usen ANSI.
Al crear el paquete en Visual Studio, asegúrese de que ha iniciado sesión con la misma cuenta asociada a la cuenta de desarrollador. Algunas partes del manifiesto del paquete contienen detalles específicos relacionados con tu cuenta. Esta información se detecta y se agrega automáticamente. Sin la información adicional agregada al manifiesto, es posible que encuentre errores de carga de paquetes.
Tipos de paquetes de aplicaciones
- Paquete de aplicación (.msix o .appx): Un único paquete que contiene la aplicación y sus recursos, dirigidos a una única arquitectura de dispositivo. Por ejemplo, un paquete de aplicación x64 o x86. Para tener como destino varias arquitecturas con un lote de aplicaciones, deberá generar una para cada arquitectura.
- Paquete de aplicaciones (.msixbundle o .appxbundle): Una agrupación de aplicaciones es un tipo de paquete que puede contener varios paquetes de aplicaciones, cada uno de los cuales se crea para admitir una arquitectura de dispositivo específica. Por ejemplo, una agrupación de aplicaciones puede contener tres paquetes de aplicaciones independientes para las configuraciones x86, x64 y ARM. Los conjuntos de aplicaciones deben generarse siempre que sea posible, ya que permiten que la aplicación esté disponible en la gama más amplia posible de dispositivos.
- Archivo de carga de paquetes de aplicaciones (.msixupload o .appxupload) —solo para el envío a la tienda—: Un único archivo que puede contener varios paquetes de aplicaciones o un paquete de aplicaciones para ser compatible con diversas arquitecturas de procesador. El archivo de carga del paquete de la aplicación también contiene un archivo de símbolos (un archivo .appxsym) para evaluar el análisis de errores después de que la aplicación se haya publicado en la Microsoft Store. Este archivo se creará automáticamente si va a empaquetar la aplicación con Visual Studio con la intención de enviarlo al Centro de partners para su publicación en el Microsoft Store. Nota: Un archivo appxsym es un archivo .pdb comprimido que contiene símbolos públicos de su aplicación utilizados para el análisis de errores en Partner Center. Puedes omitir este archivo, pero si lo haces, no habrá información de análisis de fallos o depuración disponible para tu aplicación.
Al compilar paquetes para UWP de la aplicación, Visual Studio puede crear un archivo .msix o appx, o un archivo .msixupload o .appxupload. Para las aplicaciones UWP, le recomendamos que cargue siempre el archivo .msixupload o .appxupload en la página Paquetes. Para obtener más información sobre el empaquetado de aplicaciones para UWP para la Tienda, consulta Paquete una aplicación para UWP con Visual Studio.
Firma de código para envíos de Microsoft Store
Los paquetes MSIX y AppX no tienen que estar firmados con un certificado raíz en una entidad de certificación de confianza al enviar al Microsoft Store. El Microsoft Store volverá a firmar automáticamente los paquetes MSIX/AppX con un certificado de Microsoft durante el proceso de publicación después de que la aplicación supere la certificación. Esto significa lo siguiente:
- No es necesario comprar un certificado de firma de código de confianza de CA para envíos de MSIX/AppX Store.
- No es necesario proporcionar un archivo .pfx o .cer de una entidad de certificación para enviar paquetes MSIX/AppX
- Los tokens USB o los módulos de seguridad de hardware (HSM) no son necesarios para envíos de MSIX/AppX Store
- La Tienda reemplaza cualquier firma existente en los paquetes MSIX/AppX por un certificado de Microsoft, lo que proporciona confianza y seguridad a los clientes.
Nota:
Si envías un instalador MSI o EXE a la Tienda, la Tienda no vuelve a firmar esos archivos. Debe firmar usted mismo sus instaladores MSI/EXE con un certificado de firma de código válido usando Authenticode antes del envío.
Nota:
Si va a distribuir el paquete MSIX fuera del Microsoft Store (por ejemplo, para la implementación empresarial o la instalación de prueba), deberá firmar el paquete usted mismo con su propio certificado de firma de código. Para obtener más información, consulte Firmar un paquete de aplicación mediante SignTool.
Compilación manual del paquete de la aplicación
Si no usa Visual Studio para crear el paquete, debe crear manualmente el manifiesto del paquete.
Asegúrese de revisar la documentación del manifiesto del paquete de la aplicación para obtener los detalles y requisitos completos del manifiesto. El manifiesto debe seguir el esquema del manifiesto del paquete para pasar la certificación.
El manifiesto debe incluir información específica sobre la cuenta y la aplicación. Puede encontrar esta información consultando Ver detalles de identidad de la aplicación en la sección Gestión de productos de la página general de su aplicación en el panel de control.
Nota:
Los valores del manifiesto distinguen mayúsculas de minúsculas. Los espacios y otros signos de puntuación también deben coincidir. Introduzca los valores cuidadosamente y revíselos para asegurarse de que son correctos.
Los lotes de aplicaciones (.msixbundle o .appxbundle) usan un manifiesto diferente. Revise la documentación del manifiesto de paquetes para obtener los detalles y los requisitos de los manifiestos de paquetes de aplicaciones. Tenga en cuenta que en un .msixbundle o .appxbundle, el manifiesto de cada paquete incluido debe usar los mismos elementos y atributos, excepto para el atributo ProcessorArchitecture del elemento Identity.
Sugerencia
Asegúrese de ejecutar Aplicación de Windows Kit de certificación antes de enviar los paquetes. Esto puede ayudarle a determinar si el manifiesto tiene algún problema que pueda provocar errores de certificación o envío.
Requisitos de formato del paquete
Los paquetes de la aplicación deben cumplir estos requisitos.
| Propiedad del paquete de la aplicación | Requisito |
|---|---|
| Tamaño de paquete | .msixbundle o .appxbundle: 25 GB máximo por lote Paquetes .msix o .appx destinados a Windows 10 o Windows 11: 25 GB máximo por paquete |
| Bloqueo de hashes de mapa | Algoritmo SHA2-256 |
Versiones compatibles
Para las aplicaciones para UWP, todos los paquetes deben tener como destino una versión de Windows 10 o Windows 11 compatibles con la Tienda. Las versiones que admite el paquete deben indicarse en los atributos MinVersion y MaxVersionTested del elemento TargetDeviceFamily del manifiesto de la aplicación.
Archivo XML de StoreManifest
StoreManifest.xml es un archivo de configuración opcional que se puede incluir en los paquetes de la aplicación. Su propósito es habilitar características, como declarar tu aplicación como una aplicación de dispositivo para Microsoft Store o declarar los requisitos de los que depende un paquete para ser aplicable a un dispositivo, que el manifiesto del paquete no cubre. Si se usa, StoreManifest.xml se envía con el paquete de la aplicación y debe estar en la carpeta raíz del proyecto principal de la aplicación. Para obtener más información, consulte Esquema de StoreManifest.
Numeración de la versión del paquete
Cada paquete que proporcione debe tener un número de versión (proporcionado como un valor en el atributo Version del elemento Package/Identity en el manifiesto de la aplicación). El Microsoft Store aplica ciertas reglas relacionadas con los números de versión, que funcionan de forma algo diferente en distintas versiones del sistema operativo.
Nota:
Aunque este tema hace referencia a "paquetes", a menos que se indique, se aplican las mismas reglas a los números de versión para los archivos .msix/.appx y .msixbundle/.appxbundle.
Numeración de versiones para paquetes de Windows 10 y 11
Importante
Para los paquetes de Windows 10 o Windows 11 (UWP), la última sección (cuarta) del número de versión está reservada para el uso de Store y debe dejarse como 0 al compilar el paquete (aunque la Tienda puede cambiar el valor de esta sección). Las demás secciones deben establecerse en un entero comprendido entre 0 y 65535 (excepto la primera sección, que no puede ser 0).
Al elegir un paquete UWP del envío publicado, la Microsoft Store siempre usará el paquete con la versión más alta que sea aplicable al dispositivo con Windows 10 o Windows 11 del cliente. Esto le proporciona más flexibilidad y le permite controlar qué paquetes se ofrecerán a los clientes en determinados tipos de dispositivos. Es importante destacar que puede enviar estos paquetes en cualquier orden; no está limitado a proporcionar paquetes con versiones superiores en cada envío posterior.
Puedes proporcionar varios paquetes UWP con el mismo número de versión. Sin embargo, los paquetes que comparten un número de versión no pueden tener también la misma arquitectura, porque la identidad completa que Store utiliza para cada uno de sus paquetes debe ser única. Para obtener más información, consulte Identity.
Cuando se proporcionan varios paquetes UWP que usan el mismo número de versión, la arquitectura (en el orden x64, x86, Arm, neutral) se usará para decidir cuál es de mayor rango (cuando Store determina qué paquete proporcionar al dispositivo de un cliente). Cuando se clasifican agrupaciones de aplicaciones que usan el mismo número de versión, se tiene en cuenta la clasificación de arquitectura más alta dentro de la agrupación: una agrupación de aplicaciones que contiene un paquete x64 tendrá una clasificación superior a la que solo contiene un paquete x86.
Esto le ofrece mucha flexibilidad para evolucionar la aplicación a lo largo del tiempo. Puede cargar y enviar nuevos paquetes que usen números de versión inferiores para agregar compatibilidad con dispositivos Windows 10 o Windows 11 que no admitía anteriormente, puede agregar paquetes con versiones superiores que tengan dependencias más estrictas para aprovechar las características de hardware o sistema operativo, o puede agregar paquetes con versiones posteriores que sirvan como actualizaciones a algunas o todas las bases de clientes existentes.
En el ejemplo siguiente se muestra cómo se puede administrar la numeración de versiones para entregar los paquetes previstos a los clientes en varios envíos.
Ejemplo: pasar a un paquete único en lugar de múltiples envíos
Windows 10 permite escribir un código base único que se ejecuta en todas partes. Esto facilita mucho el inicio de un nuevo proyecto entre plataformas. Sin embargo, por una serie de razones, es posible que no desee combinar bases de código existentes para crear un único proyecto de inmediato.
Puede usar las reglas de control de versiones de paquetes para mover gradualmente a los clientes a un único paquete para la familia de dispositivos universales, mientras envía una serie de actualizaciones provisionales para familias de dispositivos específicas (incluidas las que aprovechan las API de Windows 10). En el ejemplo siguiente se muestra cómo se aplican las mismas normas de forma coherente en una serie de envíos para la misma aplicación.
| Presentación | Contenido | Experiencia del cliente |
|---|---|---|
| 1 | - Versión del paquete: 1.1.10.0 - Familia de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 |
- Los dispositivos con Windows 10 y 11 Desktop compilación 10.0.10240.0 y posteriores obtendrán 1.1.10.0 - Otras familias de dispositivos no podrán comprar ni instalar la aplicación. |
| 2 | - Versión del paquete: 1.1.10.0 - Familia de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 - Versión del paquete: 1.0.0.0 - Familia de dispositivos: Windows. Universal, minVersion 10.0.10240.0 |
- Los dispositivos con Windows 10 y 11 Desktop compilación 10.0.10240.0 y posteriores obtendrán 1.1.10.0 - Otras familias de dispositivos (que no sean de escritorio) recibirán la versión 1.0.0.0 cuando se introduzcan. - Los dispositivos de escritorio que ya tengan instalada la aplicación no verán ninguna actualización (porque ya tienen la mejor versión disponible, 1.1.10.0, y son superiores a 1.0.0.0). |
| 3 | - Versión del paquete: 1.1.10.0 - Familia de dispositivos: Windows.Desktop, minVersion 10.0.10240.0 - Versión del paquete: 1.1.5.0 - Familia de dispositivos: Windows. Universal, minVersion 10.0.10250.0 - Versión del paquete: 1.0.0.0 - Familia de dispositivos: Windows. Universal, minVersion 10.0.10240.0 |
- Los dispositivos con Windows 10 y 11 Desktop compilación 10.0.10240.0 y posteriores obtendrán 1.1.10.0 - Otras familias de dispositivos (que no sean de escritorio) recibirán la versión 1.1.5.0 a partir de la versión 10.0.10250.0. - Otras familias de dispositivos (no de escritorio) cuando se introduzcan con la compilación > >=10.0.10240.0 y < >=10.010250.0 obtendrán 1.1.0.0 - Los dispositivos de escritorio que ya tengan instalada la aplicación no verán ninguna actualización (porque ya tienen la mejor versión disponible, 1.1.10.0, que es superior a las versiones 1.1.5.0 y 1.0.0.0) |
| 4 | - Versión del paquete: 2.0.0.0 - Familia de dispositivos: Windows. Universal, minVersion 10.0.10240.0 |
- Todos los clientes de todas las familias de dispositivos de Windows 10 y 11 compilación v10.0.10240.0 y versiones posteriores obtendrán el paquete 2.0.0.0. |
Nota:
En todos los casos, los dispositivos de los clientes recibirán el paquete que tenga el número de versión más alto posible para el que cumplan los requisitos. Por ejemplo, en el tercer envío anterior, todos los dispositivos de escritorio obtendrán v1.1.10.0, incluso si tienen la versión del sistema operativo 10.0.10250.0 o posterior y, por tanto, también podrían aceptar v1.1.5.0. Dado que 1.1.10.0 es el número de versión más alto disponible para ellos, es el paquete que obtendrán.
Uso de la numeración de versiones para revertir a un paquete enviado previamente para nuevas adquisiciones
Si mantienes copias de tus paquetes, tendrás la opción de revertir el paquete de la aplicación en la Tienda a un paquete de Windows 10 anterior si deberías detectar problemas con una versión. Se trata de una forma temporal de limitar las molestias a sus clientes mientras se toma su tiempo para solucionar el problema.
Para ello, cree un nuevo envío. Elimine el paquete problemático y cargue el paquete antiguo que quiere proporcionar en Store. Los clientes que ya hayan recibido el paquete que está revirtiendo seguirán teniendo el paquete problemático (ya que su paquete anterior tendrá un número de versión anterior). Pero esto impedirá que cualquier otra persona adquiera el paquete problemático, al tiempo que permitirá que la aplicación siga estando disponible en Store.
Para corregir el problema de los clientes que ya han recibido el paquete problemático, puede enviar un nuevo paquete de Windows 10 que tenga un número de versión superior al paquete incorrecto tan pronto como pueda. Una vez que ese envío pase el proceso de certificación, todos los clientes se actualizarán al nuevo paquete, ya que tendrá un número de versión superior.
Idiomas compatibles
Puede enviar aplicaciones al Microsoft Store en más de 100 idiomas.
Para obtener más información sobre cómo configurar idiomas en las aplicaciones, consulte Globalización y localización y Descripción de los lenguajes de perfil de usuario y los lenguajes de manifiesto de la aplicación. También tenemos un Kit de herramientas para aplicaciones multilingües para ayudarle a escribir aplicaciones que admiten varios idiomas.
Lista de idiomas admitidos
Estos son los idiomas que admite el Microsoft Store. La aplicación debe ser compatible con al menos uno de estos idiomas.
Los códigos de idioma que no se incluyen aquí no son compatibles con la Tienda. Se recomienda no incluir paquetes destinados a códigos de idioma distintos de los enumerados a continuación; estos paquetes no se distribuirán a los clientes y pueden provocar retrasos o errores en la certificación.
| Nombre del idioma | Códigos de idioma admitidos |
|---|---|
| Árabe | 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 |
| Afrikáans | AF, af-za |
| Albanés | sq, sq-al |
| Amárico | am, am-et |
| Armenio | hola, hy-am |
| Asamés | as, as-in |
| Azerbaiyano | az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az |
| Vasco (España) | UE, eu-es |
| Bielorruso | ser, be-by |
| Bengalí | bn, bn-bd, bn-in |
| Bosnio | bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba |
| Búlgaro | bg, bg-bg |
| Catalán | ca, ca-es, ca-es-valencia |
| Cheroqui | chr-cher, chr-cher-us, chr-latn |
| Chino (simplificado) | zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg |
| Chino (tradicional) | zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw |
| Croata | RRHH, hr-hr, hr-ba |
| Checo | cs, cs-cz |
| Danés | da, da-dk |
| Darí | prs, prs-af, prs-arab |
| Neerlandés | nl, nl-nl, nl-be |
| Inglés | 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 |
| Estonio | et, et-ee |
| Filipino | fil, fil-latn, fil-ph |
| Finés | fi, fi-fi |
| Francés | 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 |
| Gallego | gl, gl-es |
| Georgiano | ka, ka-ge |
| Alemán | de, de-at, de-ch, de-de, de-lu, de-li |
| Griego | el, el-gr |
| Gujarati | gu, gu-in |
| Hausa | ha, ha-latn, ha-latn-ng |
| Hebreo | he, he-il |
| hindi | hola, hi-in |
| Húngaro | hu, hu-hu |
| Islandés | is, is-is |
| Igbo | ig-latn, ig-ng |
| Indonesio | id, id-id |
| Inuktitut (latín) | iu-cans, iu-latn, iu-latn-ca |
| Irlandés | ga, ga-ie |
| isiXhosa | xh, xh-za |
| isiZulu | zu, zu-za |
| Italiano | it, it-it, it-ch |
| Japonés | ja , ja-jp |
| Canarés | kn, kn-in |
| Kazajo | kk, kk-kz |
| Jemer | km, km-kh |
| Quiché | quc-latn, qut-gt, qut-latn |
| Kinyarwanda | rw, rw-rw |
| Kiswahili | SW, sw-ke |
| Konkani | kok, kok-in |
| Coreano | ko, ko-kr |
| Kurdo | ku-arab, ku-arab-iq |
| Kirguís | ky-kg, ky-cyrl |
| Lao | lo, lo-la |
| Letón | lv, lv-lv |
| Lituano | lt, lt-lt |
| Luxemburgués | lb, lb-lu |
| Macedonio | mk, mk-mk |
| Malayo | MS, ms-bn, ms-my |
| Malayalam | ml, ml-in |
| Maltés | Mt, mt-mt |
| Maorí | mi, mi-latn, mi-nz |
| Maratí | mr, mr-in |
| Mongol (cirílico) | mn-cyrl, mn-mong, mn-mn, mn-phag |
| Nepalí | ne, ne-np |
| Noruego | nb, nb-no, nn, nn-no, no, no-no, |
| Odia | or, or-in |
| Persa | fa, fa-ir |
| Polaco | pl, pl-pl |
| Portugués (Brasil) | pt-br |
| Portugués (Portugal) | pt, pt-pt |
| Punjabí | pa, pa-arab, pa-arab-pk, pa-deva, pa-in |
| Quechua | quz, quz-bo, quz-ec, quz-pe |
| Rumano | ro, ro-ro |
| Ruso | ru , ru-ru |
| Gaélico escocés | gd-gb, gd-latn |
| Serbio (latino) | sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs |
| Serbio (cirílico) | sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs |
| Sotho septentrional | nso, nso-za |
| Setsuana | tn, tn-bw, tn-za |
| Sindhi | sd-arab, sd-arab-pk, sd-deva |
| Cingalés | sí, si-lk |
| Eslovaco | sk, sk-sk |
| Esloveno | sl, sl-si |
| Español | 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 |
| Sueco | sv, sv-se, sv-fi |
| Tayiko (cirílico) | tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn |
| Tamil | ta, ta-in |
| Tártaro | tt-arab, tt-cyrl, tt-latn, tt-ru |
| Telugu | te, te-in |
| Tailandés | Th, th-th |
| Tigriña | ti, ti-et |
| Turco | tr, tr-tr |
| Turcomano | tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr |
| Ucraniano | uk, uk-ua |
| Urdú | ur, ur-pk |
| Uigur | ug-arab, ug-cn, ug-cyrl, ug-latn |
| Uzbeko (alfabeto latino) | uz, uz-cyrl, uz-latn, uz-latn-uz |
| Vietnamita | vi, vi-vn |
| Galés | cy, cy-gb |
| Wolof | wo, wo-sn |
| Yoruba | yo-latn, yo-ng |
Preguntas más frecuentes
¿Necesito empaquetar mi aplicación como MSIX o puedo enviar un instalador TRADICIONAL EXE/MSI?
El Microsoft Store admite varios formatos de empaquetado. MSIX es el formato recomendado, pero también se aceptan instaladores EXE/MSI tradicionales.
Formatos de paquete MSIX y relacionados admitidos:
- .msix
- .msixbundle
- .msixupload
- .appx
- .appxbundle
- .appxupload
.xapes un tipo de paquete heredado asociado a las aplicaciones publicadas anteriormente y no se usa para nuevos envíos.Entre las ventajas de MSIX se incluyen:
- Firma de código Microsoft gratis y hospedaje de CDN.
- Actualizaciones más fáciles y una mejor integración con las características de Windows.
- Compatibilidad con funcionalidades avanzadas, como el vuelo y el comercio.
El uso del formato de paquete MSIX garantiza una experiencia de instalación y actualización más confiable, segura y simplificada para los usuarios.
Envío EXE/MSI:
- Permitido desde junio de 2021.
- Debe proporcionar una dirección URL del paquete para el instalador como parte del envío; El instalador debe hospedarse en su propia infraestructura o red CDN.
- Requisitos:
- Debe ser solo .exe o .msi.
- Instalador sin conexión: no hay descargas durante la instalación.
- El instalador no debe cambiar después del envío o agrupar software no relacionado.
Ambos tipos de aplicación se pueden enviar en la Store según las necesidades del desarrollador.