Preparar para empacotar um aplicativo da área de trabalho

Este artigo lista as coisas que você precisa saber antes de empacotar seu aplicativo da área de trabalho. Poderá não precisar fazer muito para preparar a sua aplicação para o processo de embalagem, mas se algum dos itens abaixo se aplicar à sua aplicação, deve tratá-lo antes de iniciar a embalagem.

• 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 esta versão do sistema operacional inclui o .NET Framework 4.6.2 por padrão. As versões posteriores do SO 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 as versões de destino do .NET Framework anteriores à 4.6.2 em aplicativos de área de trabalho empacotados funcionem na maioria dos casos. No entanto, se apontares para uma versão anterior à 4.6.2, deves testar exaustivamente a tua aplicação de desktop empacotada antes de a distribuir aos utilizadores.

  • 4.0 - 4.6.1: Espera-se que os aplicativos destinados a essas versões do .NET Framework sejam executados sem problemas na versão 4.6.2 ou posterior. Portanto, esses aplicativos devem ser instalados e executados 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 na máquina 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 é executado como o usuário interativo. Os usuários que instalam seu aplicativo podem não ser administradores de 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 de sua funcionalidade não serão aceitos na Loja.

• Seu aplicativo requer um driver do Windows. MSIX não suporta drivers do Windows.

• Seu aplicativo requer um serviço de usuário do Windows. O MSIX não suporta serviços do Windows por usuário. O MSIX suporta serviços de sessão-0 (por máquina) executados em uma das contas de sistema definidas (LocalSystem, LocalService ou NetworkService). Em vez de um serviço de usuário do Windows, use uma tarefa em segundo plano.

• Os módulos da sua aplicação são carregados internamente em processos que não fazem parte do pacote da sua aplicação do Windows. Isso não é permitido, o que significa que extensões em processo, como extensões de shell, não são suportadas. Mas se você tiver dois aplicativos no mesmo pacote, poderá fazer a comunicação entre processos entre eles.

• Certifique-se de que 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 dos pacotes. Consulte "Definições->Sistema->Armazenamento->Mais definições de armazenamento->Alterar onde o novo conteúdo é salvo->Novos aplicativos serão salvos em". Se você estiver instalando uma extensão com seu aplicativo, certifique-se de que a extensão não tenha restrições adicionais de pasta de instalação. Por exemplo, algumas extensões podem desativar a instalação de sua extensão em unidades que não são do sistema. Isso resultará num erro 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) se a localização padrão tiver sido alterada.

• Seu aplicativo usa um ID de modelo de usuário de aplicativo personalizado (AUMID). Se o seu processo chamar SetCurrentProcessExplicitAppUserModelID para definir seu próprio AUMID, ele só poderá usar o AUMID gerado para ele pelo ambiente do modelo de aplicativo/pacote de aplicativos do Windows. Não é possível definir AUMIDs personalizados.

• Seu aplicativo modifica a seção de registro HKEY_LOCAL_MACHINE (HKLM). Qualquer tentativa do seu aplicativo de criar uma chave HKLM, ou abrir uma para modificação, resultará em uma falha de acesso negado. Lembre-se de que o seu aplicativo tem a sua própria visão virtualizada privada do registo, e, portanto, a noção de um ramo de registo aplicável a todo o utilizador e a toda a máquina (tal como o HKLM) não se aplica. Você precisará encontrar outra maneira de alcançar o que você estava usando HKLM para, como escrever para HKEY_CURRENT_USER (HKCU) em vez disso.

• Seu aplicativo usa uma subchave de registro ddeexec como um meio de iniciar outro aplicativo. Em vez disso, use um dos manipuladores de verbos 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, 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 e por aplicativo. Para obter mais detalhes sobre o redirecionamento de arquivo e registro, consulte Os bastidores do Desktop Bridge.

  Utilize um meio diferente de partilha de dados entre processos. Para saber mais, veja Armazenar e recuperar definições e outros dados da aplicação.

• Seu aplicativo grava no diretório de instalação do seu aplicativo. Por exemplo, seu aplicativo grava em um arquivo de log que você colocou no mesmo diretório que seu exe. Isso não é suportado, então você precisará encontrar outro local, como a loja de dados de aplicativos local.

• Seu aplicativo usa o diretório de trabalho atual. Durante a execução, a sua aplicação de desktop empacotada não obterá o mesmo diretório de trabalho especificado anteriormente no atalho .LNK do seu desktop. Você precisa alterar seu CWD em tempo de execução se ter o diretório correto é importante para que seu aplicativo funcione corretamente.

  Observação

  Se seu aplicativo precisar gravar no diretório de instalação ou usar o diretório de trabalho atual, você também pode considerar adicionar uma correção de tempo de execução usando o Package Support Framework ao seu pacote. Para obter mais detalhes, consulte 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 suporte COM em pacotes, o que permite registar servidores OOP COM e OLE que agora estão visíveis fora do pacote. Consulte Servidor COM e suporte de documentos OLE para Desktop Bridge.

  O suporte COM empacotado funciona com APIs COM existentes, mas não funcionará para extensões de aplicativo que dependem da leitura direta do registro, pois o local para 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 originários de executáveis externos ao seu pacote de aplicativos do Windows. Os processos de dentro do pacote podem registrar e usar assemblies GAC normalmente, mas eles não serão visíveis externamente. Isso significa que cenários de interoperabilidade como OLE não funcionarão se invocados por processos externos.

• Seu aplicativo está vinculando bibliotecas de tempo de execução C (CRT) de uma maneira sem suporte. A biblioteca de tempo de execução do Microsoft C/C++ fornece rotinas de programação para o sistema operacional Microsoft Windows. Essas rotinas automatizam muitas tarefas comuns de programação que não são fornecidas pelas linguagens C e C++. Se seu aplicativo utiliza a biblioteca de tempo de execução C/C++, você precisa garantir que ele esteja vinculado de uma maneira suportada.

  O Visual Studio 2017 oferece 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. Consulte a tabela a seguir para obter detalhes:

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

  Nota: Em todos os casos, deves ligar ao CRT mais recente disponível publicamente.

• O seu aplicativo instala e carrega assemblies da pasta paralela do Windows. Por exemplo, seu aplicativo usa bibliotecas de tempo de execução C VC8 ou VC9 e está vinculando-as 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 é suportado. 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 do aplicativo do Windows. Isso garante que o aplicativo se comporta como se as DLLs estivessem 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 sua 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, você deve manipular a implantação do Visual C++ Runtime. 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 Visual C++ Runtime nas seguintes pastas:

  • Pacotes do framework VC 14.0: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • Pacotes do framework VC 12.0: C:\Program Files (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 fazer referência ao pacote como uma dependência no manifesto do pacote. Quando os clientes instalam a versão comercial da sua aplicação a partir da Microsoft Store, o pacote será instalado a partir da Loja juntamente com a sua aplicação. As dependências não serão instaladas se você carregar seu aplicativo lateralmente. 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 Visual C++ Runtime em seu aplicativo:

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

  2. Abra o ficheiro SDKManifest.xml nesta pasta, localize o atributo FrameworkIdentity-Debug ou FrameworkIdentity-Retail (dependendo se estiver a usar a versão de depuração ou de varejo do tempo de execução) e copie os valores Name e MinVersion desse atributo. Por exemplo, aqui está o FrameworkIdentity-Retail atributo para o pacote de estrutura 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 para a sua aplicação, adicione o seguinte elemento <PackageDependency> sob o nó <Dependencies>. Certifique-se de substituir os 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" />
     

• A sua aplicação contém uma lista de saltos personalizada. Existem vários problemas e ressalvas a ter em conta ao utilizar jump lists.

  • A arquitetura do seu aplicativo não corresponde ao sistema operacional. Atualmente, as listas de atalhos não funcionam 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á outra solução alternativa além de recompilar seu aplicativo para a arquitetura correspondente.

  • A sua aplicação cria entradas na lista de saltos e chama ICustomDestinationList::SetAppID ou SetCurrentProcessExplicitAppUserModelID. Não defina programaticamente seu AppID no código. Isso fará com que as entradas da sua lista de atalhos não apareçam. Se seu aplicativo precisar de uma ID personalizada, especifique-a usando o arquivo de manifesto. Consulte Empacotar uma aplicação de ambiente de trabalho manualmente para obter instruções. O AppID para seu aplicativo é especificado na seção YOUR_PRAID_HERE .

  • O vosso aplicativo adiciona uma ligação de shell de lista de saltos que faz referência a um executável no vosso pacote. Você não pode iniciar executáveis diretamente em seu pacote a partir de uma lista de atalhos (com exceção do caminho absoluto do próprio aplicativo .exe). Em vez disso, registre um alias de execução de aplicativo (que permite que seu aplicativo de desktop empacotado inicie por meio de 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 da área de trabalho com o Windows 10. Observe que, se precisar que os recursos do link na lista de saltos correspondam ao .exeoriginal, deve definir recursos como o ícone usando SetIconLocation e o nome de exibição com PKEY_Title, tal como faria para outras entradas personalizadas.

  • A sua aplicação adiciona entradas de lista de saltos que fazem referência a ativos no pacote da aplicação por caminhos absolutos. O caminho de instalação de um aplicativo pode mudar quando seus pacotes são atualizados, alterando a localização dos ativos (como ícones, documentos, executáveis e assim por diante). Se as entradas da lista de atalhos fizerem referência a esses ativos por caminhos absolutos, o aplicativo deverá atualizar sua lista de atalhos periodicamente (como na inicialização do aplicativo) para garantir que os caminhos sejam resolvidos corretamente. Como alternativa, use as APIs UWP Windows.UI.StartScreen.JumpList que permitem fazer referência a recursos de cadeias de texto e de imagem usando o esquema de URI ms-resource relativo ao pacote (que também tem consciência de idioma, 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 bloquear o envio do seu aplicativo para a Microsoft Store porque todos os aplicativos enviados para a 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 os recursos do sistema. No entanto, você pode usar APIs UWP para realizar esses tipos de tarefas. Essas APIs têm mais desempenho 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á como esperado em sistemas que executam o Windows 10 S.

• Seu aplicativo hospeda suplementos, plug-ins ou extensões. Em muitos casos, as extensões no estilo COM provavelmente continuarão a funcionar enquanto a extensão não tiver sido empacotada e for instalada com confiança total. Isso porque esses instaladores podem usar seus recursos de confiança total para modificar o registro e colocar arquivos de extensão onde quer que seu aplicativo host espere encontrá-los.

  No entanto, se essas extensões forem empacotadas e, em seguida, instaladas como um pacote de aplicativo do Windows, elas não funcionarão porque cada pacote (o aplicativo host e a extensão) será isolado um do outro. Para ler mais sobre como os aplicativos são isolados do sistema, consulte Os bastidores do Desktop Bridge.

  Todos os aplicativos e extensões que os usuários instalam 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 aplicativo 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 no disco porque o processo de certificação de aplicativos do Windows não pode validar esse código antes do envio do aplicativo. Além disso, os aplicativos que gravam código no disco não serão executados corretamente em sistemas que executam o Windows 10 S. Isso pode bloquear o envio do seu aplicativo para a Microsoft Store porque todos os aplicativos enviados para a Microsoft Store devem ser compatíveis com o Windows 10 S.