Requisitos do pacote de aplicativos para o aplicativo MSIX

Requisitos

Siga estas diretrizes para preparar os pacotes do aplicativo para envio ao Microsoft Store.

Antes de criar o pacote do aplicativo para o Microsoft Store

Certifique-se de testar seu aplicativo com o Kit de Certificação de Aplicativo do Windows. Também recomendamos que você teste seu aplicativo em diferentes tipos de hardware. Observe que, até certificarmos seu aplicativo e disponibilizá-lo no Microsoft Store, ele só poderá ser instalado e executado em computadores com licenças de desenvolvedor.

Compilar o pacote do aplicativo usando Microsoft Visual Studio

Se você estiver usando Microsoft Visual Studio como seu ambiente de desenvolvimento, você já tem ferramentas internas que tornam a criação de um pacote de aplicativos um processo rápido e fácil. Para obter mais informações, confira Empacotamento de aplicativos.

Observação

Certifique-se de que todos os seus nomes de arquivos usem ANSI.

Ao criar seu pacote no Visual Studio, verifique se você está conectado com a mesma conta associada à sua conta de desenvolvedor. Algumas partes do manifesto do pacote têm detalhes específicos relacionados à sua conta. Essas informações são detectadas e adicionadas automaticamente. Sem as informações adicionais incluídas no manifesto, você pode enfrentar falhas ao enviar pacotes.

Tipos de pacotes de aplicativos

  • Pacote do Aplicativo (.msix ou .appx): Um único pacote que contém seu aplicativo e seus recursos, direcionados a uma única arquitetura de dispositivo. Por exemplo, um pacote de aplicativo x64 ou x86. Para direcionar várias arquiteturas com um pacote de aplicativos, você precisará gerar uma para cada arquitetura.
  • Pacote de aplicativos (.msixbundle ou .appxbundle): Um pacote de aplicativos é um tipo de pacote que pode conter vários pacotes de aplicativos, cada um deles criado para dar suporte a uma arquitetura de dispositivo específica. Por exemplo, um pacote de aplicativos pode conter três pacotes de aplicativos separados para as configurações x86, x64 e ARM. Os pacotes de aplicativos devem ser gerados sempre que possível, pois permitem que seu aplicativo esteja disponível na maior variedade possível de dispositivos.
  • Arquivo de carregamento do pacote do aplicativo (.msixupload ou .appxupload) – somente para Envio da Loja: Um único arquivo que pode conter vários pacotes de aplicativos ou um pacote de aplicativos para dar suporte a várias arquiteturas de processador. O arquivo de upload do pacote do aplicativo também contém um arquivo de símbolos (um arquivo .appxsym) para avaliar a análise de falhas do aplicativo depois que seu aplicativo for publicado na Microsoft Store. Esse arquivo será criado automaticamente para você se você estiver empacotando seu aplicativo com o Visual Studio com a intenção de enviá-lo ao Partner Center para publicação na Microsoft Store. Nota: Um arquivo appxsym é um arquivo .pdb compactado que contém símbolos públicos do seu aplicativo usados para análise de falhas no Partner Center. Você pode omitir esse arquivo, mas se o fizer, nenhuma informação de análise de falhas ou depuração estará disponível para seu aplicativo.

Quando você cria os pacotes UWP do aplicativo, Visual Studio pode criar um arquivo .msix ou appx, ou um arquivo .msixupload ou .appxupload. Para aplicativos UWP, recomendamos que você sempre carregue o arquivo .msixupload ou .appxupload na página Pacotes . Para obter mais informações sobre como empacotar aplicativos UWP para a Loja, consulte Pacote um aplicativo UWP com Visual Studio.

Assinatura de código para envios de Microsoft Store

Seus pacotes MSIX e AppX não precisam ser assinados com um certificado com raiz em uma autoridade de certificação confiável ao enviar para o Microsoft Store. O Microsoft Store assinará automaticamente seus pacotes MSIX/AppX com um certificado da Microsoft durante o processo de publicação após o aplicativo passar na certificação. Isso significa:

  • Você não precisa adquirir um certificado de assinatura de código confiável por uma Autoridade Certificadora (CA) para submissões na loja MSIX/AppX
  • Você não precisa fornecer um arquivo .pfx ou .cer de uma autoridade de certificação para enviar pacotes MSIX/AppX
  • Tokens USB ou HSMs (módulos de segurança de hardware) não são necessários para envios da MSIX/AppX Store
  • A Loja substitui qualquer assinatura existente em pacotes MSIX/AppX por um certificado Microsoft, fornecendo confiança e segurança aos clientes

Observação

Se você estiver enviando um instalador MSI ou EXE para a Loja, a Loja não assinará novamente esses arquivos. Você deve assinar por si mesmo o instalador MSI/EXE com Authenticode, usando um certificado de assinatura de código válido antes da submissão.

Observação

Se você estiver distribuindo seu pacote MSIX fora do Microsoft Store (por exemplo, para implantação corporativa ou sideload), precisará assinar o pacote de forma independente com seu próprio certificado para assinatura de código. Para obter mais informações, consulte Assinar um pacote de aplicativo usando SignTool.

Compilar o pacote do aplicativo manualmente

Se você não usar Visual Studio para criar seu pacote, deverá criar o manifesto do pacote manualmente.

Certifique-se de revisar a documentação do manifesto do pacote do aplicativo para obter os detalhes e requisitos completos. Seu manifesto deve seguir o esquema de manifesto do pacote para passar na certificação.

Seu manifesto deve incluir algumas informações específicas sobre sua conta e seu aplicativo. Você pode encontrar essas informações consultando Ver detalhes da identidade do aplicativo na seção Gerenciamento do produto da página de visão geral do seu aplicativo no painel.

Observação

 Os valores no manifesto diferenciam maiúsculas de minúsculas. Espaços e outras pontuações também devem corresponder. Insira os valores cuidadosamente e revise-os para garantir que estejam corretos.

Os pacotes de aplicativos (.msixbundle ou .appxbundle) usam um manifesto diferente. Revise a documentação do manifesto de pacote para mais informações sobre os detalhes e requisitos dos manifestos de pacotes de aplicativos. Observe que em um .msixbundle ou .appxbundle, o manifesto de cada pacote incluído deve usar os mesmos elementos e atributos, exceto para o atributo ProcessorArchitecture do elemento Identity.

Dica

 Execute o aplicativo do Windows Certification Kit antes de enviar seus pacotes. Isso pode ajudar a determinar se o manifesto tem algum problema que possa causar falhas de certificação ou de envio.

Requisitos de formato do pacote

Os pacotes do seu aplicativo devem estar em conformidade com esses requisitos.

Propriedade do pacote do aplicativo Requisito
Tamanho do pacote .msixbundle ou .appxbundle: máximo de 25 GB por pacote
Pacotes .msix ou .appx destinados a Windows 10 ou Windows 11: máximo de 25 GB por pacote
Bloquear hashes de mapa Algoritmo SHA2-256

Versões suportadas

Para aplicativos UWP, todos os pacotes devem ter como destino uma versão de Windows 10 ou Windows 11 com suporte da Loja. As versões suportadas pelo pacote devem ser indicadas nos atributos MinVersion e MaxVersionTested do elemento TargetDeviceFamily do manifesto do aplicativo.

Arquivo XML StoreManifest

StoreManifest.xml é um arquivo de configuração opcional que pode ser incluído em pacotes de aplicativos. Sua finalidade é habilitar recursos, como declarar seu aplicativo como um aplicativo de dispositivo Microsoft Store ou declarar requisitos dos quais um pacote depende para ser aplicável a um dispositivo, que o manifesto do pacote não abrange. Se usado, o StoreManifest.xml é enviado com o pacote do aplicativo e deve estar na pasta raiz do projeto principal do aplicativo. Para obter mais informações, consulte Esquema StoreManifest.

Numeração de versão do pacote

Cada pacote fornecido deve ter um número de versão (fornecido como um valor no atributo Version do elemento Pacote/Identidade do manifesto do aplicativo). O Microsoft Store impõe determinadas regras relacionadas a números de versão, que funcionam de forma um pouco diferente em diferentes versões do sistema operacional.

Observação

Este tópico refere-se a "pacotes", mas, a menos que indicado, as mesmas regras se aplicam aos números de versão para arquivos .msix/.appx e .msixbundle/.appxbundle.

Numeração de versão para Windows 10 e 11 pacotes

Importante

Para pacotes UWP (Windows 10 ou Windows 11), a última seção (quarta) do número de versão é reservada para uso da Store e deve ser deixada como 0 quando você compilar seu pacote (embora a Loja possa alterar o valor nesta seção). As outras seções devem ser definidas como um inteiro entre 0 e 65535 (exceto a primeira seção, que não pode ser 0).

Ao escolher um pacote UWP do envio publicado, o Microsoft Store sempre usará o pacote de versão mais alta aplicável ao dispositivo Windows 10 ou Windows 11 do cliente. Isso oferece maior flexibilidade e o coloca no controle sobre quais pacotes serão fornecidos aos clientes em tipos de dispositivos específicos. É importante ressaltar que você pode enviar esses pacotes em qualquer ordem. Você não está limitado a fornecer pacotes com versões mais altas a cada envio posterior.

Você pode fornecer vários pacotes UWP com o mesmo número de versão. No entanto, os pacotes que compartilham um número de versão também não podem ter a mesma arquitetura, porque a identidade completa que a Store usa para cada um dos pacotes deve ser exclusiva. Para obter mais informações, consulte Identidade.

Quando você fornece vários pacotes UWP que usam o mesmo número de versão, a arquitetura (na ordem x64, x86, Arm, neutral) será usada para decidir qual deles é de classificação mais alta (quando a Store determina qual pacote fornecer ao dispositivo de um cliente). Ao classificar pacotes de aplicativos que usam o mesmo número de versão, a classificação de arquitetura mais alta dentro do pacote é considerada: um pacote de aplicativos que contém um pacote x64 terá uma classificação mais alta do que um que contém apenas um pacote x86.

Isso lhe dá muita flexibilidade para evoluir seu aplicativo ao longo do tempo. Você pode carregar e enviar novos pacotes que usam números de versão mais baixos para adicionar suporte para dispositivos Windows 10 ou Windows 11 que você não deu suporte anteriormente, adicionar pacotes com versões mais altas que têm dependências mais rigorosas para aproveitar os recursos de hardware ou do sistema operacional ou adicionar pacotes de versão superior que servem como atualizações para alguns ou toda a sua base de clientes existente.

O exemplo a seguir ilustra como a numeração de versão pode ser gerenciada para entregar os pacotes pretendidos aos seus clientes por meio de vários envios.

Exemplo: Transicionando para um pacote único em múltiplas submissões

Windows 10 permite que você escreva uma única base de código que é executada em todos os lugares. Isso torna o início de um novo projeto multiplataforma muito mais fácil. No entanto, por vários motivos, talvez você não queira mesclar bases de código existentes para criar um único projeto imediatamente.

Você pode usar as regras de controle de versão do pacote para mover gradualmente seus clientes para um único pacote para a família de dispositivos Universal, ao mesmo tempo em que enviará várias atualizações provisórias para famílias de dispositivos específicas (incluindo as que aproveitam Windows 10 APIs). O exemplo abaixo ilustra como as mesmas regras são aplicadas consistentemente em uma série de envios para o mesmo aplicativo.

Envio Conteúdos Experiência do cliente
1 - Versão do pacote: 1.1.10.0
- Família de dispositivos: Windows Desktop, minVersion 10.0.10240.0		 - Dispositivos no Windows 10 e 11 Desktop com build 10.0.10240.0 ou superior receberão 1.1.10.0
- Outras famílias de dispositivos não poderão comprar e instalar o aplicativo
2 - Versão do pacote: 1.1.10.0
- Família de dispositivos: Windows Desktop, minVersion 10.0.10240.0

- Versão do pacote: 1.0.0.0
- Família de dispositivos: Windows. Universal, minVersion 10.0.10240.0		 - Dispositivos no Windows 10 e 11 Desktop com build 10.0.10240.0 ou superior receberão 1.1.10.0
– Outras famílias de dispositivos (não desktop) que forem introduzidas receberão 1.0.0.0
– Os dispositivos desktop que já têm o aplicativo instalado não verão nenhuma atualização porque já têm a melhor versão disponível, isto é, 1.1.10.0, e são posteriores a 1.0.0.0
3 - Versão do pacote: 1.1.10.0
- Família de dispositivos: Windows Desktop, minVersion 10.0.10240.0

- Versão do pacote: 1.1.5.0
- Família de dispositivos: Windows. Universal, minVersion 10.0.10250.0

- Versão do pacote: 1.0.0.0
- Família de dispositivos: Windows. Universal, minVersion 10.0.10240.0		 - Dispositivos no Windows 10 e 11 Desktop com build 10.0.10240.0 ou superior receberão 1.1.10.0
– Outras famílias de dispositivos (não desktop) introduzidas com a compilação 10.0.10250.0 e acima receberão 1.1.5.0
- Outras famílias de dispositivos (não desktop) quando introduzidas com build >=10.0.10240.0 e < 10.010250.0 receberão 1.1.0.0
– Os dispositivos desktop que já têm o aplicativo instalado não verão nenhuma atualização porque eles já têm a melhor versão disponível, isto é, 1.1.10.0, que já é posterior a 1.1.5.0 e 1.0.0.0)
4 - Versão do pacote: 2.0.0.0
- Família de dispositivos: Windows. Universal, minVersion 10.0.10240.0		 – Todos os clientes em todas as famílias de dispositivos no Windows 10 e 11 build v10.0.10240.0 e superior receberão o pacote 2.0.0.0

Observação

 Em todos os casos, os dispositivos do cliente receberão o pacote que tem o número de versão mais alto possível para o qual eles se qualificam. Por exemplo, no terceiro envio acima, todos os dispositivos desktop receberão a v1.1.10.0, mesmo que tenham a versão do sistema operacional 10.0.10250.0 ou posterior e, portanto, também poderiam aceitar a v1.1.5.0. Como 1.1.10.0 é o número de versão mais alto disponível para eles, esse é o pacote que eles receberão.

Usar a numeração de versão para reverter para um pacote enviado anteriormente para novas aquisições

Se você mantiver cópias de seus pacotes, terá a opção de reverter o pacote do aplicativo na Loja para um pacote de Windows 10 anterior, caso deva descobrir problemas com uma versão. Essa é uma maneira temporária de limitar a interrupção para seus clientes, enquanto você corrige o problema.

Para fazer isso, crie um novo envio. Remova o pacote problemático e carregue o pacote antigo que você deseja fornecer na Store. Os clientes que já receberam o pacote que você está revertendo ainda terão o pacote problemático (já que seu pacote mais antigo terá um número de versão anterior). Mas isso impedirá que qualquer outra pessoa adquira o pacote problemático, permitindo que o aplicativo ainda esteja disponível na Store.

Para corrigir o problema para os clientes que já receberam o pacote problemático, você pode enviar um novo pacote de Windows 10 que tenha um número de versão maior do que o pacote incorreto assim que possível. Após esse envio passar pelo processo de certificação, todos os clientes serão atualizados para o novo pacote, já que ele terá um número de versão maior.

Idiomas com suporte

Você pode enviar aplicativos para o Microsoft Store em mais de 100 idiomas.

Para saber mais sobre como configurar idiomas em seus aplicativos, consulte Globalização e localização e Compreender os idiomas do perfil do usuário e os idiomas do manifesto do aplicativo. Também temos um kit de ferramentas de aplicativo multilíngue para ajudá-lo a escrever aplicativos compatíveis com vários idiomas.

Lista de idiomas com suporte

Esses são os idiomas aos quais o Microsoft Store dá suporte. Seu aplicativo deve ser compatível com pelo menos um desses idiomas.

Os códigos de idioma que não estão incluídos aqui não são suportados pela Store. Recomendamos que você não inclua pacotes direcionados a códigos de idioma diferentes dos listados abaixo. Esses pacotes não serão distribuídos aos clientes e podem causar atrasos ou falhas na certificação.

Nome do idioma Códigos de idioma com suporte
Á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
Africâner AF, af-za
Albanês sq, sq-al
Amárico am, am-et
Armênia hy, hy-am
Assamês as, as-in
Azerbaidjano az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az
Basco (Basco) UE, eu-es
Bielorrusso be, be-by
Bengali bn, bn-bd, bn-in
Bósnio bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba
Búlgaro bg, bg-bg
Catalão ca, ca-es, ca-es-valencia
Cherokee chr-cher, chr-cher-us, chr-latn
Chinês (simplificado) zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg
Chinês (tradicional) zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw
Croata hr, hr-hr, hr-ba
Tcheco cs, cs-cz
Dinamarquês da, da-dk
Dari prs, prs-af, prs-arab
Holandê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
Estoniano et, et-ee
Filipino fil, fil-latn, fil-ph
Finlandê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
Galego gl, gl-es
Georgiano ka, ka-ge
Alemão de, de-at, de-ch, de-de, de-lu, de-li
Grego el, el-gr
Guzerate gu, gu-in
Haúça ha, ha-latn, ha-latn-ng
Hebraico he, he-il
Híndi oi, hi-in
Húngaro hu, hu-hu
Islandês is, is-is
Igbo ig-latn, ig-ng
Indonésio id, id-id
Inuktitut (Latino) 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 já, ja-jp
Kannada kn, kn-in
Cazaque kk, kk-kz
Khmer km, km-kh
Quiché quc-latn, qut-gt, qut-latn
Quiniaruanda rw, rw-rw
Kiswahili sw, sw-ke
Concani kok, kok-in
Coreano ko, ko-kr
Curdo ku-arab, ku-arab-iq
Quirguiz ky-kg, ky-cyrl
Lao lo, lo-la
Letão lv, lv-lv
Lituano lt, lt-lt
Luxemburguês lb, lb-lu
Macedônio mk, mk-mk
Malaio ms, ms-bn, ms-my
Malaiala ml, ml-in
Maltês Mt, mt-mt
Maori mi, mi-latn, mi-nz
Marati Sr., mr-in
Mongol (Cirílico) mn-cyrl, mn-mong, mn-mn, mn-phag
Nepalês ne, ne-np
Norueguês nb, nb-no, nn, nn-no, não, no-no,
Oriá or, or-in
Persa FA, fa-ir
Polonês pl, pl-pl
Português (Brasil) pt-br
Português (Portugal) pt, pt-pt
Panjabi pa, pa-árabe, pa-árabe-pk, pa-deva, pa-in
Quíchua quz, quz-bo, quz-ec, quz-pe
Romeno ro, ro-ro
Russo ru , ru-ru
Gaélico escocês gd-gb, gd-latn
Sérvio (latino) sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs
Sérvio (cirílico) sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs
Soto setentrional nso, nso-za
Setsuana tn, tn-bw, tn-za
Sindhi sd-arab, sd-arab-pk, sd-deva
Sinhala si, si-lk
Eslovaco Sk, sk-sk
Esloveno sl, sl-si
Espanhol 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
Tadjique (Cirílico) tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn
Tâmil Templar Assassin, ta-in
Tártaro tt-arab, tt-cyrl, tt-latn, tt-ru
Télugo te, te-in
Tailandês th, th-th
Tigrinya ti, ti-et
Turco tr, tr-tr
Turcomeno tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr
Ucraniano uk, uk-ua
Urdu ur, ur-pk
Uigure ug-arab, ug-cn, ug-cyrl, ug-latn
Uzbeque (Latino) uz, uz-cyrl, uz-latn, uz-latn-uz
Vietnamita vi, vi-vn
Galês cy, cy-gb
Wolof wo, wo-sn
Ioruba yo-latn, yo-ng

Perguntas frequentes

  1. Preciso empacotar meu aplicativo como MSIX ou posso enviar um instalador EXE/MSI tradicional?

    O Microsoft Store dá suporte a vários formatos de empacotamento. MSIX é o formato recomendado, mas os instaladores tradicionais do EXE/MSI também são aceitos.

    Os formatos de pacote MSIX com suporte e relacionados:

    • .msix
    • .msixbundle
    • .msixupload
    • .appx
    • .appxbundle
    • .appxupload

    .xap é um tipo de pacote herdado associado a aplicativos publicados anteriormente e não é usado para novos envios.

    Os benefícios do MSIX incluem:

    • Assinatura de código de Microsoft gratuita e hospedagem de CDN.
    • Atualizações mais fáceis e melhor integração com recursos de Windows.
    • Suporte para recursos avançados, como pré-lançamento e comércio.

    O uso do formato de pacote MSIX garante uma experiência de instalação e atualização mais confiável, segura e simplificada para os usuários.

    Envio EXE/MSI:

    • Permitido desde junho de 2021.
    • Você deve fornecer uma URL de pacote para o instalador como parte do envio; o instalador deve ser hospedado em sua própria infraestrutura ou CDN.
    • Requisitos:
      • Deve ser apenas .exe ou .msi.
      • Instalador offline – sem downloads durante a instalação.
      • O instalador não deve ser alterado após a submissão, nem incluir software não relacionado.

    Ambos os tipos de aplicativo podem ser enviados na Store, dependendo das necessidades do desenvolvedor.

  • Last updated on