Preparar para empacotar um aplicativo de desktop

Este artigo lista as coisas que você precisa considerar antes de empacotar seu aplicativo desktop. Talvez você não precise fazer muito para preparar seu aplicativo para o processo de empacotamento, mas se qualquer um dos itens abaixo se aplicar ao seu aplicativo, precisará resolvê-lo antes do empacotamento.

• Seu aplicativo .NET requer uma versão do .NET Framework anterior à 4.6.2. Se você estiver empacotando um aplicativo .NET, recomendamos que seu aplicativo tenha como destino o .NET Framework 4.6.2 ou posterior. A capacidade de instalar e executar aplicativos de área de trabalho empacotados foi introduzida pela primeira vez no Windows 10, versão 1607 (também chamada de Atualização de Aniversário), e essa versão do sistema operacional inclui o .NET Framework 4.6.2 por padrão. Versões posteriores do sistema operacional incluem versões posteriores do .NET Framework. Para obter uma lista completa de quais versões do .NET estão incluídas em versões posteriores do Windows 10, consulte este artigo.

  Espera-se que direcionar versões do .NET Framework anteriores a 4.6.2 em aplicações desktop empacotadas funcione na maioria dos casos. No entanto, se você escolher uma versão anterior à 4.6.2 como destino, deverá testá-la por completo no aplicativo da área de trabalho empacotado antes da distribuição para os usuários.

  • 4.0 – 4.6.1: os aplicativos destinados a essas versões do .NET Framework devem ser executados sem problemas na 4.6.2 ou posterior. Portanto, esses aplicativos devem instalar e executar sem alterações no Windows 10, versão 1607 ou posterior com a versão do .NET Framework incluída no sistema operacional.

  • 2.0 e 3.5: em nossos testes, os aplicativos de área de trabalho empacotados destinados a essas versões do .NET Framework geralmente funcionam, mas podem apresentar problemas de desempenho em alguns cenários. Para que esses aplicativos empacotados sejam instalados e executados, o recurso .NET Framework 3.5 deve ser instalado no computador de destino (esse recurso também inclui o .NET Framework 2.0 e 3.0). Você também deve testar esses aplicativos completamente depois de empacotá-los.

• Seu aplicativo sempre é executado com privilégios de segurança elevados. Seu aplicativo precisa funcionar enquanto estiver sendo executado como o usuário interativo. Os usuários que instalam seu aplicativo podem não ser administradores do sistema, portanto, exigir que seu aplicativo seja executado com privilégios elevados significa que ele não será executado corretamente para usuários padrão. Se você planeja publicar seu aplicativo na Microsoft Store, os aplicativos que exigem elevação para qualquer parte da funcionalidade não serão aceitos na Loja.

• Seu aplicativo requer um driver do Windows. O MSIX não dá suporte a drivers do Windows.

• Seu aplicativo requer um serviço windows de usuário. O MSIX não dá suporte a serviços windows por usuário. O MSIX dá suporte a serviços de sessão 0 (por computador) em execução em uma das contas de sistema definidas (LocalSystem, LocalService ou NetworkService). Em vez de um serviço windows de usuário, use uma tarefa em segundo plano.

• Os módulos do seu aplicativo são carregados em execução para processos que não fazem parte do pacote de aplicativos do Windows. Isso não é permitido, o que significa que extensões em processo, como extensões de shell, não têm suporte. No entanto, se você tiver dois aplicativos no mesmo pacote, poderá realizar a comunicação entre processos entre eles.

• Verifique se todas as extensões instaladas pelo aplicativo serão instaladas onde o aplicativo está instalado. O Windows permite que usuários e gerentes de TI alterem o local de instalação padrão para pacotes. Consulte "Configurações->Sistema->Armazenamento->Mais configurações de armazenamento-> Alterar onde o novo conteúdo deve ser salvo-> Novos aplicativos serão salvos em". Se você estiver instalando uma extensão com seu aplicativo, verifique se a extensão não tem restrições adicionais de pasta de instalação. Por exemplo, algumas extensões podem desabilitar a instalação de sua extensão em unidades que não são do sistema. Isso resultará em um erro 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) caso a localização padrão tenha sido alterada.

• Seu aplicativo usa uma AUMID (ID do Modelo de Usuário do Aplicativo) personalizada. Se o processo chamar SetCurrentProcessExplicitAppUserModelID para definir seu próprio AUMID, ele poderá usar apenas o AUMID gerado para ele pelo ambiente do modelo de aplicativo/pacote de aplicativos do Windows. Você não pode estabelecer AUMIDs personalizadas.

• Seu aplicativo modifica o hive do Registro HKEY_LOCAL_MACHINE (HKLM). Qualquer tentativa do aplicativo de criar uma chave HKLM ou abrir uma para modificação resultará em uma falha por acesso negado. Lembre-se de que o seu aplicativo tem uma exibição virtualizada própria privada do Registro, portanto, a noção de um hive do Registro no âmbito do usuário e do computador (que é do que se trata o HKLM) não se aplica. Você precisará encontrar outra maneira de fazer o que o HKLM faz, como, por exemplo, fazer a gravação em HKEY_CURRENT_USER (HKCU).

• Seu aplicativo usa uma subchave de registro ddeexec como um meio de iniciar outro aplicativo. Em vez disso, use um dos manipuladores de verbo DelegateExecute conforme configurado pelas várias extensões Activatable* no manifesto do pacote do aplicativo.

• Seu aplicativo grava na pasta AppData ou no registro com a intenção de compartilhar dados com outro aplicativo. Após a conversão, AppData é redirecionado para o repositório de dados do aplicativo local, que é um repositório privado para cada aplicativo.

  Todas as entradas que seu aplicativo grava no hive do registro HKEY_LOCAL_MACHINE são redirecionadas para um arquivo binário isolado e todas as entradas que seu aplicativo grava no hive do registro HKEY_CURRENT_USER são colocadas em um local privado por usuário por aplicativo. Para obter mais detalhes sobre o redirecionamento de arquivos e registros, consulte Bastidores do Desktop Bridge.

  Use um meio diferente de compartilhamento de dados entre processos. Para obter mais informações, consulte Armazenar e recuperar configurações e outros dados do aplicativo.

• O aplicativo faz a gravação no diretório de instalação do aplicativo. Por exemplo, seu aplicativo grava em um arquivo de log que você coloca no mesmo diretório que seu exe. Não há suporte para isso, portanto, você precisará encontrar outro local, como o repositório de dados do aplicativo local.

• Seu aplicativo usa o diretório de trabalho atual. Em runtime, o aplicativo da área de trabalho empacotado não terá o mesmo diretório de trabalho especificado anteriormente no atalho .LNK da área de trabalho. Você precisa alterar seu CWD em runtime se ter o diretório correto é importante para que seu aplicativo funcione corretamente.

  Observação

  Caso o aplicativo precise ser gravado no diretório de instalação ou usar o diretório de trabalho atual, considere também a possibilidade de adicionar uma correção de runtime usando o Package Support Framework do pacote. Para obter mais detalhes, confira este artigo.

• A instalação do aplicativo requer interação do usuário. O instalador do aplicativo deve ser capaz de ser executado silenciosamente e deve instalar todos os seus pré-requisitos que não estão ativados por padrão em uma imagem limpa do sistema operacional.

• Seu aplicativo expõe objetos COM. Processos e extensões de dentro do pacote podem registrar e usar servidores COM &OLE, tanto em processo quanto fora de processo (OOP). A Atualização para Criadores adiciona o suporte ao COM empacotado, o que oferece a capacidade de registrar servidores OOP COM e OLE que já ficam visíveis fora do pacote. Veja Suporte ao servidor COM e ao documento do OLE para a Ponte de Desktop.

  O suporte ao COM empacotado funciona com APIs COM existentes, mas não funcionará para extensões de aplicativo que dependem da leitura direta do registro, já que o local do COM empacotado está em um local privado.

• Seu aplicativo expõe assemblies GAC para uso por outros processos. Seu aplicativo não pode expor assemblies GAC para uso por processos originados de executáveis externos ao pacote de aplicativos do Windows. Os processos de dentro do pacote podem registrar e usar assemblies GAC normalmente, mas não ficarão visíveis externamente. Isso significa que cenários de interoperabilidade como o OLE não funcionarão se invocados por processos externos.

• Seu aplicativo está vinculando CRT (bibliotecas de runtime C) de maneira sem suporte. A biblioteca de runtime do Microsoft C/C++ fornece rotinas para programação para o sistema operacional Microsoft Windows. Essas rotinas automatizam muitas tarefas de programação comuns que não são fornecidas pelas linguagens C e C++. Se o aplicativo utilizar a biblioteca de runtime do C/C++, você precisará garantir que ela esteja vinculada de maneira compatível.

  O Visual Studio 2017 dá suporte à vinculação estática e dinâmica, para permitir que seu código use arquivos DLL comuns ou vinculação estática, para vincular a biblioteca diretamente ao seu código, à versão atual do CRT. Se possível, recomendamos que seu aplicativo use a vinculação dinâmica com o VS 2017.

  O suporte em versões anteriores do Visual Studio varia. Para obter detalhes, consulte a tabela a seguir:

  Versão do Visual Studio	Vinculação dinâmica	Vinculação estática
  2005 (VC 8)	Sem suporte	Suportado
  2008 (VC 9)	Sem suporte	Suportado
  2010 (VC 10)	Suportado	Suportado
  2012 (VC 11)	Suportado	Sem suporte
  2013 (VC 12)	Suportado	Sem suporte
  2015 e 2017 (VC 14)	Suportado	Suportado

  Observação: em todos os casos, você precisa vincular à última CRT publicamente disponível.

• Seu aplicativo instala e carrega os assemblies da pasta lado a lado do Windows. Por exemplo, seu aplicativo usa bibliotecas de runtime C VC8 ou VC9 e as vincula dinamicamente da pasta lado a lado do Windows, o que significa que seu código está usando os arquivos DLL comuns de uma pasta compartilhada. Isso não tem suporte. Você precisará vinculá-los estaticamente vinculando-os aos arquivos de biblioteca redistribuíveis diretamente em seu código.

• Seu aplicativo usa uma dependência na pasta System32/SysWOW64. Para que essas DLLs funcionem, você deve incluí-las na parte do sistema de arquivos virtual do pacote de aplicativos do Windows. Isso garante que o aplicativo se comporte como se as DLLs fossem instaladas na pasta System32/SysWOW64 . Na raiz do pacote, crie uma pasta chamada VFS. Dentro dessa pasta, crie uma pasta SystemX64 e SystemX86 . Em seguida, coloque a versão de 32 bits da DLL na pasta SystemX86 e coloque a versão de 64 bits na pasta SystemX64 .

• Seu aplicativo usa um pacote de estrutura VCLibs. Se você estiver convertendo um aplicativo C++ Win32, deverá lidar com a implantação do Runtime do Visual C++. O Visual Studio 2019 e o SDK do Windows incluem os pacotes de estrutura mais recentes para as versões 11.0, 12.0 e 14.0 do Runtime do Visual C++ nas seguintes pastas:

  • Pacotes de framework VC 14.0: C:\Arquivos de Programas (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • Pacotes de estrutura vc 12.0: C:\Arquivos de Programas (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

  • Pacotes de estrutura vc 11.0: C:\Arquivos de Programas (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

  Para usar um desses pacotes, você deve referenciar o pacote como uma dependência no manifesto do pacote. Quando os clientes instalam a versão de varejo do seu aplicativo da Microsoft Store, o pacote será instalado na Loja junto com seu aplicativo. As dependências não serão instaladas se você fizer o sideload do aplicativo. Para instalar as dependências manualmente, você deve instalar o pacote de estrutura apropriado usando o pacote de .appx apropriado para x86, x64 ou ARM localizado nas pastas de instalação listadas acima.

  Para fazer referência a um pacote de estrutura do Runtime do Visual C++ em seu aplicativo:

  1. Vá para a pasta de instalação do pacote da estrutura listada acima para a versão do Runtime do Visual C++ usada pelo seu aplicativo.

  2. Abra o arquivo SDKManifest.xml nessa pasta, localize o atributo FrameworkIdentity-Debug ou FrameworkIdentity-Retail (dependendo se você estiver usando a versão de depuração ou de varejo do runtime) e copie os valores Name e MinVersion desse atributo. Por exemplo, este é o atributo FrameworkIdentity-Retail do pacote de estrutura do VC 14.0 atual.

     FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"
     

  3. No manifesto do pacote do aplicativo, adicione o seguinte elemento <PackageDependency> no nó <Dependencies>. Certifique-se de substituir os valores Name e MinVersion pelos valores copiados na etapa anterior. O exemplo a seguir especifica uma dependência para a versão atual do pacote de estrutura vc 14.0.

     <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
     

• Seu aplicativo contém uma lista de saltos personalizada Ao usar a lista de atalhos, é importante ter em mente vários problemas e limitações.

  • A arquitetura do aplicativo não corresponde ao sistema operacional. As listas de atalho atualmente não funcionarão corretamente se as arquiteturas do aplicativo e do sistema operacional não corresponderem (por exemplo, um aplicativo x86 em execução no Windows x64). No momento, não há nenhuma solução alternativa além de recompilar seu aplicativo para a arquitetura correspondente.

  • O aplicativo cria entradas da lista de atalhos e chama ICustomDestinationList::SetAppID ou SetCurrentProcessExplicitAppUserModelID. Não defina programaticamente seu AppID no código. Isso fará com que as entradas da lista de atalhos não sejam exibidas. Se o aplicativo precisar de uma ID personalizada, especifique-a usando o arquivo de manifesto. Verifique Como empacotar manualmente um software para desktop para obter instruções. A AppID do aplicativo é especificada na seção YOUR_PRAID_HERE .

  • O aplicativo adiciona um link de shell de lista de atalhos que referencia um executável no pacote. Não é possível iniciar executáveis diretamente no pacote por meio de uma lista de atalhos (com exceção do caminho absoluto do .exe próprio do aplicativo). Em vez disso, registre um alias de execução do aplicativo (que permite que o aplicativo da área de trabalho empacotado seja iniciado por uma palavra-chave como se estivesse no PATH) e defina o caminho de destino do link para o alias. Para obter detalhes sobre como usar a extensão appExecutionAlias, consulte Integrar seu aplicativo de área de trabalho com o Windows 10. Observe que, se você precisar que os ativos do link na lista de atalhos correspondam ao .exe original, precisará definir os ativos, como o ícone, usando SetIconLocation e o nome de exibição com PKEY_Title como você faria para outras entradas personalizadas.

  • O aplicativo adiciona entradas de lista de atalhos que referenciam ativos no pacote do aplicativo por caminhos absolutos. O caminho de instalação de um aplicativo pode mudar quando seus pacotes são atualizados, alterando o local dos ativos (como ícones, documentos, executáveis e assim por diante). Se as entradas de lista de salto fizerem referência a esses ativos por caminhos absolutos, o aplicativo deverá atualizar sua lista de saltos periodicamente (como na inicialização do aplicativo) para garantir que os caminhos sejam resolvidos corretamente. Como alternativa, use as APIs Windows.UI.StartScreen.JumpList do UWP, que permitem referenciar ativos de cadeias de caracteres e imagens usando o esquema de URI package-relative ms-resource (que também reconhece linguagem, DPI e alto contraste).

• Seu aplicativo inicia um utilitário para executar tarefas. Evite iniciar utilitários de comando, como PowerShell e Cmd.exe. Na verdade, se os usuários instalarem seu aplicativo em um sistema que executa o Windows 10 S, seu aplicativo não poderá iniciá-los. Isso pode impedir que seu aplicativo seja enviado à Microsoft Store porque todos os aplicativos enviados à Microsoft Store devem ser compatíveis com o Windows 10 S.

  Iniciar um utilitário geralmente pode fornecer uma maneira conveniente de obter informações do sistema operacional, acessar o registro ou acessar recursos do sistema. No entanto, você pode usar APIs UWP para realizar esses tipos de tarefas. Essas APIs têm um desempenho maior porque não precisam de um executável separado para serem executadas, mas, mais importante, impedem que o aplicativo alcance fora do pacote. O design do aplicativo permanece consistente com o isolamento, a confiança e a segurança que vem com um aplicativo que você empacotou e seu aplicativo se comportará conforme o esperado em sistemas que executam o Windows 10 S.

• Seu aplicativo hospeda suplementos, plug-ins ou extensões. Em muitos casos, as extensões do tipo COM provavelmente continuarão funcionando, desde que a extensão não tenha sido empacotada e seja instalada com confiança total. Isso ocorre porque esses instaladores podem usar seus recursos de confiança total para modificar o registro e colocar arquivos de extensão onde o aplicativo host espera encontrá-los.

  No entanto, se essas extensões forem empacotadas e instaladas como um pacote de aplicativos do Windows, elas não funcionarão porque cada pacote (o aplicativo host e a extensão) será isolado um do outro. Para saber mais sobre como os aplicativos são isolados do sistema, veja Bastidores da Ponte de Desktop.

  Todos os aplicativos e extensões instalados pelos usuários em um sistema que executa o Windows 10 S devem ser instalados como pacotes de aplicativos do Windows. Portanto, se você pretende empacotar suas extensões ou planeja incentivar seus colaboradores a empacotá-las, considere como você pode facilitar a comunicação entre o pacote de aplicativos host e quaisquer pacotes de extensão. Uma maneira de fazer isso é usando um serviço de aplicativo.

• Seu aplicativo gera código. Seu aplicativo pode gerar código que consome na memória, mas evite gravar o código gerado em disco porque o processo de certificação do aplicativo Windows não pode validar esse código antes do envio do aplicativo. Além disso, os aplicativos que gravam código em disco não serão executados corretamente em sistemas que executam o Windows 10 S. Isso pode impedir que seu aplicativo seja enviado à Microsoft Store porque todos os aplicativos enviados à Microsoft Store devem ser compatíveis com o Windows 10 S.