Como o Visual Studio gera um manifesto do pacote do aplicativo

  • Artigo

quando você cria um projeto com Visual Studio, Visual Studio gera um manifesto de pacote (AppxManifest.xml), que contém informações que o sistema precisa para implantar, exibir ou atualizar um aplicativo Plataforma Universal do Windows (UWP).

Há duas variedades de arquivos de manifesto de pacote de aplicativo que você encontrará se estiver desenvolvendo um aplicativo com Visual Studio

  • Package.appxmanifest
    Esse é um arquivo de estilo XML que os desenvolvedores usam para configurar os detalhes de um aplicativo, como informações do Publicador, logotipos, arquiteturas de processador, etc. Essa é uma versão temporária e facilmente configurável do manifesto do pacote de aplicativo usado durante o desenvolvimento do aplicativo.
  • AppxManifest.xml
    esse arquivo é gerado pelo processo de compilação Visual Studio e é baseado nas informações no arquivo Package. appxmanifest. Esta é a versão final do manifesto do pacote de aplicativo usada com aplicativos publicados e Sideload. Se alguma atualização for feita no arquivo Package. appxmanifest, você deverá recompilar o projeto para ver as atualizações no arquivo de AppxManifest.xml.

Para obter uma visão geral do processo de empacotamento, consulte empacotar um aplicativo UWP com Visual Studio.

Validando o manifesto de aplicativo

Para poder publicar seu aplicativo, é preciso corrigir todos os erros que causam a falha das verificações de validação do Visual Studio. Quando o Visual Studio gera o manifesto, ele valida o aplicativo das seguintes maneiras:

  • Validação sintática
    O Visual Studio confirma se todos os dados no manifesto de aplicativo estão de acordo com o esquema do manifesto de aplicativo.
  • Validação semântica
    O Visual Studio fornece diretrizes sobre dados esperados com base no contexto das informações.

Observação

Se essas seções não mencionarem o campo que você está procurando, elas serão geradas a partir de ambos os dados que podem ter sido configurados separadamente ou um valor padrão do esquema de manifesto.

Gerando o conteúdo de manifesto

Visual Studio popula os campos nas tabelas a seguir ao gerar o arquivo de AppxManifest.xml para o pacote do aplicativo.

Identidade

A Identity seção do manifesto do aplicativo contém os campos a seguir.

Campo Descrição
Nome O nome do pacote, que é populado de forma diferente nos seguintes cenários:
  • Por padrão, o valor desse campo é um GUID gerado.
  • se você associar o aplicativo ao Microsoft Store, ou se você invocar o comando Store- > Create app packages... e, em seguida, entrar com uma conta de desenvolvedor, o valor desse campo será recuperado do aplicativo associado no Microsoft Store ou no Partner Center.
  • Se você invocar o comando Store- > create app Packages... , mas não entrar com uma conta de desenvolvedor, o valor desse campo será obtido do manifesto de origem.
Publicador O nome do publicador. O nome é preenchido de maneira diferente nos seguintes cenários:
  • Por padrão, o valor desse campo é o nome do usuário.
  • se você associar o aplicativo ao Microsoft Store, ou se você invocar o comando Store- > Create app packages... e, em seguida, entrar com uma conta de desenvolvedor, o valor desse campo será o publicador associado à conta.
  • Se você invocar o comando Store- > create app Packages... , mas não entrar com uma conta de desenvolvedor, o valor desse campo corresponderá ao campo Subject do certificado de teste usado para assinar o pacote do aplicativo.
Visual Studio só dá suporte ao formato CN (common name) para o publicador e adicionará o prefixo "CN =" ao campo publisher no manifesto.
Versão A versão do aplicativo que está sendo compilado. Normalmente, isso é incrementado sempre que o aplicativo é modificado e empacotado. Para garantir que o Version seja incrementado corretamente, use a caixa de diálogo fornecida ao invocar Store- > create app Packages... para fazer atualizações.
ProcessorArchitecture Um valor que é gerado com base na configuração de compilação que você especificou para o projeto. Se referências de projeto ou referências de arquivo no projeto direcionarem uma arquitetura específica diferente do pacote do aplicativo, um erro de compilação será gerado e você deverá alterar a arquitetura de destino do pacote do aplicativo para que ele funcione para todas as referências.

Aqui está um exemplo do XML de Identity saída:

<Identity Name="Microsoft.UWPAppExample"
          Publisher="CN=Microsoft Corporation"
          Version="1.0.0.0"
          ProcessorArchitecture="x86" />

Propriedades

A Properties seção do manifesto do aplicativo contém os campos na tabela a seguir.

Campo Descrição
PublisherDisplayName Essa cadeia de caracteres é preenchida de forma diferente nos seguintes cenários:
  • Por padrão, o valor desse campo é o nome do usuário.
  • se você associar o aplicativo ao Microsoft Store, ou se você invocar o comando Store- > Create app packages... e, em seguida, entrar com uma conta de desenvolvedor, o valor de tha desse campo corresponderá à cadeia de caracteres PublisherDisplayName associada à sua conta de desenvolvedor.
  • Se você invocar o comando Store- > create app Packages... , mas não entrar com uma conta de desenvolvedor, o valor desse campo será seu nome de usuário, a menos que você especifique o contrário no arquivo Package. appxmanifest.
DisplayName A cadeia de caracteres é preenchida de maneira diferente nos seguintes cenários:
  • Por padrão, o valor desse campo é o nome do projeto.
  • se você associar o aplicativo ao Microsoft Store, ou se você invocar o comando Store- > Create app packages... e, em seguida, entrar com uma conta de desenvolvedor, o valor desse campo será populado de acordo com as seguintes regras:
    • Se você especificar esse valor no manifesto de origem e o valor começar com @ (que indica que você deseja localizar esse valor), o valor desse campo corresponderá ao que você especificou.
    • Se o aplicativo selecionado tiver apenas um nome, o valor será esse nome.
    • Se o aplicativo selecionado tiver vários nomes, mas o manifesto de origem não estiver localizado, o valor será definido como o nome de exibição no manifesto de origem. Do contrário, o valor é definido como o primeiro nome reservado.
  • Se você invocar o comando Store- > create app Packages... , mas não entrar com uma conta de desenvolvedor, o valor desse campo será obtido do manifesto de origem.
Logotipo um modelo de Visual Studio será usado Assets\StoreLogo.png por padrão. Esse valor deve ser personalizado pelo desenvolvedor no arquivo Package. appxmanifest.

Aqui está um exemplo do XML de Properties saída:

<Properties>
    <DisplayName>UWP App Example</DisplayName>
    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
</Properties>

Aplicativo

Um manifesto de aplicativo pode conter vários Application elementos, cada um com um nome de exibição que aparece no bloco no cliente. A Application seção do manifesto do aplicativo contém os campos na tabela a seguir.

Campo Descrição
ID A cadeia de caracteres é preenchida de maneira diferente nos seguintes cenários:
  • Por padrão, o valor desse campo é o nome do projeto.
  • se você associar o aplicativo ao Microsoft Store, ou se você invocar o comando Store- > Create app packages... e, em seguida, entrar com uma conta de desenvolvedor, o valor desse campo será o nome do aplicativo para o aplicativo selecionado se o /Properties[@DisplayName] e o /Applications/Application[@DisplayName] no manifesto de origem forem correspondentes. Do contrário, o valor permanecerá o mesmo do manifesto de origem.
  • Se você invocar o comando Store- > create app Packages... , mas não entrar com uma conta de desenvolvedor, o valor desse campo será o mesmo do manifesto de origem.
Executável O valor desse campo é o nome de saída do assembly do projeto. O token executável $targetnametoken $.exe usado no arquivo de manifesto de origem (Package. appxmanifest) é substituído pelo nome real do arquivo quando o manifesto é compilado.
EntryPoint Esse valor se baseia nos valores gerados Executable e Id .

Exemplo Application de saída:

<Applications>
    <Application Id="App" Executable="UWPAppExample.exe" EntryPoint="UWPAppExample.App">
        <!-- Other elements configured within the Application, such as Extensions, VisualElements, etc. -->
</Applications>

PackageDependency

a PackageDependency seção contém todas as dependências de biblioteca de componentes Windows para este pacote. por exemplo, se o seu projeto tiver uma referência a WinJS, Visual Studio recuperará as informações de identidade do pacote das dependências quando o manifesto for gerado. em seguida, Visual Studio preenche esta seção com os Name campos e MinVersion para cada pacote dependente.

em um projeto C++ nativo, Visual Studio adicionará uma referência ao tempo de execução do Visual C/C++:

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

extensões de registro de Windows Runtime

você pode implementar Windows Runtime componentes para seus aplicativos, mas precisará registrar esses componentes com o sistema operacional para que eles sejam executados corretamente. para registrar um componente Windows Runtime, você deve colocar as informações de registro nos arquivos WinMD e no manifesto do aplicativo. se um projeto implementar um componente Windows Runtime, a saída da compilação do projeto conterá um arquivo WinMD. Visual Studio extrai as informações de registro de Windows Runtime do arquivo WinMD e gera os elementos apropriados Extension no manifesto do aplicativo.

O sistema dá suporte a duas formas de servidores: servidores .dll (em processo) e servidores .exe (fora de processo). Esses servidores exigem informações de registro semelhantes, mas diferentes, que devem ser copiadas para o manifesto de aplicativo. O Visual Studio dá suporte à geração de manifesto apenas para servidores .dll, e a extensão DLLServer é obrigatória para registrar servidores .dll. Os seguintes valores no manifesto de aplicativo são utilizados dos arquivos WinMD para construir a Extensão DLLServer:

  • DllPath
  • ActivatableClassId
  • ThreadingModel
  • ActivatableClass (atributo ActivatableClassId)

Aqui está um exemplo do XML de saída:

<extension category="Microsoft.Windows.ActivatableClass">
    <dllServer>
        <dllPath>Fabrikam.dll</dllPath>
        <activatableClass activatableClassId="Fabrikam.MyClass" threadingModel="sta" />
    </dllServer>
</extension>

Para obter mais informações sobre este tópico, consulte Windows Runtime componentes.

Recursos

A Resources seção contém uma entrada para cada idioma compatível com o aplicativo. Você deve ter pelo menos um idioma de recurso especificado no manifesto do aplicativo. O Visual Studio gera automaticamente a lista de idiomas compatíveis com base nas informações de localização no projeto. O token de linguagem de recurso "x-generate" usado no arquivo de manifesto de origem (Package.appxmanifest) é substituído pelo código de idioma real quando o manifesto é criado. Aqui está um exemplo do XML de saída:

<Resources>
    <Resource Language="en-us">
    <Resource Language="fr-fr">
</Resources>

A primeira entrada na lista é o idioma padrão para o aplicativo.

TargetDeviceFamily

A TargetDeviceFamily seção contém os seguintes campos:

  • Nome
  • MinVersion
  • MaxVersionTested
<Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.0" />
</Dependencies>

Esses elementos são populados de MSBuild propriedades.

Confira também

Empacotar um aplicativo UWP com o Visual Studio
Arquiteturas de pacote do aplicativo
Referência do esquema de manifesto de pacote do Windows 10