Junio de 2019

Volumen 34, número 6

[DevOps]

MSIX: La manera moderna de implementar aplicaciones de escritorio en Windows

Por Magnus Montin | Junio de 2019 | Obtener el código

MSIX es el nuevo formato de empaquetado que se presentó con la actualización de octubre de 2018 de Windows 10. El objetivo es reunir lo mejor de las tecnologías de instalación anteriores, como MSI y ClickOnce, para obtener el método recomendado de instalación de aplicaciones en Windows a partir de ahora. En este artículo se muestra cómo empaquetar una aplicación de escritorio de .NET y cómo configurar la integración continua (CI), la implementación continua (CD) y las actualizaciones automáticas de paquetes MSIX de los que se ha realizado una instalación de prueba mediante Azure Pipelines.

En primer lugar, un poco de información sobre el asunto. En Windows 8, Microsoft introdujo una combinación de API y tiempo de ejecución denominada Windows Runtime, que buscaba principalmente ofrecer un conjunto de servicios de plataforma para un nuevo tipo de aplicación, que originalmente se denominaba "moderna", "Metro", "envolvente" o simplemente una aplicación de "Windows Store". Este tipo de aplicación surgió de la revolución de los dispositivos móviles y solía estar destinado a varios factores de forma de dispositivo, como teléfonos, tabletas y equipos portátiles. Se solía instalar y actualizar desde la aplicación central de Microsoft Store.

Esta clase de aplicación ha evolucionado bastante desde entonces y ahora se conoce como una aplicación para la Plataforma universal de Windows (UWP). Las aplicaciones para UWP se ejecutan en un espacio aislado denominado AppContainer que se aísla de otros procesos. Explícitamente, declaran funcionalidades para exigir los permisos necesarios para funcionar correctamente y, es el usuario quien decide si se deben aceptar estas funcionalidades. Se contrapone a una aplicación de escritorio tradicional, que normalmente se ejecuta como un proceso de plena confianza con los permisos de lectura y escritura completos del usuario actual.

En la Actualización de aniversario de Windows 10, Microsoft introdujo el kit Puente de dispositivo de escritorio (también conocido como proyecto Centennial). Le permite empaquetar una aplicación de escritorio tradicional como una aplicación para UWP y seguir ejecutándola como un proceso de plena confianza. Una aplicación empaquetada se puede cargar en Microsoft Store o en Microsoft Store para Empresas y beneficiarse de las prestaciones de implementación optimizada, licencias integradas y actualizaciones automáticas que proporciona la tienda. Una vez que haya empaquetado la aplicación, también puede empezar a usar las nuevas API de Windows 10 y migrar el código a la plataforma UWP para llegar a los clientes en todos los dispositivos.

Aunque no esté interesado en el Store o en la plataforma UWP, puede empaquetar las aplicaciones de escritorio de línea de negocio para aprovechar las ventajas del nuevo modelo de aplicación que ofrece Windows 10. Proporciona instalaciones limpias y desinstalaciones de aplicaciones al redirigir automáticamente todas las operaciones en el registro y algunas carpetas del sistema conocidas a una carpeta local de la aplicación instalada, donde se configuran un sistema de archivos virtual y el registro. No tiene que hacer nada en el código fuente para que esto suceda, Windows se encarga de ello automáticamente. La idea es que cuando se desinstala un paquete, se elimina toda la carpeta local, sin dejar rastro de la aplicación en el sistema.

MSIX es básicamente un sucesor para el Puente de dispositivo de escritorio. Además, el contenido de un paquete MSIX y las limitaciones que se aplican a las aplicaciones empaquetadas son prácticamente iguales que con el formato APPX que se usa en el Puente de dispositivo de escritorio. Los requisitos se enumeran en la documentación oficial en bit.ly/2OvCcVW y deben atenderse antes de decidir si se deben empaquetar las aplicaciones. Algunos de ellos se aplican solo a las aplicaciones que se publican en el Store.

MSIX incorpora una nueva característica denominada paquetes de modificación. Es un concepto similar a las transformaciones de MST, que permite a los administradores de TI personalizar una aplicación, normalmente de un proveedor de terceros, sin tener que volver a empaquetarla desde el principio cada vez que se lance una nueva característica o corrección de errores. El paquete de modificación se combina con la aplicación principal en tiempo de ejecución y puede deshabilitar algunas características de la aplicación, por ejemplo, mediante la alteración de algunas configuraciones del registro. Desde el punto de vista de un desarrollador, esto podría no aportar mucho a la tabla, suponiendo que posee el código fuente y las canalizaciones de compilación y versión para las aplicaciones, pero para grandes empresas puede reducir los costos y evitar que lo que se conoce como parálisis del paquete.

La definición del formato MSIX es código abierto en GitHub y Microsoft tiene previsto proporcionar un SDK que pueda usarse para empaquetar y desempaquetar los paquetes MSIX en todos los sistemas operativos principales, incluidos Linux y macOS. Oficialmente, MSIX se introdujo con la versión 1809 de Windows 10 en octubre de 2018 y, posteriormente, Microsoft agregó compatibilidad con este en las siguientes versiones anteriores: actualización de abril de 2018 (versión 1803) y October 2017 Fall Creators Update (versión 1709).

Empaquetado

Si tiene un instalador existente, existe una herramienta de empaquetado MSIX disponible en el Store que le permite la conversión a MSIX. Esto permite a los administradores empaquetar aplicaciones existentes sin necesidad de acceso al código fuente original. Para los desarrolladores, Visual Studio 2017, versión 15.5 y posteriores, proporciona el Proyecto de paquete de aplicación de Windows, que simplifica el proceso de empaquetado de una aplicación existente. Lo encontrará en Archivo | Agregar | Nuevo proyecto | Instalado | Visual C# | Universal de Windows. Incluye una carpeta Aplicación en la que puede hacer clic con el botón derecho en el Explorador de soluciones y elegir la opción para agregar una referencia a su proyecto de Windows Presentation Foundation (WPF), Windows Forms (WinForms) o cualquier proyecto de escritorio que quiera empaquetar. Si posteriormente hace clic con el botón derecho en la aplicación de referencia y elige Establecer como punto de entrada, podrá compilar, ejecutar y depurar la aplicación como suele hacerlo.

La diferencia entre iniciar el proceso de escritorio original y el proyecto de con el proyecto de empaquetado es que este último ejecutará la aplicación en un contenedor de aplicaciones moderno. En segundo plano, Visual Studio usa las herramientas de línea de comandos MakeAppx y SignTool de Windows SDK para crear un archivo .msix file y, posteriormente, firmarlo con un certificado. Este paso no es opcional. Todos los paquetes MSIX deben firmarse con un certificado vinculado a una entidad de certificación raíz de confianza en la máquina donde se va a instalar y ejecutar la aplicación empaquetada.

Firma digital El proyecto de empaquetado incluye un archivo de formato de intercambio de información personal (PFX) predeterminado protegido mediante contraseña que puede reemplazar por uno propio. Si su empresa no le proporciona un certificado de firma de código, puede adquirir uno a través de una autoridad de confianza o crear un certificado autofirmado. Existe una opción "Crear certificado de prueba" y un asistente para importación en Visual Studio, que encontrará si abre el archivo Package.appxmanifest en el diseñador de manifiestos de aplicaciones predeterminado y busca en la pestaña Empaquetado. Si no lo encuentra los asistentes y cuadros de diálogo, puede usar el cmdlet de PowerShell New-SelfSignedCertificate para crear un 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')

El cmdlet genera una huella digital (A27...D9F en este ejemplo) que puede pasar a otro cmdlet, Move-Item, para mover el certificado al almacén de certificados raíz de confianza:

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

De nuevo, debe instalar el certificado en este almacén en todos los equipos donde se va a instalar y ejecutar la aplicación empaquetada. También debe habilitar la instalación de prueba de aplicaciones en estos dispositivos. En un equipo no administrado, esto puede hacerse en Actualización y seguridad | Para programadores en la aplicación Configuración. En un dispositivo administrado por una organización, puede activar la instalación de prueba mediante la inserción de una directiva con un proveedor de administración de dispositivos móviles (MDM).

La huella digital también puede usarse para exportar el certificado a un nuevo archivo PFX mediante el 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

Recuerde indicar a Visual Studio que use el archivo PFX generado para firmar el paquete MSIX, para lo cual debe seleccionarlo en la pestaña Empaquetado del diseñador, o bien editar manualmente el archivo de proyecto .wapproj y reemplazar los valores de los elementos <PackageCertificateKeyFile> y <PackageCertificateThumbprint>.

Manifiesto del paquete El archivo Package.appxmanifest es una plantilla basada en XML que se usa en el proceso de compilación para generar un archivo AppxManifest.xml firmado digitalmente, que incluye toda la información que el sistema operativo necesita para implementar, mostrar y actualizar la aplicación empaquetada. Aquí es donde se especifican el nombre para mostrar y el logotipo de la aplicación, tal y como aparecerá en el shell de Windows una vez instalada la aplicación.

Asegúrese de que la propiedad Subject del certificado que usa para firmar el paquete MSIX coincide exactamente con el valor del atributo Publisher del elemento Identity. Dado que una aplicación de escritorio empaquetada puede ejecutarse solo en dispositivos de escritorio, también debe quitar el elemento TargetDeviceFamily con el nombre Windows.Universal del elemento Dependencies de la plantilla predeterminada que genera Visual Studio.

Los atributos MinVersion y MaxVersionTested, o Versión mínima y Versión de destino, como se denominan en el cuadro de diálogo que aparece cuando se crea un proyecto de empaquetado, son un concepto de UWP en que el primero especifica la versión más antigua del sistema operativo con el que es compatible la aplicación y el segundo se usa para identificar el conjunto de API que están disponibles cuando se compila la aplicación. Al empaquetar aplicaciones de escritorio que no llaman a ninguna API de Windows 10, debe seleccionar la misma versión. Si no lo hace, el código debe incluir comprobaciones de API en tiempo de ejecución para evitar las excepciones cuando se ejecuta la aplicación en dispositivos que tienen como destino la versión mínima.

Para generar el paquete MSIX real, existe un asistente disponible en Proyecto | Store | Crear paquetes de aplicaciones en Visual Studio. Para instalar un paquete MSIX, el usuario final solo tiene que hacer doble clic en el archivo .msix generado. Se abre un cuadro de diálogo integrado no personalizable, que se muestra en la Figura 1, que le guía en el proceso de instalación de la aplicación.

Figura 1 Instalador de la aplicación y experiencia de instalación de MSIX en Windows 10

Integración continua

Si quiere configurar la integración continua para sus paquetes MSIX, Azure Pipelines ofrece un buen soporte. Admite la configuración como código (CAC) mediante el uso de archivos YAML y proporciona un agente de compilación hospedado en la nube, que incluye todo el software necesario para crear paquetes MSIX preinstalados.

Antes de compilar el proyecto de empaquetado como lo hace el asistente en Visual Studio mediante la línea de comandos de MSBuild, el proceso de compilación puede versionar el paquete MSIX que se está generando con la edición del atributo Version del elemento Package de archivo Package.appxmanifest. En Azure Pipelines, esto puede lograrse mediante una expresión para establecer una variable de contador que se incrementa para cada compilación y un script de PowerShell que usa la clase System.Xml.Linq.XDocument en .NET para cambiar el valor del atributo. La Figura 2 muestra un ejemplo del archivo YAML que versiona y crea un paquete MSIX basado en un proyecto de empaquetado antes de copiarlo en un directorio de almacenamiento provisional en el agente de compilación.

Figura 2 Archivo YAML que define la canalización de compilación de 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'

El nombre de la máquina virtual hospedada que ejecuta Visual Studio 2017 en Windows Server 2016 es vs2017-win2016. Tiene las cargas de trabajo de desarrollo de UWP y .NET necesarias instaladas, incluido SignTool, que se usa para firmar el paquete MSIX una vez creado mediante MSBuild. Tenga en cuenta que el archivo PFX no debería agregarse al control de código fuente. Git también lo omite de forma predeterminada. En su lugar, debe cargarse en Azure Pipelines como un archivo secreto en la pestaña Biblioteca en el portal web. Dado que incluye la clave privada del certificado que representa la firma digital y la identidad de su empresa, no debe distribuirla a más personas de las necesarias.

En grandes empresas donde puede publica software en varios entornos y distintas fases, se considera un procedimiento recomendado firmar los paquetes como parte del proceso de lanzamiento y permitir que la canalización de compilación genere paquetes sin firmar. Esto no solo le permite firmar con certificados diferentes para distintos entornos, sino que también le ofrece la capacidad para cargar los paquetes en Store, donde se firmarán mediante un certificado de Microsoft.

Tenga en cuenta también que los secretos, como la contraseña del archivo PFX, no deberían incluirse en el archivo YAML. A diferencia de las variables que especifican la arquitectura del procesador de destino y la versión del paquete, se definen y establecen en la interfaz web.

La Figura 3 muestra el Explorador de soluciones para una aplicación WPF que se creó mediante la plantilla de proyecto predeterminada en Visual Studio y empaquetó mediante un proyecto de paquete de aplicación de Windows. El archivo YAML se ha agregado al proyecto de empaquetado y está protegido en un repositorio de código fuente junto con el resto del código.

Figura 3 Aplicación WPF empaquetada que se insertará en el control de código fuente

Para configurar la canalización de compilación real, vaya al portal de Azure DevOps en dev.azure.com/<organización> y cree un nuevo proyecto. Si no tiene una cuenta, puede crear una de forma gratuita. Una vez que haya iniciado sesión y creado un proyecto, puede insertar el código fuente en el repositorio de Git que configurado automáticamente en https://<organización>@dev.azure.com/<organización>/<proyecto>/_git/<proyecto> o usar cualquier otro proveedor, como GitHub. Podrá elegir la ubicación del repositorio cuando cree una nueva canalización en el portal. Para ello, deberá hacer clic primero en el botón "Canalizaciones" y, a continuación, en "Nueva canalización".

En la pantalla Configurar que aparece a continuación, debe seleccionar la opción "Archivo YAML de Azure Pipelines existente" y seleccionar la ruta de acceso al archivo YAML protegidos en el repositorio, como se muestra en la Figura 4.

Figura 4 Interfaz web de configuración de canalizaciones

El paquete MSIX generado por la compilación se puede descargar e instalar mediante un doble clic en cualquier equipo compatible con Windows 10 con el certificado necesario instalado. También puede configurar una canalización de CD que copie el paquete en un sitio web o un recurso compartido de archivos donde sus usuarios finales puedan descargarlo. Seguiré con esto dentro de un momento.

Actualizaciones automáticas Aunque un paquete MSIX puede extraer por si mismo y reemplazar automáticamente cualquier versión anterior de la aplicación empaquetada presente en la máquina al instalarlo, el formato MSIX no ofrece soporte técnico integrado para actualizar automáticamente una aplicación que ya se ha instalado al abrir un archivo .msix.

No obstante, a partir de abril de la actualización de abril de 2018 de Windows 10, se ofrece soporte técnico para un archivo instalador de la aplicación, que puede implementar junto con el paquete para habilitar las actualizaciones automáticas. Contiene un elemento MainPackage cuyo atributo Uri hace referencia al paquete MSIX original o a uno actualizado. La Figura 5 muestra un ejemplo de un archivo .appinstaller mínimo. Tenga en cuenta que el atributo Uri del elemento raíz especifica una dirección URL o una ruta de acceso UNC a un recurso compartido de archivos donde el sistema operativo buscará los archivos actualizados. Si el URI es diferente entre una versión instalada actualmente y un nuevo archivo instalador de la aplicación, la operación de implementación le redirigirá al URI "antiguo".

Figura 5 Archivo .appinstaller que buscará archivos actualizados en \\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>

El elemento UpdateSettings se utiliza para indicar al sistema cuándo buscar actualizaciones y si se debe forzar al usuario a realizar la actualización. La referencia del esquema completo, incluidos los espacios de nombres admitidos para cada versión de Windows 10, puede encontrarse en los documentos de bit.ly/2TGWnCR.

Si agrega el archivo .appinstaller de la Figura 5 al proyecto de empaquetado y establece la propiedad Acción de paquete en Contenido y la propiedad Copiar en el directorio de salida en Copiar si es posterior, puede agregar otra tarea de PowerShell al archivo YAML que actualiza los atributos Version de la raíz y los elementos MainPackage, y guarda el archivo actualizado en el directorio de almacenamiento provisional:

- 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'

A continuación, puede distribuir el archivo .appinstaller a los usuarios finales y permitirles hacer doble clic en este en lugar de en el archivo .msix para instalar la aplicación empaquetada.

Implementación continua

El propio archivo instalador de la aplicación es un archivo XML sin compilar que se puede editar después de la compilación, si es necesario. De este modo, es más fácil de usar al implementar el software en varios entornos y cuando quiere separar la canalización de compilación del proceso de lanzamiento.

Si crea una canalización de versiones en el Azure Portal mediante la plantilla "Fase vacía" y usar la canalización de compilación configurada recientemente como el origen del artefacto que se va a implementar, como se muestra en la Figura 6. A continuación, puede agregar la tarea de PowerShell de la Figura 7 a la fase de lanzamiento con el fin de cambiar de forma dinámica los valores de los dos atributos Uri del archivo .appinstaller para reflejar la ubicación donde está publicada la aplicación.

Figura 6 Pestaña Canalización en el portal de Azure DevOps

Figura 7 Tarea de canalización de versión que modifica los URI en el archivo .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'

En la tarea de la Figura 7, el URI está establecido en la ruta de acceso UNC de un recurso compartido de archivos de Azure. Dado que aquí es donde el sistema operativo buscará el paquete MSIX al instalar y actualizar la aplicación, también agregué otro script de línea de comandos a la canalización de versiones, que asigna el recurso compartido de archivos en la nube a la unidad Z:\ local en el agente de compilación antes de usar el comando xcopy para copiar allí los archivos .appinstaller y .msix:

- 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'

Si hospeda su propia instancia de Azure DevOps Server local, puede publicar los archivos en su propio recurso compartido de red interno.

Instalaciones web Si decide realizar una publicación en un servidor web, puede indicar a MSBuild que genere un archivo .appinstaller con control de versiones y una página HTML que contenga un vínculo de descarga y cierta información sobre la aplicación empaquetada. Para ello, debe proporcionar algunos argumentos adicionales en el archivo 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'

La Figura 8 muestra el contenido del directorio de almacenamiento provisional en el agente de compilación después de ejecutar el comando anterior. Es el mismo resultado que obtiene del asistente en Visual Studio si opta por crear paquetes para la instalación de prueba y marca la casilla "Habilitar las actualizaciones automáticas". Con este enfoque, puede quitar el archivo .appinstaller creado manualmente, a costa de cierta flexibilidad respecto a la configuración del comportamiento de actualización.

Figura 8 Explorador de artefactos de compilación en el portal de Azure DevOps

El archivo HTML generado incluye un hipervínculo prefijado con el esquema de activación de protocolos ms-appinstaller independiente del explorador:

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

Si ha configurado una canalización de versión que publica el contenido de la carpeta de entrega en la intranet o cualquier otro sitio web, y el servidor web es compatible con las solicitudes de intervalo de bytes y está configurado correctamente, los usuarios finales pueden usar este vínculo para instalar directamente la aplicación sin descargar primero el paquete MSIX.

Resumen

En este artículo, hemos visto lo fácil que es empaquetar una aplicación de escritorio de .NET como un paquete MSIX con Visual Studio. También hemos visto cómo configurar canalizaciones de CI y CD en Azure Pipelines, y cómo configurar actualizaciones automáticas. MSIX es el método moderno para implementar aplicaciones en Windows. Está diseñado para ser seguro y confiable, y permite que tanto usted como sus clientes aprovechen el nuevo modelo de aplicación y las API modernas que se han introducido en Windows 10, independientemente de si va a cargar las aplicaciones en Microsoft Store o a realizar una instalación de prueba de estas en los equipos de su empresa. Siempre y cuando todos los usuarios hayan cambiado a Windows 10, debe poder aprovechar MSIX para empaquetar la mayoría de las aplicaciones de escritorio de Windows que están disponibles.

Magnus Montin es MVP de Microsoft que trabaja como desarrollador de software por cuenta propia y consultor en Estocolmo, Suecia. Está especializado en .NET y la pila de Microsoft, y tiene más de una década de experiencia práctica. Puede leer su blog en blog.magnusmontin.net.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: Matteo Pagani (Matteo.Pagani@microsoft.com)
Matteo Pagani es un desarrollador con una gran pasión por el desarrollo del cliente y la plataforma Windows. Suele dar conferencias en todo el mundo, es autor de libros y escribe con regularidad artículos técnicos para blogs y sitios web de ámbito tecnológico. Fue MVP de Microsoft en la categoría de desarrollo de Windows durante un período de 5 años, tras el cual se unió a Microsoft como ingeniero en el equipo de Windows AppConsult.

Comente este artículo en el foro de MSDN Magazine