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.
O empacotamento define como seu aplicativo é instalado, atualizado e integrado ao Windows. Os aplicativos WinUI 3 são empacotados por padrão, enquanto muitos aplicativos da área de trabalho, como aplicativos tradicionais do Win32, são executados desempacotados. Escolher entre um aplicativo empacotado ou não empacotado afeta os recursos que você pode usar, o modelo de implantação em que você depende e a experiência geral que seus clientes obtêm.
Observação
Criando um novo aplicativo WinUI 3? Você já está configurado por padrão. As diretrizes a seguir são mais relevantes para desenvolvedores que precisam fazer uma escolha explícita , normalmente ao portar um aplicativo existente, implantar em computadores empresariais ou adicionar recursos Windows a um aplicativo que não foi originalmente empacotado.
Por que o empacotamento de aplicativos importa
Os aplicativos empacotados se beneficiam de um modelo de instalação limpo, atualizações automáticas e acesso a recursos Windows que exigem a identidade do pacote, incluindo tarefas em segundo plano, notificações, extensões de menu de contexto, destinos de compartilhamento e outros pontos de extensibilidade. O empacotamento também ajuda a garantir implantações mais limpas, atualizações confiáveis e distribuição simplificada por meio de canais como o Microsoft Store e as ferramentas de implantação corporativa.
Recursos que exigem a identidade do pacote
Esses recursos Windows funcionam apenas em aplicativos que têm a identidade do pacote, seja por meio de empacotamento MSIX completo ou pacote com local externo (empacotamento esparso).
| Característica | Descrição |
|---|---|
| Tarefas em segundo plano | Execute o código quando o aplicativo não estiver em primeiro plano , por exemplo, para sincronizar dados, processar downloads ou responder a eventos do sistema. |
| Windows APIs de IA (Phi Silica, OCR etc.) | Acesse recursos de IA no dispositivo, como modelos de idioma local, reconhecimento de texto e análise de imagem. |
| Notificações por push (WNS) | Receba notificações em tempo real do serviço de nuvem por meio do Serviço de Notificação do Windows. |
| Destino de compartilhamento | Permitir que os usuários compartilhem conteúdo de outros aplicativos diretamente no seu por meio da planilha de compartilhamento do sistema. |
| Extensões de menu de contexto personalizado | Adicione as ações do seu aplicativo ao menu de clique com o botão direito do mouse no Explorador de Arquivos e em outras superfícies do shell. |
| Tipo de arquivo e associações de protocolo | Registre seu aplicativo como o manipulador para tipos de arquivo específicos ou protocolos de URI (por exemplo, yourapp://). |
| Tarefas de inicialização | Inicie seu aplicativo automaticamente quando o usuário entrar no Windows. |
| Serviços de aplicativo | Exponha os serviços de fundo que outros aplicativos podem chamar para permitir a comunicação entre aplicativos. |
Dica
Se você estiver desempacotado e encontrando erros de E_ILLEGAL_METHOD_CALL ou APPMODEL_ERROR_NO_PACKAGE ao chamar APIs do Windows, esse é o requisito de identidade do pacote. Veja o empacotamento com local externo (empacotamento esparso) como a correção de menor atrito.
Para obter mais informações, consulte Recursos que exigem a identidade do pacote.
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 (submissão do MSIX) | Novos aplicativos, publicação na Loja, MDM corporativo |
| Empacotamento com localização externa | ✅ Sim | Seu instalador existente | ✅ Sim (envio de MSI/EXE) | Aplicativos existentes com instalador próprio, ISVs |
| Desempacotado | ❌ Não | Instalador MSI ou EXE (também: XCopy ou script para distribuição fora da Loja) | ✅ Sim (envio de MSI/EXE – requer um instalador MSI ou EXE com suporte de instalação silenciosa) | Distribuição ampla do Win32, ferramentas internas |
Aplicativos empacotados (MSIX)
Os aplicativos empacotados usam MSIX e têm identidade do pacote, o que é necessário para vários pontos de extensibilidade do Windows. A identidade do pacote permite que Windows identifiquem de forma confiável o chamador de APIs de plataforma, razão pela qual esses recursos dependem dele.
- Os aplicativos empacotados normalmente são executados em um contêiner de aplicativo leve, com virtualização do sistema de arquivos e do registro (consulte AppContainer para aplicativos herdados e aplicativos MSIX AppContainer).
- Os aplicativos também podem ser configurados para não serem executados em um contêiner de aplicativo, se necessário.
- O MSIX é usado tanto para empacotamento quanto para instalação (veja o que é MSIX?).
Empacotamento com localização externa (empacotamento esparso)
O empacotamento com local externo (também chamado pacotes esparsos) permite que você registre um pequeno pacote de identidade junto ao 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).
Esse é o ponto perfeito para aplicativos Win32/WPF/WinForms existentes que são distribuídos por meio de instalador próprio (NSIS, WiX, InstallShield etc.) e não querem substituí-lo pelo MSIX. Você registra um pacote de identidade, mantém seus binários onde estão e desbloqueia o conjunto completo de recursos do Windows restritos por identidade de pacote.
| Capacidade | MSIX | Local externo |
|---|---|---|
| Substitui seu instalador | Sim | No |
| Binários dentro do pacote | Sim | Não (externo) |
| Loja elegível | Sim (submissão MSIX) | Sim (envio de MSI/EXE) |
| 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
Aplicativos não empacotados
Aplicativos não empacotados não usam MSIX e não têm identidade de pacote, o que significa que eles não podem acessar os recursos listados acima.
- Eles permanecem totalmente irrestritos em termos de superfície da API, acesso ao sistema de arquivos, acesso ao registro, elevação e modelo de processo.
- A instalação e as atualizações dependem de
.exe,.msi, instaladores personalizados, ClickOnce ou xcopy deployment.
Antes de se comprometer a desempacotar, verifique a tabela de recursos acima em relação ao roteiro. Se notificações, tarefas em segundo plano ou APIs de IA estiverem no horizonte, considere iniciar com pacotes.
Escolher por cenário
| Scenario | Modelo recomendado | Detalhes |
|---|---|---|
| Desenvolvedor indie publicando na Microsoft Store | Empacotado (MSIX) recomendado | MSIX é o caminho recomendado – ele habilita atualizações gerenciadas pela Loja, downloads diferenciais e desinstalação limpa. Os aplicativos WinUI 3 são empacotados por padrão. A assinatura de código é feita gratuitamente pela Microsoft Store. → Distribuir seu aplicativo empacotado Aplicativos Win32 com um instalador MSI ou EXE existente também podem publicar na Loja por meio do caminho de envio do MSI/EXE, mas a Loja não envia atualizações por push para usuários existentes – as atualizações devem ser tratadas pelo aplicativo ou pelo instalador. |
| Aplicativo corporativo implantado por meio do Intune ou do Gerenciador de Configurações | Local empacotado ou externo para instaladores existentes | Novos aplicativos devem usar o MSIX. Aplicativos existentes com seu próprio instalador podem usar empacotamento com localização externa. Code signing: use um certificado autoassinado (confiável via Intune, Política de Grupo ou Gerenciador de Configurações) ou Azure Artifact Signing (anteriormente Trusted Signing). → implantar aplicativos empacotados |
| ISV disponibilizando um download direto com instalador próprio | Empacotamento com localização externa | Registre um pacote de identidade leve junto com o instalador existente.
Assinatura de código: é necessário um certificado confiável de uma Autoridade Certificadora para distribuição fora da Loja.
Azure Artifact Signing (antigo Trusted Signing) é a opção de menor custo recomendada.
Conceder identidade de pacote Como alternativa, envie o instalador existente para a Loja usando o caminho de envio MSI/EXE. |
| Ferramenta interna ou utilitário de desenvolvedor | Desempacotado | Mais simples de construir e implantar. O SDK do Aplicativo Windows funciona por meio do NuGet, mas alguns recursos não estarão disponíveis. |
Dica
Não tem certeza sobre os custos de assinatura de código? Publicar um pacote MSIX por meio do Microsoft Store significa que você não precisa obter ou gerenciar separadamente um certificado de confiança do usuário final — Microsoft assina novamente o pacote. A publicação de um instalador Win32 MSI/EXE por meio da Loja requer um encadeamento de certificados para uma Autoridade Certificadora no Microsoft Trusted Root Program; certificados autoassinados não são aceitos. Para outros caminhos de distribuição, sua abordagem de assinatura depende do contexto de implantação – os ambientes empresariais podem confiar em um certificado autoassinado por meio do gerenciamento de dispositivos, enquanto uma distribuição não Store mais ampla normalmente requer uma solução de assinatura de código confiável da AC. Azure Artifact Signing (antigo Trusted Signing) é a opção recomendada da Microsoft (consulte preços), sem que nenhum token de hardware seja necessário.
Implantação dependente de framework versus autossuficiente
Independentemente do modelo de empacotamento, os aplicativos que usam o SDK do Aplicativo Windows escolhem como carregar suas dependências de tempo de execução.
- Dependente de framework: o runtime SDK do Aplicativo Windows deve ser instalado no computador do usuário. Menor volume de aplicativo; depende do runtime estar presente ou instalado automaticamente.
- Autossuficiente: Todos os binários do SDK do Aplicativo Windows são enviados com seu aplicativo. Volume maior; nenhum requisito de runtime externo. Bom para ambientes corporativos bloqueados.
Implantar aplicativos independentes
Comece com MSIX
Se você criar um aplicativo de área de trabalho Win32 (às vezes chamado de aplicativo de área de trabalho classic) ou um aplicativo .NET , incluindo Windows Presentation Foundation (WPF) e Windows Forms (WinForms), você poderá empacotar e implantar seu aplicativo usando o MSIX.
- Criar um pacote MSIX com base em um instalador existente
- Criar um pacote MSIX usando o código-fonte
- Gerenciar a implantação do MSIX
Outras tecnologias de instalação
- Instalação e manutenção de aplicativos
- Windows Installer
- visão geral da publicação de aplicativos .NET
- Implementação do .NET Framework e aplicações
- Deploying a WPF application
- Implantação ClickOnce para Windows Forms
Conteúdo relacionado
- Visão geral da identidade do pacote
- Implantação de aplicativos empacotados (SDK do Aplicativo Windows)
- Implantar aplicativos não empacotados (SDK do Aplicativo Windows)
- Tutorial: Desempacotar um aplicativo WinUI
Windows developer