Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Observação
Criando um novo aplicativo WinUI 3? Você já está configurado por padrão. Esta página é para desenvolvedores que precisam fazer uma escolha explícita, normalmente ao portar um aplicativo existente, implantar em computadores empresariais ou adicionar recursos do Windows a um aplicativo que não foi originalmente empacotado.
Os aplicativos do Windows podem ser empacotados, desempacotados ou em algum lugar no meio. A escolha certa depende de duas coisas: como você está distribuindo seu aplicativo e quais recursos do Windows você precisa.
Comece com seu cenário
"Sou um desenvolvedor independente publicando na Microsoft Store"
Use um aplicativo MSIX empacotado. A Loja requer pacote MSIX. Os aplicativos WinUI 3 criados no Visual Studio são empacotados por padrão. Você não precisa fazer nenhuma alteração. Você obtém instalação limpa, atualizações automáticas e acesso a todos os recursos fechados por identidade de pacote, como notificações e tarefas em segundo plano.
→ Distribuir seu aplicativo empacotado
"Estou criando um aplicativo empresarial implantado por meio do Intune ou do Configuration Manager"
Inicie o processo com o instalador empacotado; considere usar um local externo se já tiver um instalador existente.
- Se você estiver criando um novo aplicativo, use MSIX. Ele se integra de forma limpa ao Intune e ao SCCM/ConfigMgr e fornece a identidade completa do pacote.
- Se você tiver um aplicativo existente com seu próprio instalador que não consegue substituir, use empacotamento com localização externa. Isso fornece a identidade do pacote do aplicativo e o acesso a recursos como notificações e tarefas em segundo plano, sem alterar como ou onde você implanta.
- Se seu aplicativo realmente não precisar de recursos restritos por identidade do Windows e você controlar o ambiente de implantação, a abordagem desempacotada funcionará, mas você enfrentará dificuldades na primeira vez que tentar adicionar notificações ou recursos de inteligência artificial.
→ implantar aplicativos empacotados (SDK do Aplicativo do Windows)
Conceder identidade ao pacote através de empacotamento com localização externa
"Sou um ISV enviando um download direto com meu próprio instalador"
Use embalagens com localização externa (anteriormente chamadas de pacotes esparsos).
Esse é o ponto ideal para aplicativos Win32/WPF/WinForms existentes que são enviados por meio de seu próprio instalador (NSIS, WiX, InstallShield etc.) e não querem substituí-lo pelo MSIX. Você registra um pacote de identidade simplificado junto ao seu instalador atual, seus binários permanecem onde estão e você desbloqueia o conjunto completo de recursos do Windows controlados por identidade do pacote.
Os usuários não verão nenhuma alteração na forma como instalam ou atualizam seu aplicativo. Você obtém os recursos do Windows; eles ganham uma experiência familiar.
→ Conceder identidade do pacote empacotando com localização externa
→ Adicionar um pacote de identidade no Visual Studio
"Estou criando uma ferramenta interna ou utilitário de desenvolvedor"
Desempacotado é bom — com ressalvas.
Aplicativos não empacotados são os mais simples para criar e implantar: xcopy, robocopy ou um script simples é tudo o que você precisa. O SDK do Aplicativo do Windows funciona em aplicativos não empacotados por meio do NuGet. Mas alguns recursos não estarão disponíveis e, se você decidir mais tarde que precisa deles, a readaptação da identidade do pacote não será trivial.
Antes de se comprometer a desempacotar, verifique a tabela de recursos abaixo em relação ao roteiro. Se notificações, tarefas em segundo plano ou APIs de IA estiverem no horizonte, considere iniciar com pacotes.
Visão geral dos modelos de empacotamento
| Modelo | Identidade do pacote | Instalador | Loja elegível | Mais adequado para |
|---|---|---|---|---|
| Empacotado (MSIX) | ✅ Sim | MSIX substitui instalador | ✅ Sim | Novos aplicativos, publicação na Loja, MDM corporativo |
| Empacotamento com localização externa | ✅ Sim | Seu instalador existente | ❌ Não | Aplicativos existentes com instalador próprio, ISVs |
| Desempacotado | ❌ Não | XCopy/script | ❌ Não | Ferramentas internas, utilitários de desenvolvimento, cenários simples |
Recursos que exigem a identidade do pacote
Esses recursos do Windows funcionam apenas em aplicativos que têm identidade de pacote, seja por meio de empacotamento MSIX completo ou empacotamento com localização externa.
| Característica | Observações |
|---|---|
| Notificações do aplicativo (notificação rápida) |
AppNotificationManager requer a identidade do pacote |
| Tarefas em segundo plano | O registro requer a identidade do pacote |
| APIs de IA do Windows (Phi Silica, OCR etc.) | A maioria das APIs de IA do Windows exige a identidade do pacote |
| Notificações por push (WNS) | O registro de canal requer a identidade do pacote |
| Destino de compartilhamento | Declarado no manifesto do pacote |
| Extensões de menu de contexto personalizado | Declarado no manifesto do pacote |
| Tipo de arquivo e associações de protocolo | Associações ricas exigem identidade de pacote |
| Tarefas de inicialização | Requer a identidade do pacote |
| Serviços de aplicativo | Requer a identidade do pacote |
Dica
Se você estiver desempacotado e enfrentando E_ILLEGAL_METHOD_CALL ou APPMODEL_ERROR_NO_PACKAGE erros ao chamar APIs do Windows, isso se deve ao requisito de identidade do pacote. Veja empacotamento em local externo como a solução de menor atrito.
Empacotamento com localização externa
O empacotamento com local externo (também chamado de pacotes esparsos) permite registrar um pequeno pacote de identidade ao lado do aplicativo existente, sem alterar o instalador, os locais binários ou o processo de atualização. Ele foi introduzido no Windows 10 versão 2004 (build 19041).
Você fornece:
- Um manifesto do pacote (arquivo XML que descreve a identidade do aplicativo)
- Um
.msixassinado que contém apenas o manifesto (sem binários)
O instalador existente registra esse pacote de identidade e o Windows trata seu aplicativo como tendo a identidade do pacote desse ponto em diante.
Isso é diferente do empacotamento MSIX completo:
| MSIX | Local externo | |
|---|---|---|
| Substitui seu instalador | Sim | No |
| Binários dentro do pacote | Sim | Não (externo) |
| Armazenamento elegível | Sim | No |
| Identidade do pacote | Sim | Sim |
| Mecanismo de atualização | Atualização do MSIX | Seu mecanismo existente |
Passo a passo completo: conceder identidade ao pacote utilizando localização externa
Implantação dependente de framework versus autossuficiente
Separadamente do modelo de empacotamento, os aplicativos que usam o SDK de Aplicativos do Windows escolhem como gerenciar suas dependências de tempo de execução:
- Dependente de framework: o runtime do Windows App SDK deve ser instalado na máquina do usuário. Menor volume de aplicativo; depende do runtime estar presente ou instalado automaticamente.
- Independente: Todos os binários do Windows App SDK acompanham seu aplicativo. Volume maior; nenhum requisito de runtime externo. Bom para ambientes corporativos bloqueados.
Implantar aplicativos independentes
Conteúdo relacionado
Colaborar conosco no GitHub
A fonte deste conteúdo pode ser encontrada no GitHub, onde você também pode criar e revisar problemas e solicitações de pull. Para obter mais informações, confira o nosso guia para colaboradores.
Windows developer