Aplicativos do Windows: empacotamento, implantação e processo

Este tópico discute as suas opções relativas:

  • Que opção de embalagem usar para a sua aplicação (embalada, com localização externa ou não embalada)?
  • Como vais implementar/distribuir a tua aplicação e como será instalada.
  • O processo em tempo de execução da sua aplicação, incluindo o grau de isolamento e as APIs que lhe estarão disponíveis.

Pode tomar essas decisões tanto para aplicações novas como existentes. Mas se ainda estás na fase de planeamento para uma nova aplicação, antes de começares a pensar nas considerações acima, decide primeiro que plataforma de desenvolvimento e framework de interface de utilizador (UI) vais usar para a tua aplicação. E para essa decisão, veja Uma visão geral das opções de desenvolvimento do Windows.

Opções de embalagem: embalado, embalado com localização externa ou não embalado

A decisão sobre qual opção de embalagem usar para a sua aplicação é inicialmente determinada por um conceito conhecido como identidade de embalagem, que descreveremos nesta secção. Se não precisares disso, então a decisão depende da experiência de instalador desejada para ti e para os teus utilizadores. Vamos aprofundar os detalhes dessas coisas.

Muitas funcionalidades de extensibilidade do Windows (tarefas em segundo plano, notificações, extensões de menu contextual personalizadas e alvos de partilha) só podem ser usadas por uma aplicação se essa aplicação tiver identidade de pacote em tempo de execução. Isso porque o sistema operacional (SO) precisa ser capaz de identificar o chamador da API correspondente. Consulte Funcionalidades que exigem identidade do pacote.

  • Se precisares de usar alguma dessas funcionalidades, então a tua aplicação precisa de identidade de pacote. Por isso, tem de ser uma aplicação embalada (as aplicações embaladas são as únicas que têm identidade de pacote). Uma aplicação é empacotada utilizando a tecnologia MSIX (consulte O que é MSIX?).
    • Para uma aplicação nova, o processo de embalagem é simples (e no final desta secção há informações sobre como o fazer).
    • Para algumas aplicações existentes, pode seguir o mesmo processo de embalagem que para uma nova aplicação. Mas como alguns aplicativos existentes ainda não estão prontos para que todo o seu conteúdo esteja presente dentro de um pacote MSIX, há uma opção para que seu aplicativo seja empacotado com localização externa. Isso permite que seu aplicativo tenha identidade de pacote; podendo assim utilizar as funcionalidades que o exigem. Para obter mais informações, consulte Atribuir identidade ao pacote através do empacotamento com localização externa.
  • Mesmo que não precises de usar nenhuma dessas funcionalidades, criar uma aplicação embalada continua a ser uma boa ideia. Dá aos teus utilizadores a forma mais fácil de instalar, desinstalar e atualizar a tua aplicação. Para mais informações, consulte Deployment/distribution/installation neste tópico.
  • Mas criar uma aplicação não embalada é uma opção.

A conclusão é que as aplicações embaladas são as únicas que têm identidade de pacote (e têm a melhor experiência de instalação). Uma aplicação não empacotada não tem identidade de pacote; por isso não pode usar as APIs/funcionalidades mencionadas acima.

Para mais detalhes sobre empacotamento versus não empacotado, veja Visão geral da Implantação; em particular, as vantagens e desvantagens de empacotar a sua aplicação nesse tópico. Esse tópico também menciona a opção de embalar com localização externa .

Para informações sobre como configurar a sua aplicação como empacotada ou desempacotada:

Veja também a secção Windows Gestor de Pacotes e o cliente WinGet neste tópico.

Implementação/distribuição/instalação

  • Uma aplicação empacotada é empacotada utilizando a tecnologia MSIX.
  • Uma aplicação não empacotada não envolve MSIX de todo.

Então, porque é que importa se a sua aplicação está ou não embalada?

  • Bem, o MSIX oferece aos seus utilizadores uma forma fácil de instalar, desinstalar e atualizar a sua aplicação. A desinstalação é limpa: quando a sua aplicação é desinstalada, o sistema é restaurado ao mesmo estado em que se encontrava antes da instalação; não ficam quaisquer artefactos para trás.
  • Este tipo de aplicativo também suporta atualizações incrementais e automáticas.
  • A Microsoft Store otimiza para aplicações deste tipo (embora possam ser usadas dentro ou fora da Loja).
  • É uma opção fácil de utilização através da anexação de aplicação MSIX (para máquinas virtuais do Azure Virtual Desktop). Para mais informações, veja O que é MSIX app attach?.
  • Um pacote assinado beneficia de uma forte proteção contra adulteração. Este benefício é ainda maior do que para uma aplicação não embalada instalada em Program Files.

Veja também a secção Windows Gestor de Pacotes e o cliente WinGet neste tópico.

AppContainer ou Medium IL

A opção de executar a sua aplicação num AppContainer, ou não, é uma questão de segurança. O processo de uma aplicação AppContainer e os seus processos filhos executam-se dentro de um contentor de aplicação leve, onde podem aceder apenas aos recursos que lhes são especificamente atribuídos. E são isolados através da virtualização do sistema de arquivos e do registro. Como resultado, os aplicativos implementados em um AppContainer não podem ser hackeados para permitir ações maliciosas fora dos recursos atribuídos limitados.

Aplicações empacotadas ou não empacotadas podem ser configuradas para correr num AppContainer. Mas o processo é mais simples para aplicações empacotadas. Se uma app não for AppContainer, então é uma app Medium IL .

Para mais informações, consulte AppContainer para aplicações legadas e aplicações MSIX AppContainer.

Para informações sobre como configurar a sua aplicação para correr num AppContainer ou Medium IL:

  • Aplicações WinUI (SDK de Aplicações Windows). Veja o atributo de manifesto do pacote do aplicativo uap10:TrustLevel em Configurar um projeto WinUI para AppContainer.
  • Aplicações de ambiente de trabalho. Consulte a propriedade TrustLevel do projeto do Visual Studio em aplicações MSIX AppContainer (na secção apropriada para o seu tipo de aplicação).
  • Aplicações da Plataforma Universal Windows (UWP). As aplicações UWP já estão configuradas para correr num AppContainer; E essa configuração não pode ser alterada.

Lembra-te que as apps não embaladas não têm manifesto de pacote de app. Assim, para aplicações não empacotadas, declara-se a sua decisão de AppContainer-or-Medium-IL no ficheiro de projeto em vez de num manifesto de pacote de aplicação.

Isolamento de aplicações Win32

O isolamento de aplicações Win32 é uma funcionalidade de segurança (disponível no Windows 11, versão 24H2 e posteriores) que ajuda a conter danos caso uma aplicação seja comprometida e protege as escolhas de privacidade dos utilizadores. Baseia-se em AppContainers e componentes que virtualizam recursos e fornecem acesso intermediado. Para mais informações, consulte Visão geral do isolamento de aplicações Win32 e o repositório do GitHub sobre o isolamento de aplicações Win32.

Capacidades da aplicação

As capacidades das aplicações (por exemplo, internetClient, localização, microfone e bluetooth) são principalmente relevantes para aplicações empacotadas que correm num AppContainer. Isso inclui aplicações all Plataforma Universal do Windows (UWP) e aplicações algumas para desktop.

Mas há alguns cenários em que até uma aplicação Medium IL (ou seja, não uma app AppContainer) deveria declarar uma capacidade. Um exemplo é a runFullTrust capacidade restrita.

Para mais detalhes sobre as capacidades das aplicações, a que tipos de aplicações se aplicam e como as configurar, consulte Declarações de capacidades da aplicação. Configura capacidades no manifesto do pacote da sua aplicação; e é por isso que se aplicam apenas a aplicações em pacotes.

Tipos de aplicações

As aplicações de ambiente de trabalho e as aplicações Plataforma Universal do Windows (UWP) são os dois principais tipos de aplicações, embora existam vários tipos de aplicações na família de aplicações de ambiente de trabalho. Escolher uma framework de UI (WinForms, WPF, Win32, Direct 2D/3D ou WinUI 3) é, em certa medida, independente das configurações descritas neste tópico.

Mas vamos analisar como esses tipos de aplicações podem diferir entre si em termos de embalagem, implementação e processo.

Antes de mais, todas as aplicações UWP são embaladas e executadas num AppContainer. Mas para aplicações de desktop, as coisas são mais flexíveis. Pode escolher incluir a sua aplicação de ambiente de trabalho ou não. E, independentemente dessa decisão, pode optar por configurar a sua aplicação de ambiente de trabalho como uma AppContainer ou uma aplicação Medium IL.

Embalado Unpackaged
AppContainer Aplicações de ambiente de trabalho
Aplicativos UWP		 Aplicações de ambiente de trabalho
IL Médio Aplicações de ambiente de trabalho Aplicações de ambiente de trabalho

Para aplicações empacotadas, para configurar o tipo de aplicação que pretende, utiliza o atributo uap10:RuntimeBehavior no manifesto do pacote da sua aplicação (ver Application (Windows 10)).

  • As aplicações de ambiente de trabalho são Windows .exe, normalmente com uma função de entrada principal ou WinMain. Para configurar a sua aplicação como uma aplicação de ambiente de trabalho, defina uap10:RuntimeBehavior para "packagedClassicApp" ou "win32App".
    • O valor "packagedClassicApp" indica uma das seguintes opções: uma aplicação WinUI (SDK de Aplicações Windows) ou uma aplicação Desktop Bridge (Centennial). A diferença é que uma aplicação Centennial corre num AppContainer.
    • E "win32App" indica qualquer outro tipo de aplicação Win32 (incluindo uma aplicação com localização externa).
  • Por fim, definir uap10:RuntimeBehavior para "windowsApp" dá-te uma aplicação UWP.

Para todas as opções de tipos de aplicações que pode desenvolver, veja Windows app desenvolvimento: opções e funcionalidades.

SDK de Aplicações Windows: dependente do framework ou autónomo

Se estiveres a desenvolver ou manter uma aplicação que utiliza o SDK de Aplicações Windows, então tens uma decisão adicional a tomar. Porque existem as seguintes duas formas de implementar o SDK de Aplicações Windows do qual a sua aplicação depende:

  • Dependente do framework (o padrão). A tua aplicação precisa que o runtime do SDK de Aplicações Windows e/ou o pacote Framework estejam presentes na máquina alvo.
  • Autossuficiente. A sua aplicação traz consigo as suas dependências do SDK de Aplicações Windows.

Para mais informações, consulte SDK de Aplicações Windows Deployment Overview.

Windows Gestor de Pacotes e o cliente WinGet

Um package manager pode ajudar os seus utilizadores a instalar/atualizar/configurar o seu software automatizando o fluxo de trabalho. Os gestores de pacotes podem ajudar a instalar qualquer software, mas tendem a ser usados principalmente para instalar developer tools. Por isso, se está a desenvolver uma ferramenta para programadores, poderá estar particularmente interessado nesta opção. Mas é assim que funciona:

  • Você, enquanto programador de software, define à package manager (sob a forma de instruções declarativas) todas as peças necessárias para uma instalação bem-sucedida do seu produto.
  • E depois, quando um utilizador instala o seu software, o package manager segue as instruções declarativas para automatizar o fluxo de trabalho de instalação e configuração.

O resultado é uma redução do tempo gasto a preparar o ambiente do utilizador e uma melhor compatibilidade entre os componentes instalados. E pode usar o Windows Gestor de Pacotes para distribuir as suas aplicações embaladas ou não embaladas em formatos como .msix, .msi e .exe.

Para mais informações, consulte Windows Gestor de Pacotes.

  • Last updated on