Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Com a introdução de pacotes de ativos, os desenvolvedores agora têm as ferramentas para criar mais pacotes, além de mais tipos de pacotes. À medida que um aplicativo fica maior e mais complexo, ele geralmente será composto por mais pacotes, e a dificuldade de gerenciar esses pacotes aumentará (especialmente se você estiver criando fora do Visual Studio e usando arquivos de mapeamento). Para simplificar o gerenciamento da estrutura de empacotamento de um aplicativo, você pode usar o layout de empacotamento suportado pelo MakeAppx.exe.
O layout de empacotamento é um único documento XML que descreve a estrutura de empacotamento do aplicativo. Ele especifica os pacotes de um aplicativo (primário e opcional), os pacotes nos pacotes e os arquivos nos pacotes. Os arquivos podem ser selecionados de diferentes pastas, unidades e locais de rede. Os curingas podem ser usados para selecionar ou excluir arquivos.
Depois que o layout de empacotamento de um aplicativo é configurado, ele é usado com MakeAppx.exe para criar todos os pacotes para um aplicativo em uma única chamada de linha de comando. O layout de empacotamento pode ser editado para alterar a estrutura do pacote para atender às suas necessidades de implantação.
Exemplo de layout de embalagem simples
Aqui está um exemplo de como é um layout de embalagem simples:
<PackagingLayout xmlns="http://schemas.microsoft.com/appx/makeappx/2017">
<PackageFamily ID="MyGame" FlatBundle="true" ManifestPath="C:\mygame\appxmanifest.xml" ResourceManager="false">
<!-- x64 code package-->
<Package ID="x64" ProcessorArchitecture="x64">
<Files>
<File DestinationPath="*" SourcePath="C:\mygame\*"/>
<File ExcludePath="*C:\mygame\*.txt"/>
</Files>
</Package>
<!-- Media asset package -->
<AssetPackage ID="Media" AllowExecution="false">
<Files>
<File DestinationPath="Media\**" SourcePath="C:\mygame\media\**"/>
</Files>
</AssetPackage>
</PackageFamily>
</PackagingLayout>
Vamos detalhar este exemplo para entender como ele funciona.
Pacote Família
Este layout de empacotamento criará um único arquivo de pacote de aplicação unificado com um pacote de arquitetura x64 e um pacote de ativos de "Mídia".
O elemento PackageFamily é usado para definir um pacote de aplicativos. Você deve usar o atributo ManifestPath para fornecer um AppxManifest para o pacote, o AppxManifest deve corresponder ao AppxManifest para o pacote de arquitetura do pacote. O atributo ID também deve ser fornecido. Isso é usado com MakeAppx.exe durante a criação do pacote para que você possa criar apenas este pacote, se desejar, e este será o nome do arquivo do pacote resultante. O atributo FlatBundle é usado para descrever o tipo de pacote que você deseja criar, true para um pacote plano (sobre o qual você pode ler mais aqui) e false para um pacote clássico. O atributo ResourceManager é usado para especificar se os pacotes de recursos dentro desse pacote usarão MRT para acessar os arquivos. Isso é por padrão verdadeiro, mas a partir do Windows 10, versão 1803, isso ainda não está pronto, então esse atributo deve ser definido como false.
Pacote e Pacote de Ativos
Dentro da PackageFamily, são definidos os pacotes que a aplicação contém ou que referencia. Aqui, o pacote de arquitetura (também chamado de pacote principal) é definido com o elemento Package e o pacote de ativos é definido com o elemento AssetPackage . O pacote de arquitetura deve especificar para qual arquitetura o pacote se destina, seja "x64", "x86", "arm" ou "neutral". Você também pode (opcionalmente) fornecer diretamente um AppxManifest especificamente para este pacote usando o atributo ManifestPath novamente. Se um AppxManifest não for fornecido, um será gerado automaticamente a partir do AppxManifest fornecido para a PackageFamily.
Por padrão, o AppxManifest será gerado para cada pacote dentro do pacote. Para o pacote de ativos, você também pode definir o atributo AllowExecution . Definir isso como false (o padrão) ajudará a diminuir o tempo de publicação do seu aplicativo, já que os pacotes que não precisam ser executados não terão a verificação de vírus bloqueando o processo de publicação (você pode saber mais sobre isso em Introdução aos pacotes de ativos).
Ficheiros
Dentro de cada definição de pacote, você pode usar o elemento File para selecionar arquivos a serem incluídos neste pacote. O atributo SourcePath é onde os arquivos estão localmente. Você pode selecionar arquivos de pastas diferentes (fornecendo caminhos relativos), unidades diferentes (fornecendo caminhos absolutos) ou até mesmo compartilhamentos de rede (fornecendo algo como \\myshare\myapp\*). O DestinationPath é onde os arquivos irão parar dentro do pacote, em relação à raiz do pacote.
ExcludePath pode ser usado (em vez dos outros dois atributos) para selecionar arquivos a serem excluídos daqueles selecionados pelos atributos SourcePath de outros elementos File dentro do mesmo pacote.
Cada elemento File pode ser usado para selecionar vários arquivos usando curingas. Em geral, um único curinga (*) pode ser usado em qualquer lugar dentro do caminho qualquer número de vezes. No entanto, uma única carta curinga corresponderá apenas aos ficheiros dentro de uma pasta e não a quaisquer subpastas. Por exemplo, C:\MyGame\*\* pode ser usado no SourcePath para selecionar os arquivos C:\MyGame\Audios\UI.mp3 e C:\MyGame\Videos\intro.mp4, mas não pode selecionar C:\MyGame\Audios\Level1\warp.mp3. O curinga duplo (**) também pode ser usado no lugar de nomes de pastas ou arquivos para corresponder a qualquer coisa recursivamente (mas não pode estar ao lado de nomes parciais). Por exemplo, C:\MyGame\**\Level1\** pode selecionar C:\MyGame\Audios\Level1\warp.mp3 e C:\MyGame\Videos\Bonus\Level1\DLC1\intro.mp4. Os caracteres universais também podem ser usados para modificar diretamente os nomes dos ficheiros como parte do processo de empacotamento, se forem usados em locais diferentes entre a origem e destino. Por exemplo, ter C:\MyGame\Audios\* para SourcePath e Sound\copy_* para DestinationPath pode selecionar C:\MyGame\Audios\UI.mp3 e fazer com que ele apareça no pacote como Sound\copy_UI.mp3. Em geral, o número de curingas simples e curingas duplos deve ser igual para o SourcePath e o DestinationPath de um único elemento File.
Exemplo de layout de empacotamento avançado
Aqui está um exemplo de um layout de embalagem mais complicado:
<PackagingLayout xmlns="http://schemas.microsoft.com/appx/makeappx/2017">
<!-- Main game -->
<PackageFamily ID="MyGame" FlatBundle="true" ManifestPath="C:\mygame\appxmanifest.xml" ResourceManager="false">
<!-- x64 code package-->
<Package ID="x64" ProcessorArchitecture="x64">
<Files>
<File DestinationPath="*" SourcePath="C:\mygame\*"/>
<File ExcludePath="*C:\mygame\*.txt"/>
</Files>
</Package>
<!-- Media asset package -->
<AssetPackage ID="Media" AllowExecution="false">
<Files>
<File DestinationPath="Media\**" SourcePath="C:\mygame\media\**"/>
</Files>
</AssetPackage>
<!-- English resource package -->
<ResourcePackage ID="en">
<Files>
<File DestinationPath="english\**" SourcePath="C:\mygame\english\**"/>
</Files>
<Resources Default="true">
<Resource Language="en"/>
</Resources>
</ResourcePackage>
<!-- French resource package -->
<ResourcePackage ID="fr">
<Files>
<File DestinationPath="french\**" SourcePath="C:\mygame\french\**"/>
</Files>
<Resources>
<Resource Language="fr"/>
</Resources>
</ResourcePackage>
</PackageFamily>
<!-- DLC in the related set -->
<PackageFamily ID="DLC" Optional="true" ManifestPath="C:\DLC\appxmanifest.xml">
<Package ID="DLC.x86" Architecture="x86">
<Files>
<File DestinationPath="**" SourcePath="C:\DLC\**"/>
</Files>
</Package>
</PackageFamily>
<!-- DLC not part of the related set -->
<PackageFamily ID="Themes" Optional="true" RelatedSet="false" ManifestPath="C:\themes\appxmanifest.xml">
<Package ID="Themes.main" Architecture="neutral">
<Files>
<File DestinationPath="**" SourcePath="C:\themes\**"/>
</Files>
</Package>
</PackageFamily>
<!-- Existing packages that need to be included/referenced in the bundle -->
<PrebuiltPackage Path="C:\prebuilt\DLC2.appxbundle" />
</PackagingLayout>
Este exemplo difere do exemplo simples com a adição dos elementos ResourcePackage e Optional.
Os pacotes de recursos podem ser especificados com o elemento ResourcePackage . Dentro do ResourcePackage, o elemento Resources deve ser usado para especificar os qualificadores de recursos do pacote de recursos. Os qualificadores de recursos são os recursos que são suportados pelo pacote de recursos, aqui, podemos ver que existem dois pacotes de recursos definidos e cada um deles contém os arquivos específicos em inglês e francês. Um pacote de recursos pode ter mais de um qualificador, isso pode ser feito adicionando outro elemento Resource em Resources. Um recurso padrão para a dimensão do recurso também deve ser especificado se a dimensão existir (dimensões como idioma, escala, dxfl). Aqui, podemos ver que o inglês é o idioma padrão, o que significa que, para os utilizadores que não têm o francês definido como idioma do sistema, será feito o download do pacote de recursos em inglês e será mostrado em inglês.
Cada pacote opcional tem seus próprios nomes de família de pacotes distintos e deve ser definido com elementos PackageFamily , especificando o atributo Optional como true. O atributo RelatedSet é usado para especificar se o pacote opcional está dentro do conjunto relacionado (por padrão, isso é verdadeiro) – se o pacote opcional deve ser atualizado com o pacote primário.
O elemento PrebuiltPackage é usado para adicionar pacotes que não estão definidos no layout de empacotamento a ser incluído ou referenciado no(s) arquivo(s) do pacote de aplicativos a ser criado. Nesse caso, outro pacote opcional de DLC está sendo incluído aqui para que o arquivo de pacote de aplicativo principal possa fazer referência a ele e fazer parte do conjunto relacionado.
Crie pacotes de aplicativos com um layout de empacotamento e MakeAppx.exe
Depois de ter o layout de empacotamento para o seu aplicativo, pode começar a usar MakeAppx.exe para criar pacotes do seu aplicativo. Para construir todos os pacotes definidos no layout de empacotamento, use o comando:
MakeAppx.exe build /f PackagingLayout.xml /op OutputPackages\
Mas, se você estiver atualizando seu aplicativo e alguns pacotes não contiverem nenhum arquivo alterado, você poderá criar apenas os pacotes que foram alterados. Usando o exemplo de layout de empacotamento simples nesta página e criando o pacote de arquitetura x64, este é o aspeto do nosso comando:
MakeAppx.exe build /f PackagingLayout.xml /id "x64" /ip PreviousVersion\ /op OutputPackages\ /iv
O /id sinalizador pode ser usado para selecionar os pacotes a serem construídos a partir do layout da embalagem, correspondente ao atributo ID no layout. O /ip é usado para indicar onde a versão anterior dos pacotes estão neste caso. A versão anterior deve ser fornecida porque o arquivo de pacote do aplicativo ainda precisa fazer referência à versão anterior do pacote de mídia . O /iv indicador é usado para incrementar automaticamente a versão dos pacotes em construção (em vez de alterar a versão no AppxManifest). Como alternativa, os switches /pv e /bv podem ser usados para fornecer diretamente uma versão do pacote (para todos os pacotes a serem criados) e uma versão do bundle (para todos os bundles a serem criados), respectivamente.
Usando o exemplo de layout de empacotamento avançado nesta página, se você quiser criar apenas o pacote opcional Temas e o pacote de aplicativo Themes.main ao qual ele faz referência, use este comando:
MakeAppx.exe build /f PackagingLayout.xml /id "Themes" /op OutputPackages\ /bc /nbp
O /bc indicador é usado para indicar que os subelementos do pacote Temas também devem ser construídos (neste caso, Themes.main será construído). O indicador /nbp é usado para indicar que o pai do pacote Temas não deve ser criado. O pai do Themes, que é um pacote de aplicativos opcional, é o pacote de aplicativos principal: MyGame. Normalmente, para um pacote opcional em um conjunto relacionado, o pacote de aplicativo principal também deve ser criado para que o pacote opcional seja instalável, uma vez que o pacote opcional também é referenciado no pacote de aplicativo principal quando está em um conjunto relacionado (para garantir o controle de versão entre os pacotes primário e opcional). A relação pai-filho entre pacotes é ilustrada no diagrama a seguir: