- MSIX unifica y moderniza el empaquetado de aplicaciones Windows heredando ventajas de MSI y AppX con tecnología de contenedores.
- Visual Studio y MSIX Packaging Tool permiten crear, convertir y firmar paquetes MSIX para múltiples arquitecturas y escenarios.
- La validación con WACK, el uso de PSF y la automatización con MSBuild y Azure AD mejoran la calidad y el despliegue continuo.
- MSIX app attach y los contenedores VHD/CIM facilitan imágenes ligeras y entrega dinámica de aplicaciones en entornos modernos.
Si trabajas con despliegue de software en entornos Windows, tarde o temprano te vas a topar con MSIX como formato estándar de empaquetado de aplicaciones. Ya sea para publicar en Microsoft Store, hacer despliegues con Intune, automatizar instalaciones remotas o modernizar aplicaciones heredadas, entender bien cómo funciona MSIX te ahorrará muchos quebraderos de cabeza.
En las siguientes líneas vas a encontrar una guía muy completa sobre cómo empaquetar aplicaciones con MSIX usando Visual Studio, MSIX Packaging Tool y las herramientas de proyecto único de WinUI 3, además de conceptos clave como MSIX app attach, contenedores VHD/CIM, validación con WACK, automatización de builds y el papel de Package Support Framework. Todo explicado con lenguaje llano y ejemplos prácticos para que puedas aplicarlo en tu día a día.
Qué es MSIX y en qué se diferencia de MSI, EXE y AppX
MSIX es el formato de instalación moderno que Microsoft propone como sustituto natural de EXE, MSI y AppX, heredando lo mejor de cada uno y añadiendo tecnología de contenedores para aislar la aplicación del sistema operativo.
Frente a los clásicos instaladores MSI, que son estupendos para instalaciones simples y desatendidas pero dejan fácilmente archivos y claves de registro huérfanas, MSIX mantiene la idea de empaquetar todos los recursos de la app pero con reglas estrictas sobre dónde se escriben los datos y cómo se eliminan después.
Comparado con un instalador EXE, mucho más flexible y personalizable en interfaz y lógica de instalación, MSIX sacrifica parte de esa libertad en favor de una instalación predecible, limpia y altamente automatizable, algo clave cuando tienes que gestionar cientos o miles de equipos.
En relación con AppX, el formato propio de las aplicaciones UWP, MSIX mantiene el modelo de contenedor y las actualizaciones limpias, pero elimina la gran limitación de AppX: ya no dependes solo de Microsoft Store ni del mundo UWP. Ahora puedes empaquetar Win32, WPF, WinForms y aplicaciones clásicas bajo MSIX, distribuirlas fuera de la tienda y seguir aprovechando el aislamiento y la limpieza de desinstalación.
La clave está en que MSIX instala la aplicación en un contenedor (habitualmente bajo C:\Program Files\WindowsApps) y controla de forma precisa cómo interactúa con el sistema de archivos y el registro. Al desinstalar, todo el contenido del contenedor (y los recursos asociados) se elimina sin dejar restos, mejorando la estabilidad a largo plazo del sistema.
Tipos de paquetes: MSIX, bundle y archivos de carga
Cuando hablamos de empaquetar aplicaciones con MSIX conviene distinguir varios tipos de archivos, porque cada uno cumple un rol concreto en el ciclo de vida de la app.
Por un lado tenemos el paquete de aplicación MSIX o APPX individual (.msix o .appx), que contiene la aplicación compilada y sus recursos para una sola arquitectura: x86, x64, ARM, etc. Si quieres cubrir varias arquitecturas, necesitas generar un paquete por cada una de ellas.
En escenarios donde buscas abarcar el mayor número posible de dispositivos, lo ideal es crear un paquete de aplicaciones (bundle) con extensión .msixbundle o .appxbundle. Este bundle incluye varios paquetes MSIX individuales, uno por arquitectura, y permite que el sistema elija automáticamente cuál instalar en función del hardware.
Cuando el objetivo es publicar en Microsoft Store, entra en juego el archivo de carga de paquete de aplicación (.msixupload o .appxupload). Este archivo puede agrupar uno o varios paquetes o bundles y, además, incluye los símbolos necesarios (.appxsym) para el análisis de rendimiento y bloqueos desde el Centro de partners.
En la práctica, lo habitual es usar MSIX o bundle para distribución interna (web, Intune, Configuration Manager, scripts, etc.) y .msixupload cuando vas a certificar y publicar la aplicación en la tienda de Microsoft.
Preparativos antes de empaquetar con MSIX
Antes de ponerte a generar paquetes, conviene asegurarte de que la aplicación está lista para ser empaquetada y distribuida en las plataformas objetivo. Si este paso se ignora, luego aparecen sorpresas en producción.
Lo primero es probar a fondo la aplicación en todas las familias de dispositivos que tengas previsto soportar: escritorio, Xbox, Surface Hub, IoT, etc. Si la app está pensada para UWP o para escritorio empaquetado, puedes apoyarte en Visual Studio para despliegue y depuración directa en los distintos targets.
El segundo punto clave es la optimización de rendimiento. Visual Studio dispone de herramientas de perfiles como la línea de tiempo de UI, el analizador de uso de memoria o el inspector de CPU que permiten pulir cuellos de botella antes de congelar el paquete MSIX que acabará llegando al usuario final.
En proyectos VB o C# que usan la Plataforma universal de Windows entra en juego .NET Native. La compilación en modo Release activa automáticamente este compilador nativo, por lo que debes probar sí o sí en esa configuración y confirmar que no aparecen diferencias de comportamiento respecto a Debug.
Por último, en entornos de empaquetado “limpio” con MSIX Packaging Tool se recomienda trabajar en máquinas donde ciertos servicios estén deshabilitados (Windows Update, Windows Search, SMS Host, etc.) para que no contaminen la captura de la instalación, especialmente al convertir aplicaciones Win32 clásicas.
El manifiesto Package.appxmanifest y la configuración del proyecto
En cualquier aplicación empaquetada con MSIX, el archivo crítico es Package.appxmanifest, un XML que describe identidad, capacidades, asociaciones y aspecto visual de la app. Es, literalmente, el “DNI” del paquete.
Dentro del manifiesto se definen propiedades como el nombre del paquete, el publisher, la versión, la imagen de icono, las orientaciones de pantalla admitidas, las asociaciones de archivo, protocolos personalizados, tareas en segundo plano, alias de ejecución, etc.
Visual Studio incorpora un diseñador visual de manifiestos que evita tener que editar el XML a mano. Desde el Explorador de soluciones basta con hacer doble clic en Package.appxmanifest para abrir pestañas como “Recursos visuales” (iconos y logotipos) o “Empaquetado” (datos de publicación y certificado de firma).
En la pestaña de recursos visuales tendrás que proporcionar todos los tamaños de icono requeridos por Windows: el sistema usa distintos logos para barra de tareas, menú inicio, lista de apps, notificaciones toast, etc., por lo que es importante cubrir todas las variantes para evitar que la interfaz se vea pobre o inconsistente.
En la pestaña de empaquetado se configura qué certificado se usará para firmar el MSIX. Toda aplicación MSIX debe ir firmada con un certificado de confianza para el dispositivo donde se instala; si no, el sistema rechazará el paquete o mostrará advertencias de seguridad.
Empaquetar aplicaciones MSIX desde Visual Studio
Si tu proyecto está en Visual Studio, empaquetar con MSIX es bastante directo gracias al Asistente para crear paquetes de aplicaciones, que guía todo el proceso desde la selección del tipo de distribución hasta la generación del archivo final.
El flujo típico consiste en abrir la solución, hacer clic derecho sobre el proyecto y elegir Publicar → Crear paquetes de aplicaciones. Dependiendo de la versión de Visual Studio y del tipo de proyecto, el texto del menú puede variar ligeramente, pero la idea es siempre lanzar el asistente de empaquetado.
En la primera pantalla tendrás que decidir si quieres crear un paquete para carga lateral (sideloading) o para Microsoft Store. La carga lateral es la opción adecuada para pruebas internas, despliegue con Intune, Configuration Manager o scripts propios sin pasar por la tienda.
El siguiente paso es escoger el método de firma. Puedes omitir la firma (solo útil en escenarios muy controlados), seleccionar un certificado del almacén local, apuntar a un archivo .pfx o crear un certificado nuevo. Para instalaciones en equipos de usuario final, ese certificado debe ser de confianza para el sistema, ya sea porque procede de una CA reconocida o porque has importado manualmente su raíz.
Finalmente, en la pantalla de “Seleccionar y configurar paquetes” defines qué arquitecturas vas a generar (x86, x64, ARM, arm64, etc.) y si quieres crear un bundle. En escenarios de Store, la recomendación es marcar todas las arquitecturas relevantes y establecer que siempre se genere un paquete de aplicaciones (bundle).
Instalación y prueba de paquetes MSIX
Una vez creado el paquete, llega el momento de instalarlo y comprobar que la aplicación se comporta como se espera en los distintos escenarios de uso. Aquí tienes varias opciones, desde el doble clic hasta scripts de PowerShell.
En el caso más sencillo, basta con localizar el archivo .msix o .msixbundle y hacer doble clic en él. Esto lanzará el instalador de aplicaciones de Windows, que muestra información básica del paquete (nombre, publisher, permisos) y una barra de progreso de instalación.
Cuando necesitas automatizar la instalación en entornos de desarrollo o laboratorio, Visual Studio crea junto al paquete una carpeta *_Test que incluye el script Add-AppDevPackage.ps1. Ejecutándolo con “Ejecutar con PowerShell” puedes instalar el paquete de desarrollo y ver en consola si todo ha ido bien.
En escenarios más avanzados y completamente automatizados puedes recurrir directamente a cmdlets de PowerShell como Add-AppxPackage, Get-AppxPackage o Remove-AppxPackage para instalar, inspeccionar y desinstalar MSIX sin intervención del usuario.
Para validar la compatibilidad con Microsoft Store y las políticas de certificación de Windows, el paso recomendado es lanzar el Kit de certificación de aplicaciones de Windows (WACK) desde la última pantalla del asistente de empaquetado, eligiendo si las pruebas se ejecutan en la máquina local o en un dispositivo remoto.
Creación de archivos .msixupload para Microsoft Store
Cuando tu objetivo es publicar la app en Microsoft Store, lo que espera el Centro de partners no es el paquete MSIX suelto, sino un archivo de carga .msixupload (o .appxupload) que agrupa paquetes y símbolos.
De nuevo, Visual Studio simplifica este proceso con el mismo asistente de empaquetado. En la primera pantalla deberás escoger Microsoft Store con un nuevo nombre de aplicación (o vincularla a una app ya asociada) y después iniciar sesión con la cuenta de desarrollador del Centro de partners.
Tras reservar o seleccionar el nombre de la aplicación, el asistente te permitirá elegir todas las arquitecturas necesarias (x86, x64, ARM, arm64) y obligar a la creación de un bundle. Esta configuración garantiza que el archivo de carga contenga un conjunto coherente de paquetes aptos para la mayoría de dispositivos.
Además, puedes indicar que se incluyan símbolos públicos en forma de archivo .appxsym, lo que permite a Microsoft y a tu propio equipo diagnosticar bloqueos y problemas de rendimiento desde el portal del Centro de partners una vez publicada la app.
Al pulsar “Crear”, el asistente generará el paquete o bundle junto con el archivo de carga .msixupload. Ese es el archivo que tendrás que subir en el flujo de envío del Centro de partners para comenzar el proceso de certificación y publicación.
Creación manual de un archivo de carga MSIX
Si por cualquier motivo no quieres depender de Visual Studio para crear el archivo de carga, es posible montar un .msixupload de forma manual a partir de archivos ya existentes.
La receta consiste en reunir en una misma carpeta uno o varios paquetes MSIX o AppX (o bien un bundle .msixbundle), junto a un archivo .appxsym con los símbolos públicos de la aplicación. Aunque el archivo de símbolos es opcional, renunciar a él implica perder la capacidad de análisis de fallos en el Centro de partners.
Una vez tengas esos archivos, solo necesitas comprimirlos en un ZIP desde el explorador de archivos (Enviar a → Carpeta comprimida). El último paso es cambiar la extensión de .zip a .msixupload (o .appxupload, según corresponda).
Siempre que el contenido sea coherente (paquetes válidos y símbolos correctos) el Centro de partners aceptará ese archivo manual igual que si lo hubiese generado Visual Studio, por lo que es una opción útil en flujos de integración continua sin IDE.
Validación de paquetes MSIX en local y en remoto
Antes de subir nada a la tienda o desplegar a gran escala, es fundamental validar los paquetes MSIX con el Kit de certificación de aplicaciones de Windows, tanto en equipo local como en dispositivos remotos.
El lanzador más cómodo es el propio asistente de Visual Studio: al terminar la creación del paquete puedes marcar la opción de ejecutar WACK en la máquina local y se abrirá automáticamente el conjunto de pruebas recomendadas.
Estas pruebas analizan desde el uso de APIs no permitidas hasta problemas de rendimiento, consumo excesivo de recursos, errores de empaquetado y otros aspectos que después revisará el proceso automático de certificación de Microsoft Store.
Si necesitas validar en otra máquina (por ejemplo, un dispositivo Windows 10 con hardware específico), tendrás que instalar allí el Kit de certificación y las herramientas remotas de Visual Studio. Una vez configurado, el asistente permite seleccionar “Máquina remota”, introducir la dirección o nombre DNS, escoger el modo de autenticación y lanzar las pruebas remotamente.
Cuando el paquete supera WACK, ya puedes localizar el archivo .msixupload generado en la ruta \[AppName]\AppPackages de la solución y utilizarlo para el envío definitivo al Centro de partners o para tus pipelines de despliegue automatizado.
Automatizar envíos a Microsoft Store desde Visual Studio
Con Visual Studio 2019 y posteriores puedes ir un paso más allá y automatizar el envío a Microsoft Store nada más terminar la validación con WACK, sin necesidad de entrar manualmente al portal web del Centro de partners.
En la pantalla final del asistente tienes la casilla “Enviar automáticamente a Microsoft Store después de la validación”, que aprovecha Azure Active Directory (Azure AD) para autenticar contra la cuenta de desarrollador y lanzar el envío.
Para utilizar esta característica tendrás que asociar previamente tu cuenta del Centro de partners con un inquilino de Azure AD de tu organización, crear (o vincular) una aplicación de Azure AD con rol de Administrador y recuperar tres datos críticos: identificador de inquilino, identificador de cliente y clave de cliente.
Esos valores se configuran una única vez en Visual Studio en el cuadro de diálogo de opciones de envío de la Store. A partir de ahí, cada vez que marques la opción de envío automático, el IDE tomará el archivo .msixupload generado y lo enviará al Centro de partners cuando WACK dé luz verde.
Este flujo es especialmente útil en equipos que publican versiones con frecuencia o que quieren integrar el empaquetado MSIX con pipelines de CI/CD donde la intervención humana se reduzca al mínimo imprescindible.
MSIX Packaging Tool: convertir aplicaciones de escritorio a MSIX
Cuando la aplicación que quieres desplegar no nació pensada para MSIX, entra en escena MSIX Packaging Tool, la utilidad oficial de Microsoft para convertir instaladores de escritorio tradicionales al formato moderno.
Esta herramienta se puede instalar desde Microsoft Store, vía línea de comandos con WinGet (winget install "MSIX Packaging Tool") o incluso obtenerla en versión offline para escenarios sin conexión usando PowerShell para añadir el paquete y su licencia.
Los requisitos mínimos incluyen Windows 10 versión 1809 o superior, permisos de administrador y, en algunos casos, pertenecer al programa Windows Insider. Una vez instalada, puedes alimentar la herramienta con instaladores .exe, .msi, paquetes App-V 5.x o incluso escenarios Click-Once.
El flujo típico de conversión consiste en lanzar la herramienta, elegir “Crear paquete de aplicación”, seleccionar si se empaqueta en el propio equipo, en una máquina remota o en una máquina virtual, y luego apuntar al instalador original junto con los posibles parámetros silenciosos.
Durante la instalación monitorizada, MSIX Packaging Tool captura cambios en archivos y registro, identifica puntos de entrada (ejecutables), recopila servicios, tareas de inicio, etc., y finalmente genera un MSIX listo para desplegar firmado con el certificado que hayas configurado.
Package Support Framework, PSFTooling y soluciones a apps problemáticas
No todas las aplicaciones Win32 antiguas se comportan bien en un contenedor MSIX desde el primer día; a veces aparecen problemas de redirección de archivos, accesos al registro o permisos que impiden que la app funcione correctamente tras la conversión.
Para esas situaciones existe Package Support Framework (PSF), un conjunto de interceptores y correcciones en tiempo de ejecución que permite adaptar el comportamiento de la aplicación dentro del contenedor sin modificar el binario original.
Entre las correcciones típicas están los file redirections (cuando la aplicación espera escribir en rutas que no son válidas en MSIX) o los registry fixes que permiten simular accesos al registro de una forma compatible con el modelo de contenedor.
Herramientas como PSFTooling, disponibles en Microsoft Store, prometen facilitar la inyección y configuración de estas soluciones sobre un paquete MSIX ya existente, aunque en la práctica su uso puede resultar poco intuitivo si no se dispone de una guía detallada.
En contextos como la empaquetación de apps complejas para Intune, es habitual combinar MSIX Packaging Tool + PSF, ya sea mediante paquetes NuGet con componentes de PSF o usando herramientas específicas para añadir las DLLs y configurar los JSON de corrección necesarios.
MSIX app attach, VHD/CIM y despliegue moderno de aplicaciones
Un avance especialmente interesante en entornos de escritorios virtuales es MSIX app attach, un mecanismo que permite mantener una imagen base muy ligera y “adjuntar” aplicaciones en tiempo de ejecución desde contenedores MSIX.
La idea es que, en lugar de hornear todas las aplicaciones en la imagen de Windows, empaquetas cada una en MSIX y luego la conviertes a un contenedor VHD, VHDX o CIM que se monta dinámicamente en la máquina (física o virtual) donde vaya a ejecutarse.
Los archivos .cim se basan en Composite Image File System (CimFS), un sistema de archivos diseñado para montar y desmontar más rápido y con menor consumo de disco y memoria que los VHD tradicionales, lo que los hace especialmente atractivos en escenarios de alta densidad como Windows Virtual Desktop.
La creación de estos contenedores puede hacerse de manera manual con herramientas como MSIX Manager Tool, copiando el MSIX al directorio de trabajo y ejecutando los comandos necesarios en PowerShell para generar y rellenar el VHD.
También existen utilidades de terceros como AppVentiX (Community Tool) o MSIX Hero que automatizan el proceso de conversión de paquete MSIX a contenedor VHD/CIM, evitando la dependencia de módulos de Hyper-V y simplificando el flujo para administradores menos familiarizados con PowerShell.
MSIX de proyecto único con WinUI 3 y Windows App SDK
En aplicaciones modernas construidas sobre WinUI 3 y Windows App SDK, Microsoft ha introducido el concepto de “MSIX de un solo proyecto”, eliminando la necesidad de tener un proyecto de empaquetado separado en la solución.
Tradicionalmente, si querías una app de escritorio empaquetada, necesitabas el proyecto de aplicación más un proyecto de paquete de aplicaciones de Windows independiente. Eso complicaba un poco la estructura de la solución y obligaba a cambiar de proyecto de inicio para depurar correctamente.
Con las herramientas de empaquetado MSIX de proyecto único, incluidas como extensión en Visual Studio junto con Windows App SDK, puedes crear directamente una “Aplicación vacía, empaquetada (WinUI 3 en escritorio)” donde el propio proyecto genera el MSIX sin ayuda de otro proyecto adicional.
Esta característica admite proyectos C# y C++ de WinUI 3 y tiene una limitación importante: solo soporta un ejecutable por paquete MSIX. Si necesitas agrupar varios ejecutables en el mismo paquete, tendrás que seguir usando el modelo clásico con proyecto de empaquetado.
Al migrar una solución existente a proyecto único, se suelen seguir pasos como mover el manifiesto y los archivos de empaquetado al proyecto principal, ajustar la configuración en el administrador de configuraciones para marcar “Implementar” en todas las combinaciones de compilación y, finalmente, compilar e instalar directamente desde ese único proyecto.
Automatizar compilación y empaquetado con MSBuild
Para entornos de integración continua y despliegue continuo, resulta muy útil automatizar la generación del paquete MSIX a través de la línea de comandos con MSBuild, sin depender del IDE.
En soluciones de proyecto único, la pieza clave es incluir la propiedad /p:GenerateAppxPackageOnBuild=true en la línea de MSBuild. Sin este parámetro, el proyecto se compilará pero no producirá ningún MSIX de salida.
Al habilitar dicha propiedad, cada compilación en la configuración seleccionada generará el paquete MSIX correspondiente siguiendo los ajustes definidos en el manifiesto y en el archivo de proyecto, de modo que puedes integrar fácilmente este paso en pipelines de GitHub Actions, Azure DevOps u otras plataformas CI.
Microsoft proporciona ejemplos completos de flujos de trabajo que compilan y empaquetan proyectos WinUI 3 de un solo proyecto, demostrando que el empaquetado MSIX no tiene por qué ser un paso manual aislado, sino una parte más de tu proceso de build.
Todo este ecosistema de herramientas, desde Visual Studio y MSIX Packaging Tool hasta PSF, WACK y MSIX app attach, convierte a MSIX en una pieza central para desplegar aplicaciones Windows de forma fiable, escalable y moderna, permitiendo a los equipos de desarrollo y administración tener un mayor control sobre instalaciones, actualizaciones, diagnósticos y desinstalaciones sin renunciar a compatibilidad con aplicaciones clásicas ni a la flexibilidad de distribuir fuera de la Store cuando el escenario lo requiere.