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.
Este tópico descreve os tipos de aplicativos da área de trabalho para os quais você pode criar um pacote de aplicativos do Windows, juntamente com alguns comportamentos do sistema operacional (SO) e outros aspectos específicos dos quais é importante estar ciente. Entraremos em detalhes dos seguintes itens (como veremos, o comportamento específico depende do tipo de seu aplicativo):
- O local de instalação do aplicativo e o diretório de trabalho (que pode ser diferente do que seu aplicativo assumiu no passado).
- O comportamento do sistema de arquivos e do registro do sistema operacional.
- Desinstalação.
Tipos de programa de área de trabalho
Há dois tipos de aplicativos de desktop que você pode criar e empacotar. Você declara o tipo do 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 do Windows) e aplicativos Bridge para Desktop (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".
Aplicativos da Plataforma Universal do Windows (UWP) uap10:RuntimeBehavior="windowsApp" também são empacotados, mas este tópico não trata deles.
Em seguida, o atributo uap10:TrustLevel (do mesmo elemento Application ) determina se o processo do aplicativo empacotado é executado dentro de um contêiner de aplicativo ou não.
- Um aplicativo de confiança total . Declarado com
uap10:TrustLevel="mediumIL". - Um aplicativo appContainer . Declarado com
uap10:TrustLevel="appContainer". É executado em um contêiner de aplicativo leve (e, portanto, é isolado usando o sistema de arquivos virtualizado e a virtualização do registro). Para obter mais informações, consulte aplicativos MSIX appContainer.
Importante
Para obter mais detalhes, dependências e requisitos de funcionalidade, consulte a documentação desses dois atributos no Aplicativo. Veja também uap10 foi introduzido no Windows 10, versão 2004 (10.0; Build 19041).
A finalidade do empacotamento e dos contêineres de aplicativo
A finalidade de empacotar seu aplicativo é conceder a ele a identidade do pacote em runtime. A identidade do pacote é necessária para determinados recursos do Windows (consulte Recursos que exigem a identidade do pacote). Você pode empacotar todas as combinações de tipos de aplicativo descritos acima (e, assim, se beneficiar da identidade do pacote).
Mas um objetivo fundamental de um aplicativo appContainer é separar o estado do aplicativo do estado do sistema o máximo possível, mantendo a compatibilidade com outros aplicativos. O Windows faz isso detectando e redirecionando determinadas alterações feitas ao sistema de arquivos e ao registro em runtime (conhecido como virtualizando). Indicaremos quando uma seção se aplicar somente a apps virtualizados.
Instalação
Os pacotes de aplicativos são instalados por usuário em vez de todo o sistema. O local padrão para novos pacotes em um novo computador está sob 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 Iniciar do Visual Studio usam o projeto.$(OutDir)
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 adulterados.
A localização C:\Program Files\WindowsApps é conhecida como PackageVolume. Esse local é o PackageVolume padrão que vem com o Windows, 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 arquivos
O sistema operacional dá suporte a diferentes níveis de operações do sistema de arquivos para aplicativos de área de trabalho empacotados, dependendo do local da pasta.
Otimizado para seu dispositivo
Para 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 de arquivos. Quando um usuário baixa um pacote MSIX, ele AppxManifest.xml é usado para determinar se os dados contidos no 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 apenas uma vez no disco e criará links rígidos de ambos os pacotes para o arquivo compartilhado. Como os arquivos são baixados em blocos de 64 KB, mesmo que uma porcentagem de um arquivo que esteja sendo baixado exista no disco, somente o incremento diferente será baixado. Isso reduz a largura de banda usada para download.
Operações do AppData no Windows 10, versão 1903 e posterior
Esta seção se aplica somente a aplicativos virtualizados.
Todos os arquivos e pastas recém-criados na pasta AppData do usuário (por exemplo, C:\Users\<user_name>\AppData) são gravados em um local privado por usuário, por aplicativo, mas são 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.
As modificações em arquivos existentes na pasta do AppData usuário são permitidas para fornecer um maior grau de compatibilidade e interatividade entre aplicativos e o sistema operacional. Isso reduz a "podridão" 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 área de trabalho empacotados continuem de onde uma versão não empacotada do mesmo aplicativo parou. Observe que o sistema operacional não dá suporte a uma pasta do VFS (sistema de arquivos virtual) para a pasta do AppData usuário.
Operações do AppData em OSes anteriores ao Windows 10, versão 1903
Esta seção se aplica somente a aplicativos virtualizados.
Todas as gravações na pasta AppData do usuário (por exemplo, C:\Users\<user_name>\AppData)-incluindo criação, exclusão e atualização, são copiadas na gravação para um local privado por usuário e por aplicativo. Isso cria a ilusão de que o aplicativo empacotado está editando o AppData real quando, na verdade, está alterando uma cópia privada. Ao redirecionar gravações dessa forma, o sistema pode acompanhar todas as modificações de arquivo feitas pelo aplicativo. Isso permite que o sistema limpe esses arquivos quando o aplicativo for desinstalado, reduzindo assim a "podridão" do sistema e fornecendo uma melhor experiência de remoção de aplicativo para o usuário.
Diretório de trabalho e arquivos de aplicativo
Esta seção se aplica somente a aplicativos virtualizados.
Além de redirecionar AppData, as pastas conhecidas do Windows (System32, Program Files (x86), etc.) são mescladas dinamicamente com diretórios correspondentes no pacote do aplicativo. Cada pacote contém uma pasta nomeada VFS em sua raiz. As leituras de diretórios ou arquivos no diretório VFS são mescladas em tempo de execução com seus respectivos equivalentes nativos. Por exemplo, um aplicativo pode conter C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll como parte de seu pacote de aplicativos, mas o arquivo parece estar instalado em C:\Windows\System32\vc10.dll. Isso mantém a compatibilidade com aplicativos de desktop que esperam que os arquivos estejam em locais fora de pacotes.
Gravações em arquivos/pastas no pacote do aplicativo não são permitidas. 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.
| Operação | Resultado | Exemplo |
|---|---|---|
| Ler ou enumerar um arquivo ou pasta conhecido do Windows | Uma mesclagem dinâmica de C:\Program Files\<package_full_name>\VFS\<well_known_folder> com o equivalente no sistema local. |
Ler C:\Windows\System32 retorna o conteúdo de C:\Windows\System32 mais o conteúdo de C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86. |
Gravar em AppData |
Windows 10, versão 1903 e posterior: Novos arquivos e pastas criados nos seguintes diretórios são redirecionados para um local privado por usuário, por pacote:
AppData . Se o arquivo for aberto do local real AppData , nenhuma virtualização para esse arquivo ocorrerá. A exclusão de arquivos sob AppData é permitida se o usuário tiver permissões.Windows 10 versão 1903 e anteriores: cópia em gravação para um local por usuário e por aplicativo. |
AppData é normalmente C:\Users\<user_name>\AppData. |
| Gravar dentro do pacote | Não permitido. O pacote é somente leitura. | Não é permitido gravações sob C:\Program Files\WindowsApps\<package_full_name>. |
| Escrever fora da embalagem | Permitido se o usuário tiver permissões. | Uma gravação para C:\Windows\System32\foo.dll é permitida se o pacote não contiver C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll, e o usuário tiver permissões. |
Locais empacotados do VFS
Esta seção se aplica somente a aplicativos virtualizados.
Esta tabela mostra onde os arquivos enviados como parte do pacote são sobrepostos no sistema para o aplicativo. Seu aplicativo perceberá que esses arquivos estão nos locais do sistema listados quando, na verdade, eles estão nos locais redirecionados dentro C:\Program Files\WindowsApps\<package_full_name>\VFS. Os locais FOLDERID são provenientes das constantes KNOWNFOLDERID.
| Localização do sistema | Local redirecionado (em [<package_root>]\VFS) | Válido em arquiteturas |
|---|---|---|
| FOLDERID_SystemX86 | SystemX86 |
x86, amd64 |
| FOLDERID_System | SystemX64 |
amd64 |
| FOLDERID_ProgramFilesX86 | ProgramFilesX86 |
x86, amd6 |
| FOLDERID_ProgramFilesX64 | ProgramFilesX64 |
amd64 |
| FOLDERID_ProgramFilesCommonX86 | ProgramFilesCommonX86 |
x86, amd64 |
| FOLDERID_ProgramFilesCommonX64 | ProgramFilesCommonX64 |
amd64 |
| FOLDERID_Windows | Windows |
x86, amd64 |
| FOLDERID_ProgramData |
AppData comum |
x86, amd64 |
| FOLDERID_System\catroot | AppVSystem32Catroot |
x86, amd64 |
| FOLDERID_System\catroot2 | AppVSystem32Catroot2 |
x86, amd64 |
| FOLDERID_System\drivers\etc. | AppVSystem32DriversEtc |
x86, amd64 |
| FOLDERID_System\driverstore | AppVSystem32Driverstore |
x86, amd64 |
| FOLDERID_System\logfiles | AppVSystem32Logfiles |
x86, amd64 |
| FOLDERID_System\spool | AppVSystem32Spool |
x86, amd64 |
Registro
Esta seção (e suas subsseções) se aplica somente 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 runtime, o registro virtual mescla o conteúdo desse hive no hive do sistema nativo para fornecer uma única exibição de ambos. Por exemplo, se registry.dat contiver uma única chave Foo, uma leitura de HKLM\Software em runtime também aparecerá para conter Foo (além de todas as chaves do sistema nativo).
Embora os pacotes MSIX incluam chaves HKLM e HKCU , eles são tratados de forma diferente. Somente as chaves em HKLM\Software fazem parte do pacote; as chaves em HKCU ou em outras partes do registro não são. As gravações em chaves ou valores no pacote não são permitidas. 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 no HKCU são copiadas na gravação para um local privado por usuário, por aplicativo. 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 comuns do Registro
A maior parte desta seção se aplica somente a aplicativos virtualizados.
Esta breve tabela de referência mostra as operações comuns do Registro e como o sistema operacional as manipula.
| Operação | Resultado | Exemplo |
|---|---|---|
| Ler ou enumerar HKLM\Software | Uma mesclagem dinâmica do hive de pacote com o equivalente do sistema local. | Se registry.dat contiver uma única chave Foo, em runtime, uma leitura de HKLM\Software mostrará o conteúdo de HKLM\Software e HKLM\Software\Foo. |
| Gravações em HKCU | Copiado na gravação para um local privado por usuário por aplicativo. | O mesmo que AppData para arquivos. |
| Grava dentro do pacote. | Não permitido. O pacote é somente leitura. | As gravações em HKLM\Software não serão permitidas se houver uma chave/valor correspondente no hive do pacote. |
| Gravações fora do pacote | Ignorado pelo sistema operacional. Permitido se o usuário tiver permissões. | As gravações em HKLM\Software são permitidas desde que uma chave/valor correspondente não exista no hive do pacote e o usuário tenha as permissões de acesso corretas. |
Desinstalação
Esta seção se aplica somente a aplicativos virtualizados.
Quando um pacote é desinstalado pelo usuário, todos os arquivos e pastas localizados em C:\Program Files\WindowsApps\<package_full_name> são removidos, bem como qualquer gravação redirecionada para AppData ou para o registro que foi capturada durante o processo de empacotamento.