Compreender como as aplicações de ambiente de trabalho em pacote são executadas no Windows

Este tópico descreve os tipos de aplicativos da área de trabalho para os quais você pode criar um pacote de aplicativo do Windows, juntamente com alguns comportamentos do sistema operacional (SO) e outros aspetos específicos que é importante estar ciente. Entraremos em detalhes dos seguintes itens (como veremos, o comportamento específico depende do tipo do seu aplicativo):

• O local de instalação e o diretório de trabalho do seu aplicativo (que podem ser diferentes do que seu aplicativo assumiu no passado).
• O sistema de arquivos do sistema operacional e o comportamento do registro .
• Desinstalação.

Tipos de aplicação de ambiente de trabalho

Há dois tipos de aplicativo de área de trabalho que você pode criar e empacotar. Você declara o tipo do seu aplicativo no manifesto do pacote do aplicativo usando o atributo uap10:RuntimeBehavior do elemento Application :

• Um tipo inclui aplicativos WinUI 3 (que usam o SDK de Aplicativo Windows) e aplicativos Desktop Bridge (Centennial). Declarado com uap10:RuntimeBehavior="packagedClassicApp".
• O outro tipo representa outros tipos de aplicativo Win32, incluindo aplicativos empacotados com localização externa. Declarado com uap10:RuntimeBehavior="win32App".

Os aplicativos da Plataforma Universal do Windows (uap10:RuntimeBehavior="windowsApp"UWP) também são empacotados, mas este tópico não é sobre eles.

E, em seguida, o atributo uap10:TrustLevel (do mesmo elemento Application ) determina se o processo do aplicativo empacotado é ou não executado dentro de um contêiner de aplicativo.

• Um aplicativo de confiança total . Declarado com uap10:TrustLevel="mediumIL".
• Um aplicativo appContainer . Declarado com uap10:TrustLevel="appContainer". Funciona dentro de um contentor de aplicação leve. Para obter mais informações, consulte Aplicativos MSIX appContainer.

A finalidade do empacotamento e dos contêineres de aplicativos

O objetivo de empacotar seu aplicativo é conceder-lhe identidade de pacote em tempo de execução. A identidade do pacote é necessária para determinados recursos do Windows (consulte Recursos que exigem identidade do pacote). Você pode empacotar todas as combinações de tipos de aplicativos descritas acima (e, assim, se beneficiar da identidade do pacote).

Mas um objetivo principal de um aplicativo appContainer é separar o estado do aplicativo do estado do sistema tanto quanto possível, mantendo a compatibilidade com outros aplicativos. O Windows faz isso detetando e redirecionando certas alterações que faz no sistema de arquivos e no registro em tempo de execução (conhecido como virtualização). Sinalizaremos quando uma seção se aplicar apenas a aplicações virtualizadas.

Instalação

Os pacotes de aplicativos são instalados por usuário, em vez de em todo o sistema. O local padrão para novos pacotes em uma nova máquina está em C:\Program Files\WindowsApps\<package_full_name>, com o executável chamado app_name.exe. Mas os pacotes podem ser instalados em outros locais; por exemplo, os comandos Start do Visual Studio utilizam o $(OutDir) do projeto.

Após a implantação, os arquivos de pacote são marcados como somente leitura e são fortemente bloqueados pelo sistema operacional (SO). O Windows impede que os aplicativos sejam iniciados se esses arquivos forem violados.

O C:\Program Files\WindowsApps local é conhecido como PackageVolume. Esse local é o PackageVolume padrão com o qual o Windows é fornecido; mas você pode criar um PackageVolume em qualquer unidade e em qualquer caminho. Além disso, nem todos os pacotes são instalados em um PackageVolume (consulte o exemplo do Visual Studio acima).

Sistema de ficheiros

O SO suporta diferentes níveis de operações do sistema de ficheiros para aplicações de ambiente de trabalho embaladas, dependendo da localização da pasta.

Otimizado para o seu dispositivo

A fim de evitar a duplicação de arquivos (para otimizar o espaço de armazenamento em disco e reduzir a largura de banda necessária ao baixar arquivos), o sistema operacional aproveita o armazenamento único e a vinculação rígida de arquivos. Quando um usuário baixa um pacote MSIX, o AppxManifest.xml é usado para determinar se os dados contidos com o pacote já existem no disco de uma instalação de pacote anterior. Se o mesmo arquivo existir em vários pacotes MSIX, o sistema operacional armazenará o arquivo compartilhado no disco apenas uma vez e criará links físicos de ambos os pacotes para o arquivo compartilhado. Como os arquivos são baixados em blocos de 64Kb, mesmo que uma porcentagem de um arquivo que está sendo baixado exista no disco, apenas o incremento diferente é baixado. Isso reduz a largura de banda usada para download.

Operações AppData no Windows 10, versão 1903 e posterior

Esta secção aplica-se apenas a aplicações virtualizadas.

Todos os ficheiros e pastas recém-criados na pasta do AppData utilizador (por exemplo, C:\Users\<user_name>\AppData) são armazenados num local privado e exclusivo a cada utilizador e aplicação, mas mesclados em tempo de execução para aparecer no local real AppData. Isso permite algum grau de separação de estado para artefatos que são usados apenas pelo próprio aplicativo; que permite que o sistema limpe esses arquivos quando o aplicativo é desinstalado.

Modificações em arquivos existentes na pasta do usuário são permitidas AppData para fornecer um maior grau de compatibilidade e interatividade entre aplicativos e o sistema operacional. Isso reduz o "apodrecimento" do sistema porque o sistema operacional está ciente de cada alteração de arquivo ou diretório feita por um aplicativo. A separação de estados também permite que os aplicativos de desktop empacotados continuem de onde uma versão não empacotada do mesmo aplicativo parou. Observe que o sistema operacional não suporta uma pasta VFS (sistema de arquivos virtual) para a pasta do AppData usuário.

Operações AppData em sistemas operacionais anteriores ao Windows 10, versão 1903

Esta secção aplica-se apenas a aplicações virtualizadas.

Todas as gravações na pasta do AppData utilizador (por exemplo, C:\Users\<user_name>\AppData) — incluindo a criação, eliminação e atualização — são copiadas ao serem escritas para um local privado, por utilizador e por aplicação. Isso cria a ilusão de que o aplicativo embalado está a editar o AppData real, quando na realidade está a modificar uma cópia privada. Ao redirecionar as gravações dessa forma, o sistema pode controlar todas as modificações de arquivos feitas pelo aplicativo. Isso permite que o sistema limpe esses arquivos quando o aplicativo é desinstalado, reduzindo assim o "podridão" do sistema e fornecendo uma melhor experiência de remoção do aplicativo para o usuário.

Diretório de trabalho e arquivos de aplicativo

Esta secção aplica-se apenas a aplicações virtualizadas.

Além de redirecionar AppData, as pastas conhecidas do Windows (System32, Program Files (x86), etc.) são mescladas dinamicamente com os diretórios correspondentes no pacote do aplicativo. Cada pacote contém uma pasta nomeada VFS em sua raiz. Todas as leituras de diretórios ou arquivos no VFS diretório são mescladas em tempo de execução com suas respetivas contrapartes nativas. Por exemplo, um aplicativo pode conter C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll como parte de seu pacote de aplicativo, mas o arquivo parece estar instalado em C:\Windows\System32\vc10.dll. Isso mantém a compatibilidade com aplicações de ambiente de trabalho que esperam que os ficheiros estejam em locais fora de pacotes.

Não são permitidas escritas em ficheiros/pastas no pacote da aplicação. As gravações em arquivos e pastas que não fazem parte do pacote são ignoradas pelo sistema operacional e são permitidas desde que o usuário tenha permissão.

Operações comuns do sistema de arquivos

Esta breve tabela de referência mostra as operações comuns do sistema de arquivos e como o sistema operacional as manipula.

Locais VFS empacotados

Esta secção aplica-se apenas a aplicações virtualizadas.

Esta tabela mostra onde os arquivos enviados como parte do seu pacote são sobrepostos no sistema para o aplicativo. O seu aplicativo perceberá que esses arquivos estão nos locais do sistema listados quando, na verdade, estão nos locais redirecionados dentro do C:\Program Files\WindowsApps\<package_full_name>\VFS. Os locais FOLDERID são das constantes KNOWNFOLDERID .

Registo

Esta seção (e suas subseções) se aplica apenas a aplicativos virtualizados.

Os pacotes de aplicativos contêm um registry.dat arquivo, que serve como o equivalente lógico (virtual) de HKLM\Software no registro real. Em tempo de execução, o registo virtual mescla o conteúdo dessa colmeia na colmeia nativa do sistema para fornecer um único ponto de vista de ambas. Por exemplo, se registry.dat contiver uma única tecla Foo, então uma leitura de HKLM\Software em tempo de execução também parecerá conter Foo (além de todas as chaves nativas do sistema).

Embora os pacotes MSIX incluam chaves HKLM e HKCU , eles são tratados de forma diferente. Apenas as chaves em HKLM\Software fazem parte do pacote; chaves em HKCU ou outras partes do registro não são. Não são permitidas gravações em chaves ou valores no pacote. Gravações em chaves ou valores que não fazem parte do pacote são permitidas, desde que o usuário tenha permissão.

Todas as gravações em HKCU são copiadas durante a gravação para um local privado por utilizador e por aplicação. Tradicionalmente, os desinstaladores não conseguem limpar HKEY_CURRENT_USER porque os dados do Registro para usuários desconectados estão desmontados e indisponíveis.

Todas as gravações são mantidas durante a atualização do pacote e excluídas somente quando o aplicativo é totalmente removido.

Operações de registo comuns

A maior parte desta seção se aplica apenas a aplicativos virtualizados.

Esta breve tabela de referência mostra operações de registo comuns e como o SO as trata.

Desinstalação

Esta secção aplica-se apenas a aplicações virtualizadas.

Quando um pacote é desinstalado pelo utilizador, todos os arquivos e pastas localizados em C:\Program Files\WindowsApps\<package_full_name> são removidos, bem como quaisquer gravações redirecionadas para AppData ou o registo, capturadas durante o processo de empacotamento.