• Artigo

Junho de 2019

Volume 34 – Número 6

[DevOps]

MSIX: a maneira moderna de implantar aplicativos para área de trabalho no Windows

Por Magnus Montin | Junho de 2019 | Obtenha o código

MSIX é o novo formato de empacotamento introduzido na atualização do Windows 10 realizada em outubro de 2018. Seu objetivo é combinar o melhor de todas as tecnologias de instalação anteriores, como MSI e ClickOnce. A partir de agora, será recomendado para a instalação de aplicativos no Windows. Este artigo mostra como empacotar um aplicativo de área de trabalho do .NET e como configurar a integração contínua (CI), a implantação contínua (CD) e as atualizações automáticas de pacotes MSIX sideloaded usando o Azure Pipelines.

Primeiro, algumas informações básicas. No Windows 8, a Microsoft introduziu uma API e o tempo de execução chamado Windows Runtime, cujo objetivo principal era fornecer um conjunto de serviços de plataforma para um novo tipo de aplicativo, originalmente conhecido como "moderno", "Metro", "imersivo", ou apenas um aplicativo da "Windows Store". Esse tipo de aplicativo surgiu em decorrência da revolução do dispositivo móvel, normalmente direcionava-se a vários fatores formas de dispositivo, como telefones, tablets e laptops, e, em geral, era instalado e atualizado na central da Microsoft Store.

Essa classe de aplicativo evoluiu muito desde então e agora é conhecido como um aplicativo da plataforma Universal do Windows (UWP). Os aplicativos UWP são executados em uma área restrita chamada AppContainer, isolada de outros processos. Eles declaram explicitamente os recursos para exigir as permissões necessárias ao funcionamento correto, e cabe ao usuário decidir se esses recursos devem ser aceitos. Esse procedimento é diferente do realizado por um aplicativo de área de trabalho tradicional, que normalmente é executado como um processo de confiança total, com permissões completas de leitura e gravação do usuário atual.

Na Atualização de Aniversário do Windows 10, a Microsoft introduziu a Ponte de Desktop (também conhecida como Projeto Centennial). Ela permite que você empacote o aplicativo de área de trabalho tradicional como um aplicativo UWP, mas ainda o execute como um processo de confiança total. Um aplicativo empacotado pode ser carregado para a Microsoft Store ou Store para Empresas e aproveitar a implantação simplificada, o licenciamento interno e os recursos de atualização automática oferecidos pela Store. Depois que você empacotar seu aplicativo, também poderá começar a usar as novas APIs do Windows 10 e migrar seu código para a UWP a fim de alcançar os clientes em todos os dispositivos.

Mesmo que você não esteja interessado na Store ou na UWP, ainda convém empacotar seus aplicativos de linha de negócios da área de trabalho para tirar proveito do novo modelo de aplicativo oferecido pelo Windows 10. Ele fornece instalações e desinstalações limpas de aplicativos redirecionando automaticamente todas as operações para o registro e algumas pastas bem conhecidas do sistema para uma pasta local do aplicativo instalado, na qual um sistema de arquivos virtual e o registro são configurados. Você não precisa fazer nada em seu código-fonte para que isso ocorra — ele já foi resolvido automaticamente pelo Windows. Quando um pacote é desinstalado, toda a pasta local é removida, não deixando nenhum vestígio do aplicativo no sistema.

O MSIX é basicamente um sucessor da Ponte de Desktop, e o conteúdo de um pacote MSIX — e as limitações de aplicativos empacotados — é basicamente igual ao formato APPX usado pela Ponte de Desktop. Os requisitos são listados nos documentos oficiais em bit.ly/2OvCcVW e devem ser levados em conta antes de você decidir se deseja empacotar seus aplicativos. Alguns deles se aplicam somente aos aplicativos que estão sendo publicados na Store.

O MSIX adiciona um novo recurso chamado pacotes de modificação. É um conceito semelhante ao das transformações MST, pois permite que os administradores de TI personalizem um aplicativo, normalmente de um fornecedor, sem a necessidade de reempacotá-lo do zero sempre que um novo recurso ou correção de bug é lançada. O pacote de modificação é mesclado com o aplicativo principal em tempo de execução e pode desabilitar alguns recursos do aplicativo, alterando algumas configurações do registro, por exemplo. Do ponto de vista do desenvolvedor, não se trata de uma grande vantagem, pressupondo que você possui o código-fonte e os pipelines de build e versão dos seus aplicativos. Porém, para empresas de grandes porte, isso pode cortar custos e impedir o que é conhecido como paralisia do pacote.

A definição do formato MSIX é de software livre no GitHub, e a Microsoft planeja fornecer um SDK que possa ser usado para compactar e descompactar pacotes MSIX em todos os principais sistemas operacionais, inclusive Linux e macOS. O MSIX foi oficialmente introduzido na versão 1809 do Windows 10 em outubro de 2018 e, em seguida, a Microsoft o tornou compatível também com versões anteriores — na atualização (versão 1803), em abril de 2018, e no Fall Creators Update (versão 1709), em outubro de 2017.

Empacotamento

Se você tiver um instalador, haverá uma ferramenta de empacotamento MSIX disponível na Store que permitirá sua conversão em MSIX Store. Ela permite que os administradores empacotem aplicativos existentes mesmo sem ter acesso ao código-fonte original. Para desenvolvedores, o Visual Studio 2017 versão 15.5 e posterior fornece um Projeto de Empacotamento de Aplicativos do Windows que simplifica o processo de empacotamento dos aplicativos existentes. Você o encontrará em Arquivo | Adicionar | Novo Projeto | Instalado | Visual C# | Universal do Windows. Ele inclui uma pasta de aplicativo na qual você pode clicar com o botão direito do mouse no Gerenciador de Soluções e escolher uma referência a ser adicionada ao Windows Presentation Foundation (WPF), ao Windows Forms (WinForms) ou a qualquer projeto de área de trabalho que desejar empacotar. Se você clicar com o botão direito do mouse no aplicativo referenciado e escolher Definir como Ponto de Entrada, poderá compilar, executar e depurar seu aplicativo da forma habitual.

A diferença entre o início do processo de área de trabalho original e o projeto de empacotamento é que este executará seu aplicativo em um contêiner de aplicativos modernos. Em segundo plano, o Visual Studio usa as ferramentas de linha de comando MakeAppx e SignTool do SDK do Windows para primeiro criar um arquivo .msix e, em seguida, assiná-lo com um certificado. Esta etapa não é opcional. Todos os pacotes MSIX devem ser assinados com um certificado vinculado a uma autoridade raiz confiável no computador em que você pretende instalar e executar o aplicativo empacotado.

Assinatura digital O projeto de empacotamento inclui um arquivo de Troca de Informações Pessoais (PFX) padrão protegido por senha que você provavelmente desejará substituir pelo seu. Se sua empresa não fornecer um certificado de assinatura de código, você poderá comprar um de uma autoridade confiável ou criar um certificado autoassinado. Há uma opção "Criar certificado de teste" e um Assistente de importação no Visual Studio, que você encontrará se abrir o arquivo Package.appxmanifest no designer de manifesto do aplicativo padrão e procurar a guia Empacotamento. Se você não for muito fã de assistentes nem de caixas de diálogo, poderá usar o cmdlet New-SelfSignedCertificate do PowerShell para criar um certificado:

> New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=MyCompany,
  O=MyCompany, L=Stockholm, S=N/A, C=Sweden" -KeyUsage DigitalSignature
    -FriendlyName MyCertificate -CertStoreLocation "Cert:\LocalMachine\My"
      -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.3',
        '2.5.29.19={text}Subject Type:End Entity')

O cmdlet gera uma impressão digital (como o A27...D9F aqui) que você pode passar para outro cmdlet, Move-Item, a fim de mover o certificado para o repositório de certificação raiz confiável:

>Move-Item Cert:\LocalMachine\My\A27A5DBF5C874016E1A0DEBF38A97061F6625D9F
  -Destination Cert:\LocalMachine\Root

Novamente, é preciso instalar o certificado nesse repositório em todos os computadores em que pretende instalar e executar o aplicativo empacotado. Você também precisará habilitar o sideload de aplicativos nesses dispositivos. Em um computador não gerenciado, isso pode ser feito em Atualização e Segurança | Para Desenvolvedores no aplicativo Configurações. Em um dispositivo gerenciado por uma organização, você pode ativar o sideload efetuando push de uma política com um provedor de Gerenciamento de Dispositivo Móvel (MDM).

A impressão digital também pode ser usada para exportar o certificado para um novo arquivo PFX usando o cmdlet Export-PfxCertificate:

>$pwd = ConvertTo-SecureString -String secret -Force -AsPlainText
>Export-PfxCertificate -cert
  "Cert:\LocalMachine\Root\A27A5DBF5C874016E1A0DEBF38A97061F6625D9F"
    -FilePath "c:/<SolutionFolder>/Msix/certificate.pfx" -Password $pwd

Lembre-se de informar ao Visual Studio para usar o arquivo PFX gerado para assinar o pacote MSIX selecionando-o na guia Empacotamento no designer ou manualmente editando o arquivo de projeto .wapproj e substituindo os valores dos elementos <PackageCertificateKeyFile> e <PackageCertificateThumbprint>.

Manifesto do pacote O arquivo Package.appxmanifest é um modelo baseado em XML usado pelo processo de compilação para gerar um arquivo AppxManifest.xml assinado digitalmente que inclui todas as informações de que o sistema operacional precisa para implantar, exibir e atualizar o aplicativo empacotado. Nele você especifica o nome de exibição e o logotipo do seu aplicativo, como ele aparecerá no shell do Windows após sua instalação.

Verifique se a propriedade Subject do certificado que você usa para assinar o pacote MSIX tem o mesmo valor do atributo Publisher do elemento Identity. Como um aplicativo de área de trabalho empacotado só pode ser executado em dispositivos da área de trabalho, remova o elemento TargetDeviceFamily denominado Windows.Universal do elemento Dependencies no modelo padrão gerado pelo Visual Studio.

Os atributos MinVersion e MaxVersionTested, ou Versão Mínima e Versão de Destino, exibidos na caixa de diálogo que aparece quando você cria um projeto de empacotamento, seguem o conceito da UWP, em que o primeiro especifica a versão mais antiga do sistema operacional com a qual seu aplicativo é compatível, e o último é usado para identificar o conjunto de APIs disponíveis quando o aplicativo é compilado. Ao empacotar aplicativos da área de trabalho que não chamam nenhuma API do Windows 10, você deve selecionar a mesma versão. Caso contrário, seu código deverá incluir verificações de API de tempo de execução para evitar o recebimento de exceções durante a execução de seu aplicativo em dispositivos que se destinam à versão mínima.

Para gerar o pacote MSIX real, há um assistente disponível em Projeto | Store | Criar Pacotes de Aplicativos no Visual Studio. Um usuário final instala um pacote MSIX clicando duas vezes no arquivo .msix gerado. Isso abre uma caixa de diálogo interna, não personalizável, mostrada na Figura 1, que orienta todo o processo de instalação do aplicativo.

O instalador de aplicativo e a experiência de instalação do MSIX no Windows 10
Figura 1 O instalador de aplicativo e a experiência de instalação do MSIX no Windows 10

Integração contínua

Se você quiser configurar a CI para seus pacotes MSIX, o Azure Pipelines é totalmente compatível. Ele dá suporte à Configuração como Código (CAC) com o uso de arquivos YAML e fornece um agente de compilação hospedado na nuvem com todos os softwares necessários para criar pacotes MSIX pré-instalados.

Antes de compilar o projeto de empacotamento da mesma maneira adotada pelo Visual Studio, ou seja, usando a linha de comando do MSBuild, o processo de compilação pode criar uma versão do pacote MSIX que está sendo produzido editando o atributo Version do elemento Package no arquivo Package.appxmanifest. No Azure Pipelines, isso pode ser obtido por meio de uma expressão para definir uma variável de contador, que é incrementada para cada compilação, e de um script do PowerShell, que usa a classe System.Xml.Linq.XDocument no .NET para alterar o valor do atributo. A Figura 2 mostra um exemplo de arquivo YAML com diferentes versões e cria um pacote MSIX com base em um projeto de empacotamento antes de copiá-lo em um diretório de teste no agente de build.

Figura 2 O arquivo YAML que define o pipeline de build do MSIX

pool: 
  vmImage: vs2017-win2016
variables:
  buildPlatform: 'x86'
  buildConfiguration: 'release'
  major: 1
  minor: 0
  build: 0
  revision: $[counter('rev', 0)]
steps:
- powershell: |
   [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
   $path = "Msix/Package.appxmanifest"
   $doc = [System.Xml.Linq.XDocument]::Load($path)
   $xName =
     [System.Xml.Linq.XName]
       "{https://schemas.microsoft.com/appx/manifest/foundation/windows10}Identity"
   $doc.Root.Element($xName).Attribute("Version").Value =
     "$(major).$(minor).$(build).$(revision)";
   $doc.Save($path)
  displayName: 'Version Package Manifest'
- task: MSBuild@1
  inputs:
    solution: Msix/Msix.wapproj
    platform: $(buildPlatform)
    configuration: $(buildConfiguration)
    msbuildArguments: '/p:OutputPath=NonPackagedApp
     /p:UapAppxPackageBuildMode=SideLoadOnly  /p:AppxBundle=Never /p:AppxPackageOutput=$(Build.ArtifactStagingDirectory)\MsixDesktopApp.msix /p:AppxPackageSigningEnabled=false'
  displayName: 'Package the App'
- task: DownloadSecureFile@1
  inputs:
    secureFile: 'certificate.pfx'
  displayName: 'Download Secure PFX File'
- script: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\signtool"
    sign /fd SHA256 /f $(Agent.TempDirectory)/certificate.pfx /p secret $(
    Build.ArtifactStagingDirectory)/MsixDesktopApp.msix'
  displayName: 'Sign MSIX Package'
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'

O nome da máquina virtual hospedada que executa o Visual Studio 2017 no Windows Server 2016 é vs2017-win2016. Ela tem as cargas de trabalho de desenvolvimento da UWP e do .NET necessárias instaladas, incluindo a SignTool, que é usada para assinar o pacote MSIX após ele ter sido criado pelo MSBuild. Observe que o arquivo PFX não deve ser adicionado ao controle de origem. Ele também é ignorado pelo Git por padrão. Em vez disso, ele deve ser carregado para o Azure Pipelines como um arquivo secreto na guia Biblioteca no portal da Web. Como ele inclui a chave privada do certificado que representa a assinatura digital e a identidade da sua empresa, certamente você não deseja distribuí-lo para mais pessoas do que o necessário.

Em grandes empresas em que você libera seu software em vários ambientes e diferentes estágios, a melhor prática é assinar os pacotes como parte do processo de liberação e deixar que o pipeline de build produza pacotes não assinados. Isso não só permite que você assine com certificados diferentes para ambientes diferentes, mas também permite o carregamento de seus pacotes para a Store, onde serão assinados por um certificado da Microsoft.

Observe também que os segredos, como a senha para o arquivo PFX, não devem ser incluídos no arquivo YAML. Ao contrário das variáveis que especificam a arquitetura do processador de destino e a versão do pacote, eles são definidos e configurados na interface da Web.

A Figura 3mostra o Gerenciador de soluções para um aplicativo WPF que foi criado com o modelo de projeto padrão no Visual Studio e empacotado por meio de um projeto de empacotamento de aplicativos do Windows. O arquivo YAML foi adicionado ao projeto de empacotamento, e o check-in foi feito para um repositório de códigos-fonte com o restante do código.

Um aplicativo WPF empacotado pronto para ser enviado por push para o controle de códigos-fonte
Figura 3 Um aplicativo WPF empacotado pronto para ser enviado por push para o controle de códigos-fonte

Para configurar o pipeline de build real, navegue até o portal do Azure DevOps em dev.azure.com/<organização> e crie um novo projeto. Se você não tiver uma conta, poderá criar uma. Depois de entrar e criar um projeto, poderá também enviar por push o código-fonte para o repositório do Git que está configurado em https://<organização>@dev.azure.com/<organização>/<projeto>/_git/<projeto> ou usar qualquer outro provedor, como o GitHub. Você terá de escolher o local do repositório quando criar um novo pipeline no portal. Primeiro clique no botão "Pipelines" e, em seguida, em "Novo Pipeline".

Na tela Configurar, exibida em seguida, selecione a opção "Arquivo YAML do Azure Pipelines" e selecione o caminho até o arquivo YAML com check-in feito no seu repositório, como mostrado na Figura 4.

Interface da Web da configuração do pipeline
Figura 4 Interface da Web da configuração do pipeline

Clique duas vezes no pacote MSIX produzido pela compilação para baixá-lo e instalá-lo em qualquer computador compatível com o Windows 10 com o certificado necessário instalado. Você também pode configurar um pipeline de CD que copie o pacote para um site da Web ou um arquivo de compartilhamento onde seus usuários finais possam baixá-lo. Voltaremos a isso em instantes.

Atualizações automáticas O pacote MSIX pode extrair-se e substituir automaticamente qualquer versão anterior do aplicativo empacotado que possa estar presente no computador quando ele é instalado. O formato MSIX não fornece suporte interno à atualização automática de um aplicativo que já foi instalado usando um arquivo .msix quando você o abrir.

No entanto, a partir da atualização do Windows 10 de abril de 2018, há suporte para um arquivo do instalador de aplicativo, que você pode implantar com seu pacote para habilitar atualizações automáticas. Ele contém um elemento MainPackage cujo atributo de Uri se refere ao pacote MSIX original ou atualizado. A Figura 5 mostra um exemplo de um arquivo .appinstaller mínimo. Observe que o atributo de Uri do elemento raiz especifica uma URL ou um caminho UNC para um compartilhamento de arquivo no qual o sistema operacional vai procurar os arquivos atualizados. Quando o URI for diferente na versão atualmente instalada e no novo arquivo do instalador de aplicativo, a operação de implantação será redirecionada para o URI "antigo".

Figura 5 Um arquivo .appinstaller que procurará os arquivos atualizados em \\server\foo

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller xmlns="https://schemas.microsoft.com/appx/appinstaller/2018"
              Version="1.0.0.0"
              Uri="\\server\foo\MsixDesktopApp.appinstaller">
  <MainPackage Name="MyCompany.MySampleApp"
               Publisher="CN=MyCompany, O=MyCompany, L=Stockholm, S=N/A, C=Sweden"
               Version="1.0.0.0"
               Uri="\\server\foo\MsixDesktopApp.msix"
               ProcessorArchitecture="x86"/>
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" />
  </UpdateSettings>
</AppInstaller>

O elemento UpdateSettings é usado para informar ao sistema quando verificar se há atualizações e se o usuário deve ser forçado a fazê-la. A referência de esquema completa, incluindo os namespaces com suporte para cada versão do Windows 10, pode ser encontrada nos documentos em bit.ly/2TGWnCR.

Se você adicionar o arquivo .appinstaller na Figura 5 ao projeto de empacotamento e definir sua propriedade Package Action como Content e a propriedade Copy to Output Directory como Copy, se for mais recente, será possível adicionar outra tarefa do PowerShell ao arquivo YAML, que atualizará os atributos Version da raiz e os elementos MainPackage e salvará o arquivo atualizado no diretório de teste:

- powershell: |
  [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
  $doc = [System.Xml.Linq.XDocument]::Load(
    "$(Build.SourcesDirectory)/Msix/Package.appinstaller")
  $version = "$(major).$(minor).$(build).$(revision)"
  $doc.Root.Attribute("Version").Value = $version;
  $xName =
    [System.Xml.Linq.XName]
      "{https://schemas.microsoft.com/appx/appinstaller/2018}MainPackage"
  $doc.Root.Element($xName).Attribute("Version").Value = $version;
  $doc.Save("$(Build.ArtifactStagingDirectory)/MsixDesktopApp.appinstaller")
displayName: 'Version App Installer File'

Em seguida, você poderá distribuir o arquivo .appinstaller para os usuários finais e autorizar que cliquem duas vezes nele em vez de no arquivo .msix para instalar o aplicativo empacotado.

Implantação Contínua

O arquivo do instalador de aplicativo é um XML não compilado que pode ser editado após a compilação, se necessário. Isso facilita o uso quando você implanta o software em vários ambientes e quando deseja separar o pipeline de build do processo de liberação.

Se você criar um pipeline de lançamento no Portal do Azure usando o modelo "Trabalho vazio" e usar o pipeline de build recém-configurado como a origem do artefato a ser implantado, conforme mostrado na Figura 6, poderá adicionar a tarefa do PowerShell na Figura 7 ao estágio de versão para alterar dinamicamente os valores dos dois atributos de Uri no arquivo .appinstaller para refletir o local no qual o aplicativo for publicado.

Guia Pipeline no Portal do Azure DevOps
Figura 6 Guia Pipeline no Portal do Azure DevOps

Figura 7 Uma tarefa de pipeline de lançamento que modifica os Uris no arquivo .appinstaller

- powershell: |
  [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
  $fileShare = "\\filesharestorageccount.file.core.windows.net\myfileshare\"
  $localFilePath =
    "$(System.DefaultWorkingDirectory)\_MsixDesktopApp\drop\MsixDesktopApp.appinstaller"
  $doc = [System.Xml.Linq.XDocument]::Load("$localFilePath")
  $doc.Root.Attribute("Uri").Value = [string]::Format('{0}{1}', $fileShare,
    'MsixDesktopApp.appinstaller')
  $xName =
    [System.Xml.Linq.XName]"{https://schemas.microsoft.com/appx/appinstaller/2018}MainPackage"
  $doc.Root.Element($xName).Attribute("Uri").Value = [string]::Format('{0}{1}',
    $fileShare, 'MsixDesktopApp.appx')
  $doc.Save("$localFilePath")
displayName: 'Modify URIs in App Installer File'

Na tarefa da Figura 7, o URI é definido como o caminho UNC de um compartilhamento de arquivo do Azure. Como esse é o local em que o sistema operacional procurará o pacote MSIX quando você instalar e atualizar o aplicativo, também adicionei outro script de linha de comando ao pipeline de lançamento. Primeiro ele mapeia o compartilhamento de arquivo na nuvem até a unidade Z:\ local no agente de build e depois usa o comando xcopy para copiar os arquivos .appinstaller e .msix nessa unidade:

- script: |
  net use Z: \\filesharestorageccount.file.core.windows.net\myfileshare
    /u:AZURE\filesharestorageccount
    3PTYC+ociHIwNgCnyg7zsWoKBxRmkEc4Aew4FMzbpUl/
    dydo/3HVnl71XPe0uWxQcLddEUuq0fN8Ltcpc0LYeg==
  xcopy $(System.DefaultWorkingDirectory)\_MsixDesktopApp\drop Z:\ /Y
  displayName: 'Publish App Installer File and MSIX package'

Se você hospedar seu próprio Azure DevOps Server, obviamente poderá publicar os arquivos no seu próprio compartilhamento de rede interno.

Instalações na Web Se você optar por publicar em um servidor Web, poderá informar ao MSBuild para gerar um arquivo .appinstaller com versões e uma página HTML que contenha um link de download e algumas informações sobre o aplicativo empacotado. Para tal, forneça alguns argumentos adicionais no arquivo YAML:

- task: MSBuild@1
  inputs:
    solution: Msix/Msix.wapproj
    platform: $(buildPlatform)
    configuration: $(buildConfiguration)
    msbuildArguments: '/p:OutputPath=NonPackagedApp /p:UapAppxPackageBuildMode=SideLoadOnly  /p:AppxBundle=Never /p:GenerateAppInstallerFile=True
/p:AppInstallerUri=http://yourwebsite.com/packages/ /p:AppInstallerCheckForUpdateFrequency=OnApplicationRun /p:AppInstallerUpdateFrequency=1 /p:AppxPackageDir=$(Build.ArtifactStagingDirectory)/'
  displayName: 'Package the App'

A Figura 8 mostra o conteúdo do diretório de teste no agente de build após a execução do comando anterior. Esse será o mesmo resultado obtido do assistente no Visual Studio se você optar por criar pacotes para sideload e marcar a caixa de seleção "Habilitar atualizações automáticas". Usando essa abordagem, você pode remover o arquivo .appinstaller criado manualmente, mas talvez perca um pouco de flexibilidade na configuração do comportamento de atualização.

Build Artifacts Explorer no portal do Azure DevOps
Figura 8 Build Artifacts Explorer no portal do Azure DevOps

O arquivo HTML gerado inclui um hiperlink prefixado com o esquema de ativação de protocolo ms-appinstaller independente do navegador:

<a href="ms-appinstaller:?source=
  http://yourwebsite.com/packages/Msix_x86.appinstaller ">Install App</a>

Se você configurar um pipeline de lançamento que publique o conteúdo do local de destino em sua intranet ou em qualquer outro site, e o servidor Web oferecer suporte a solicitações de intervalo de bytes e estiver configurado corretamente, os usuários finais poderão usar esse link para instalar diretamente o aplicativo, sem que seja preciso baixar o pacote MSIX primeiro.

Conclusão

Neste artigo, você viu como é fácil empacotar um aplicativo da área de trabalho do .NET como um MSIX usando o Visual Studio. Também aprendeu a configurar pipelines de CI e CD no Azure Pipelines e a configurar atualizações automáticas. O MSIX é a maneira mais moderna de implantar aplicativos no Windows. Ele foi desenvolvido para ser seguro e confiável e permite que você e seus clientes tirem proveito do novo modelo de aplicativo e das APIs modernas que foram introduzidas no Windows 10, independentemente da sua intenção de carregar seus aplicativos na Microsoft Store ou fazer sideload deles em computadores na sua empresa. Desde que todos os usuários tenham migrado para o Windows 10, você poderá aproveitar o MSIX para empacotar a maioria dos aplicativos de área de trabalho do Windows.

Magnus Montiné um Microsoft MVP que trabalha como desenvolvedor de software/consultor autônomo em Estocolmo, na Suécia. Ele é especialista no .NET e na pilha da Microsoft e tem mais de uma década de experiência. Você pode ler seu blog em blog.magnusmontin.net.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Matteo Pagani (Matteo.Pagani@microsoft.com)
Matteo Pagani é um profissional apaixonado por desenvolvimento de clientes e pela plataforma Windows. Ele faz palestras em conferências em todo o mundo, é autor de livros e escreve regularmente artigos técnicos para sites e blogs dedicados a tecnologia. Ele foi Microsoft MVP na categoria de desenvolvimento do Windows por cinco anos. Após esse período, ingressou na Microsoft como engenheiro, mais precisamente na equipe do Windows AppConsult.

Discuta esse artigo no fórum do MSDN Magazine