Partilhar via

Escolha um modelo de embalagem para a sua aplicação Windows

Observação

A construir uma nova aplicação WinUI 3? Já estás configurado por defeito. Esta página destina-se a programadores que precisam de fazer uma escolha explícita — normalmente ao portar uma aplicação existente, implementar para máquinas empresariais ou adicionar funcionalidades do Windows a uma aplicação que não foi originalmente embalada.

As aplicações do Windows podem ser empacotadas, desempacotadas ou algo pelo meio. A escolha certa depende de duas coisas: como está a distribuir a sua aplicação e quais as funcionalidades do Windows de que precisa.

Começa pelo teu cenário

"Sou um programador indie a publicar para a Microsoft Store"

Utilize uma aplicação MSIX empacotada. A loja exige embalagens MSIX. As aplicações WinUI 3 criadas no Visual Studio são embaladas por padrão — não precisa de fazer quaisquer alterações. Tens uma instalação limpa, atualizações automáticas e acesso a todas as funcionalidades bloqueadas por identidade de pacote, como notificações e tarefas em segundo plano.

→ Distribua a tua aplicação embalada

"Estou a construir uma aplicação empresarial implementada via Intune ou Configuration Manager"

Inicie com um pacote; considere uma localização externa se já tiver um instalador existente.

  • Se estiveres a criar uma nova aplicação, usa o MSIX. Integra-se perfeitamente com Intune e SCCM/ConfigMgr e dá-te a identidade completa do pacote.
  • Se tiveres uma aplicação existente com o seu próprio instalador que não podes substituir, usa uma embalagem com localização externa. Isto dá identidade ao pacote da sua aplicação — e acesso a funcionalidades como notificações e tarefas em segundo plano — sem alterar a forma ou onde implementa.
  • Se a tua aplicação realmente não precisar de funcionalidades bloqueadas pela identidade do Windows e tu controlas o ambiente de implementação, o unpackaged funciona, mas vais bater num muro na primeira vez que tentares adicionar notificações ou funcionalidades de IA.

→ Implementar aplicações empacotadas (Windows App SDK)
Conceder identidade ao pacote através de empacotamento em localização externa

Sou um ISV a fazer o envio de um download direto com o meu próprio instalador

Use embalagens com localização externa (anteriormente chamadas de embalagens esparsas).

Este é o ponto ideal para aplicações Win32/WPF/WinForms existentes que são enviadas via instalador próprio (NSIS, WiX, InstallShield, etc.) e não querem substituí-las por MSIX. Regista um pacote de identidade leve ao lado do seu instalador existente, os binários permanecem onde estão, e desbloqueia todo o conjunto de funcionalidades do Windows bloqueadas por identidade de pacote.

Os seus utilizadores não vão notar qualquer alteração na forma como instalam ou atualizam a sua aplicação. Tens as funcionalidades do Windows; Eles têm uma experiência familiar.

→ Identidade do pacote Grant por empacotamento com localização externa
→ Adicionar um pacote de identidade no Visual Studio

"Estou a construir uma ferramenta interna ou utilidade para programadores"

Não embalado está bem — com ressalvas.

As aplicações não empacotadas são as mais simples de construir e implementar: xcopy, robocopy ou um script simples é tudo o que precisas. O SDK da aplicação Windows funciona em aplicações não empacotadas via NuGet. Mas algumas funcionalidades não estarão disponíveis e, se mais tarde decidir que precisa delas, adaptar a identidade do pacote não é trivial.

Antes de se comprometer com o unpackaged, consulte a tabela de funcionalidades abaixo com o seu roteiro. Se notificações, tarefas em segundo plano ou APIs de IA estiverem no horizonte, considere iniciar o pacote em conjunto.

Modelos de embalagem de forma resumida

Modelo Identidade do pacote Instalador Elegível para loja Melhor para
Embalado (MSIX) ✅ Sim MSIX substitui instalador ✅ Sim Novas aplicações, publicação de loja, MDM empresarial
Embalagem com localização externa ✅ Sim O seu instalador atual ❌ Não Aplicações existentes com instalador independente, Fornecedores Independentes de Software (ISVs)
Não embalado ❌ Não XCopy / script ❌ Não Ferramentas internas, utilitários de desenvolvimento, cenários simples

Recursos que exigem identidade do pacote

Estas funcionalidades do Windows só funcionam em aplicações que têm identidade de pacote — seja através de empacotamento MSIX completo ou empacotamento com localização externa.

Feature Notes
Notificações do aplicativo (toast) AppNotificationManager requer identidade de pacote
Tarefas em segundo plano O registo requer a identidade do pacote
APIs de IA do Windows (Phi Silica, OCR, etc.) A maioria das APIs de IA do Windows requer identidade de pacote
Notificações push (WNS) O registo do canal requer identidade do pacote
Alvo de partilha Declarado na declaração do pacote
Extensões personalizadas do menu de contexto Declarado no manifesto do pacote
Tipos de ficheiro e associações de protocolo Associações ricas exigem identidade de pacote
Tarefas de arranque Requer identidade de pacote
Serviços de aplicação Requer identidade de pacote

Sugestão

Se estiver desempacotado e encontrar erros E_ILLEGAL_METHOD_CALL ou APPMODEL_ERROR_NO_PACKAGE ao chamar APIs do Windows, isso está associado ao requisito de identidade de pacote. Considere a embalagem com localização externa como a solução de menor resistência.

Embalagem com localização externa

O empacotamento com localização externa (também chamado de pacotes esparsos) permite-lhe registar um pequeno pacote de identidade juntamente com a sua aplicação existente — sem alterar o instalador, as localizações binárias ou o processo de atualização. Foi introduzido na versão do Windows 10 em 2004 (versão 19041).

Tu forneces:

  • Um manifesto de pacote (ficheiro XML que descreve a identidade da sua aplicação)
  • Um ficheiro assinado .msix contendo apenas o manifesto (sem binários)

O seu instalador atual regista este pacote de identidade, e o Windows trata a sua aplicação como tendo identidade de pacote a partir daí.

Isto é distinto da embalagem completa de MSIX:

MSIX Localização externa
Substitui o teu instalador Sim No
Binários incluídos no pacote Sim Não (externo)
Elegível para loja Sim No
Identidade do pacote Sim Sim
Mecanismo de atualização Atualização MSIX O teu mecanismo atual

Guia completo: Conceder identidade de pacote através de configuração com localização externa

Dependente do framework vs implementação autónoma

Separadamente do modelo de empacotamento, as aplicações que usam o Windows App SDK escolhem como transportar as suas dependências em tempo de execução:

  • Dependente do framework: O runtime do SDK da aplicação Windows deve ser instalado na máquina do utilizador. Impacto de memória menor da aplicação; depende do runtime estar presente ou ser automaticamente instalado.
  • Auto-contido: Todos os binários do SDK de aplicações Windows são incluídos na sua aplicação. Maior área; Não há necessidade de tempo de execução externo. Bom para ambientes empresariais fechados.

→ Implementar aplicações autónomas

Conteúdo relacionado

  • Last updated on