Partilhar via

Visão geral da embalagem

A embalagem define como a sua aplicação é instalada, atualizada e integrada com o Windows. As aplicações WinUI 3 são empacotadas por defeito, enquanto muitas aplicações de ambiente de trabalho, como as aplicações Win32 tradicionais, são executadas sem empacotamento. Escolher entre uma aplicação embalada ou não empacotada afeta as funcionalidades que pode usar, o modelo de implementação em que confia e a experiência global que os seus clientes têm.

Observação

A construir uma nova aplicação WinUI 3? Já estás configurado por defeito. A orientação abaixo é mais relevante para 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.

Por que a embalagem da aplicação é importante

As aplicações empacotadas beneficiam de um modelo de instalação limpo, atualizações automáticas e acesso a funcionalidades do Windows que exigem identidade de pacote — incluindo tarefas em segundo plano, notificações, extensões de menus de contexto, alvos de partilha e outros pontos de extensibilidade. A embalagem também ajuda a garantir implementações mais limpas, atualizações fiáveis e distribuição simplificada através de canais como a Microsoft Store e ferramentas empresariais de implementação.

Recursos que exigem identidade do pacote

Estas funcionalidades 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 (empacotamento esparso).

Feature Descrição
Tarefas em segundo plano Execute código quando a sua aplicação 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.) Aceda a capacidades de IA no dispositivo, como modelos de linguagem local, reconhecimento de texto e análise de imagens.
Notificações push (WNS) Receba notificações em tempo real do seu serviço cloud através do Windows Notification Service.
Alvo de partilha Permita que os utilizadores partilhem conteúdos de outras aplicações diretamente na sua através da folha de partilha do sistema.
Extensões personalizadas do menu de contexto Adicione as ações da sua aplicação ao menu do botão direito no Explorador de Ficheiros e noutras superfícies de shell.
Tipos de ficheiro e associações de protocolo Registe a tua aplicação como handler para tipos específicos de ficheiros ou protocolos URI (por exemplo, yourapp://).
Tarefas de arranque Inicie a sua aplicação automaticamente quando o utilizador iniciar sessão no Windows.
Serviços de aplicação Exponha serviços em segundo plano que outras aplicações possam acedir, permitindo a comunicação entre aplicações.

Sugestão

Se estiver desempacotado e encontrar erros E_ILLEGAL_METHOD_CALL ou APPMODEL_ERROR_NO_PACKAGE ao chamar APIs do Windows, esse é o requisito de identidade do pacote. Veja a embalagem com localização externa (embalagem esparsa) como a solução de menor atrito.

Para mais informações, consulte Funcionalidades que requerem identidade de pacote.

Modelos de embalagem de forma resumida

Modelo Identidade do pacote Instalador Elegível para loja Melhor para
Embalado (MSIX) ✅ Sim MSIX substitui instalador ✅ Sim (submissão MSIX) Novas aplicações, publicação de loja, MDM empresarial
Embalagem com localização externa ✅ Sim O seu instalador atual ✅ Sim (submissão MSI/EXE) Aplicações existentes com instalador independente, Fornecedores Independentes de Software (ISVs)
Não embalado ❌ Não Instalador MSI ou EXE (também: XCopy ou script para distribuição fora da Loja) ✅ Sim (submissão MSI/EXE — requer um instalador MSI ou EXE com suporte de instalação silenciosa) Distribuição ampla Win32, ferramentas internas

Aplicações empacotadas (MSIX)

As aplicações empacotadas usam MSIX e têm identidade de pacote, que é necessária para muitos pontos de extensibilidade do Windows. A identidade do pacote permite ao Windows identificar de forma fiável o chamador das APIs da plataforma, razão pela qual estas funcionalidades dependem dela.

Embalagem com localização externa (Embalagem esparsa)

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).

Este é o ponto ideal para aplicações Win32/WPF/WinForms existentes que são distribuídas através do seu próprio instalador (NSIS, WiX, InstallShield, etc.) e não querem substituir o instalador por MSIX. Regista um pacote de identidade simplificado, os seus binários permanecem onde estão e desbloqueia todas as funcionalidades do Windows protegidas por identidade de pacote.

Capacidade 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 (submissão MSIX) Sim (submissão MSI/EXE)
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

Aplicações não empacotadas

As aplicações não embaladas não usam MSIX e não têm identidade de pacote, o que significa que não podem aceder às funcionalidades mencionadas acima.

  • Permanecem totalmente sem restrições em termos de superfície da API, acesso ao sistema de ficheiros, acesso ao registo, elevação e modelo de processo.
  • A instalação e as atualizações dependem de .exe, .msi, instaladores personalizados, ClickOnce ou da utilização do xcopy para implementação.

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

Escolha por cenário

Scenario Modelo recomendado Detalhes
Desenvolvedor independente a publicar na Microsoft Store Pacote (MSIX) recomendado O MSIX é o caminho recomendado — permite atualizações geridas pela Store, downloads diferenciais e desinstalação limpa. As aplicações WinUI 3 são empacotadas por predefinição. A assinatura de códigos é gerida gratuitamente pela Loja. → Distribua a tua aplicação embalada

Aplicações Win32 com um instalador MSI ou EXE existente também podem ser publicadas na Store através do caminho de submissão MSI/EXE, mas a Store não envia atualizações para utilizadores existentes — as atualizações devem ser tratadas pela aplicação ou pelo instalador.
Aplicação empresarial implementada via Intune ou Gestor de Configuração Localização empacotada ou externa para instaladores existentes As novas aplicações devem usar MSIX. Aplicações existentes com o seu próprio instalador podem usar empacotamentos com localização externa. Assinatura de código: use um certificado autoassinado (confiado via Intune, Group Policy ou Gestor de Configuração) ou Azure Artifact Signing (anteriormente Trusted Signing). → Implementar aplicações empacotadas
ISV envia um download direto com instalador próprio Embalagem com localização externa Regista um pacote de identidade leve juntamente com o teu instalador atual. Assinatura de código: é necessário um certificado de confiança CA para distribuição que não seja da Store. Azure Artifact Signing (anteriormente Trusted Signing) é a opção de menor custo recomendada. → Identidade do pacote Grant

Em alternativa, submeta o seu instalador atual à Loja através do caminho de submissão MSI/EXE.
Ferramenta interna ou utilidade para programadores Unpackaged O mais simples de construir e implementar. O SDK de Aplicações Windows funciona via NuGet, mas algumas funcionalidades não estarão disponíveis.

Sugestão

Não tem a certeza sobre os custos de assinatura de código? Publicar um pacote MSIX através do Microsoft Store significa que não precisa de obter ou gerir separadamente um certificado para confiança no utilizador final — Microsoft reassina o pacote. Publicar um instalador MSI/EXE Win32 através da Store requer um encadeamento de certificado a uma CA no Programa Raiz Confiável da Microsoft; autoassinado não é aceite. Para outros caminhos de distribuição, a sua abordagem de assinatura depende do contexto de implementação — ambientes empresariais podem confiar num certificado auto-assinado através da gestão de dispositivos, enquanto a distribuição mais ampla fora da Store normalmente requer uma solução de assinatura de código confiável na CA. Azure Assinatura de Artefactos (anteriormente Assinatura Confiável) é a opção recomendada pela Microsoft (ver preço), sem necessidade de token de hardware.

Dependente do framework vs implementação autónoma

Separadamente do modelo de empacotamento, as aplicações que usam o SDK de Aplicações Windows escolhem como gerir as suas dependências de runtime.

  • Dependente do Framework: O runtime do SDK de Aplicações Windows deve ser instalado na máquina do usuário. Impacto de memória menor da aplicação; depende do runtime estar presente ou ser automaticamente instalado.
  • Autossuficiente: Todos os binários do SDK de Aplicações Windows são enviados com a 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

Comece com o MSIX

Se construir uma aplicação desktop Win32 (por vezes chamada de app clássica) ou uma aplicação .NET — incluindo Windows Presentation Foundation (WPF) e Windows Forms (WinForms) — então pode empacotar e implementar a sua aplicação usando o MSIX.

Outras tecnologias de instalação

Conteúdo relacionado

  • Last updated on