- MSIX unifica y moderniza el empaquetado de aplicaciones en Windows, mejorando fiabilidad, limpieza de desinstalación y eficiencia en disco y ancho de banda.
- MSIX Packaging Tool permite convertir instaladores heredados (MSI, EXE, App-V, ClickOnce, scripts) en paquetes MSIX, siempre que se prepare un entorno de captura limpio y controlado.
- Visual Studio genera MSIX directamente desde el código, facilita la creación de bundles y archivos de carga para Store, e integra validación con WACK y envíos automatizados mediante Azure AD.
- Con MSIX app attach y contenedores VHD/CIM es posible desacoplar aplicaciones de la imagen base en entornos de escritorio remoto, simplificando versiones y despliegues.
Si trabajas con despliegue de aplicaciones en Windows, tarde o temprano acabas topándote con el formato MSIX. Este formato se ha convertido en la apuesta fuerte de Microsoft para empaquetar software, y conviene tener claro cómo crear paquetes MSIX de forma correcta y repetible si quieres evitar dolores de cabeza en producción.
En las siguientes líneas vas a encontrar una explicación muy completa, paso a paso, sobre cómo preparar el entorno, convertir instaladores clásicos a MSIX, firmar, validar y distribuir tus paquetes, tanto si usas MSIX Packaging Tool como si trabajas desde Visual Studio o línea de comandos. La idea es que termines con una visión global y práctica, pero sin perder los detalles técnicos importantes.
Qué es MSIX y por qué merece la pena usarlo
MSIX es el formato moderno de empaquetado de aplicaciones para Windows que unifica y mejora tecnologías anteriores como MSI, AppX y App-V. No es solo “otro instalador”: añade aislamiento, gestión más limpia y opciones avanzadas de distribución tanto on‑prem como en la nube.
Entre sus ventajas clave destacan la fiabilidad de instalación y desinstalación (Microsoft habla de tasas de éxito superiores al 99,9%), la capacidad de dejar el sistema “limpio” cuando se desinstala la app y la reducción del espacio en disco gracias a que evita duplicar archivos comunes entre varias aplicaciones.
MSIX está pensado para funcionar bien en escenarios modernos: optimiza el ancho de banda (bloques de 64 KB preparados para distribución desde la nube), se integra con Microsoft Store, con herramientas de gestión como Intune o Configuration Manager, y es compatible con tecnologías como MSIX app attach para entornos de escritorio remoto y Windows 365.
La herramienta principal para convertir instaladores heredados (EXE, MSI, App-V, ClickOnce, scripts…) en paquetes MSIX es MSIX Packaging Tool, disponible en Microsoft Store y también como paquete offline. Además, Visual Studio permite generar directamente MSIX desde el código fuente en proyectos UWP o con proyectos de empaquetado de aplicaciones de Windows.
Rutas para llegar a un paquete MSIX
Antes de ponerte a convertir nada, conviene decidir por qué camino vas a generar tus paquetes. En función de si tienes o no acceso al código fuente, te interesará más un enfoque u otro para crear paquetes MSIX que sean fáciles de mantener.
Si la aplicación está en desarrollo activo y controlas el código, lo ideal es generar el MSIX en el propio proceso de compilación: con Visual Studio (proyectos UWP o de empaquetado de aplicaciones de Windows) o mediante las herramientas de línea de comandos MSIX integradas en tu sistema de build (Azure DevOps, Jenkins, etc.).
En cambio, si te toca lidiar con instaladores heredados ya compilados (MSI, EXE, App-V 5.x, ClickOnce, scripts personalizados…) o incluso con aplicaciones de las que no tienes código, la ruta recomendada es usar MSIX Packaging Tool en una máquina de conversión para capturar la instalación y generar el paquete.
En escenarios de virtualización de escritorios y WVD/Azure Virtual Desktop, además de generar el MSIX, es habitual transformar ese paquete a un contenedor VHD/VHDX o CIM para poder usarlo con MSIX app attach, manteniendo las imágenes base ligeras y “pegando” las apps según el usuario.
Prerrequisitos y preparación del entorno de conversión
Para que la conversión salga bien es fundamental partir de un entorno limpio y controlado. Si el sistema está lleno de software y procesos en segundo plano, la herramienta puede capturar ruido y acabarás con un paquete poco fiable.
Los requisitos mínimos para usar MSIX Packaging Tool son: Windows 10 versión 1809 o posterior, una cuenta Microsoft si vas a instalarla desde la Store, pertenecer al programa Windows Insider solo si usas builds Insider y disponer de privilegios de administrador en la máquina donde ejecutes la herramienta.
Es aconsejable dedicar una máquina (física, VM local con Hyper‑V o equipo remoto) exclusivamente a la captura. La propia herramienta permite elegir si quieres crear el paquete en la máquina actual, en una máquina remota o en una VM de Hyper‑V de tu equipo. Esto facilita mantener imágenes limpias listas para convertir.
Durante la preparación, MSIX Packaging Tool comprueba e intenta activar automáticamente el controlador de empaquetado que necesita para monitorizar la instalación. También puede pausar temporalmente Windows Update y, opcionalmente, detener servicios como Windows Search o el host de SMS para evitar actividad extra que contamine el paquete.
Si hay reinicios pendientes en el sistema, la herramienta te lo indicará. No es obligatorio, pero sí recomendable reiniciar antes de seguir con la captura para que no haya operaciones a medias que afecten a la monitorización.
Instalar y actualizar MSIX Packaging Tool
La forma más habitual de conseguir la herramienta es descargarla desde Microsoft Store con tu cuenta Microsoft. Basta con buscar “MSIX Packaging Tool”, entrar en la ficha del producto e iniciar la instalación. A partir de ahí, se actualizará automáticamente con las nuevas versiones estables.
Si prefieres automatizarlo o trabajar desde consola, puedes instalarla con winget install «MSIX Packaging Tool», lo que facilita mucho el despliegue en entornos administrados o laboratorios.
También existe una variante offline pensada para máquinas sin acceso a la Store, que incluye el paquete de la aplicación y su licencia. En ese caso, añades el paquete al sistema con PowerShell (por ejemplo, mediante Add-AppxProvisionedPackage apuntando a la ruta del MSIX y a la licencia XML).
La herramienta se actualiza con frecuencia. Versiones recientes han mejorado bastante la integración con el Package Support Framework (PSF), que sirve para aplicar correcciones en tiempo de ejecución a aplicaciones que no se portan bien al nuevo modelo de contenedor sin tocar su código.
Elegir tipo de paquete MSIX y entender las variantes
Al trabajar con MSIX no solo hablamos de “un paquete”, sino de varios tipos con usos distintos. Entender estas variantes te ayuda a planificar cómo distribuir e instalar tus aplicaciones en cada escenario.
El formato básico es el paquete de aplicación (.msix o .appx), que contiene la app y sus recursos para una arquitectura concreta (x86, x64, ARM, ARM64…). Si quieres dar soporte a varias arquitecturas, tendrás uno por cada tipo de procesador.
Por encima está la agrupación de aplicaciones (.msixbundle o .appxbundle), que empaqueta en un solo archivo varios paquetes MSIX para distintas arquitecturas. Es la opción recomendada siempre que puedas, porque simplifica el despliegue y permite que el sistema instale solo las partes necesarias para cada dispositivo.
Finalmente, para publicar en Microsoft Store se usan los archivos de carga (.msixupload o .appxupload), que contienen uno o varios paquetes o bundles junto con símbolos de depuración para análisis de fallos. Visual Studio los genera automáticamente cuando empaquetas con intención de subir a Store.
Crear un paquete MSIX desde un instalador existente
La ruta clásica para migrar software legado consiste en usar MSIX Packaging Tool como asistente y seguir un flujo guiado que captura todo lo que hace el instalador y lo traduce al formato MSIX.
Al iniciar la herramienta, lo primero es seleccionar el tipo de tarea. Para generar un paquete estándar, eliges “Crear paquete de aplicación” y a continuación decides si la captura se hace en el propio equipo, en una máquina remota o en una VM local gestionada con Hyper‑V.
Tras preparar el equipo (controlador, servicios detenidos, pausa de actualizaciones, etc.), llega el momento de indicar qué instalador quieres convertir. Aquí puedes trabajar con instaladores MSI, EXE, App-V 5.x, ClickOnce, scripts de instalación o incluso dejar el campo vacío si vas a hacer una instalación completamente manual.
Si el origen es un MSI, la herramienta puede leer datos internos (nombre de producto, versión, publisher…) y rellenar automáticamente muchos campos del manifiesto, lo que ahorra tiempo y reduce errores. Además, si tienes archivos MST o MSP asociados, puedes pasarlos como argumentos del instalador.
En el caso de un App-V 5.x, el proceso suele ser más directo porque el paquete ya tiene un manifiesto rico. En muchas situaciones basta con indicar el archivo App-V y la herramienta traduce esa información al formato MSIX. Ojo: versiones 4.x no se soportan, ahí lo recomendable es volver al instalador original y convertirlo directamente.
Para instaladores EXE y ClickOnce, el formato es menos estructurado y la herramienta no puede extraer tanto metadato, por lo que tendrás que rellenar a mano buena parte de la información del paquete (nombre, editor, versión, etc.). El EXE se ejecutará igualmente bajo monitorización, pero el trabajo de definición recae en ti.
Si tu proceso de instalación se basa en scripts personalizados (PowerShell, CMD, etc.), puedes indicar la línea de comandos en el asistente o ejecutarlo manualmente durante la fase de instalación. Y, si te interesa tener absolutamente todo bajo control, también puedes optar por una instalación manual, dejando el campo de instalador en blanco y realizando tú mismo cada paso mientras el sistema está siendo monitorizado.
Configurar la firma del paquete MSIX
Un punto clave: ningún paquete MSIX se puede instalar si no está firmado con un certificado que el sistema de destino considere de confianza. Por eso, durante el flujo del asistente tendrás que elegir cómo se firmará.
La herramienta soporta varias opciones. Puedes usar la firma de Device Guard, que es un servicio de Microsoft basado en Azure AD y pensado para entornos corporativos donde no quieres gestionar tu propio certificado, o puedes recurrir a un certificado .pfx propio, habitual en organizaciones con PKI interna o certificados de entidades públicas.
Existe también la posibilidad de indicar un archivo .cer sin firmar realmente el paquete, útil para comprobar que los datos del editor del manifiesto coinciden con el certificado que se utilizará más adelante. Y, si lo prefieres, puedes dejar el paquete sin firmar en esta fase para firmarlo después con tus herramientas habituales, aunque eso te impedirá instalarlo hasta que la firma esté puesta.
Cuando firmes, es muy recomendable añadir una marca de tiempo usando un servidor RFC 3161. Esto permite que la firma siga siendo válida incluso cuando el certificado haya caducado, lo que es crítico para instalaciones a largo plazo o auditorías.
Rellenar la información del paquete
Tras elegir el instalador y la estrategia de firma, viene la pantalla donde defines la identidad del paquete MSIX. Muchos campos pueden venir completados de origen, pero es importante revisarlos porque afectan tanto al comportamiento como a la experiencia de usuario.
El nombre del paquete es obligatorio, sensible a mayúsculas y sin espacios, y se corresponde con la identidad en el manifiesto. No lo verá el usuario final, pero es el identificador que utiliza el sistema. Debe tener entre 3 y 50 caracteres, alfanuméricos, guiones y puntos, sin terminar en punto ni coincidir con nombres reservados del sistema (CON, PRN, COM1, LPT1, etc.).
El nombre para mostrar sí es visible en el menú Inicio y en las páginas de configuración. Puede ser traducible, admite hasta 256 caracteres y conviene que sea descriptivo para que el usuario reconozca claramente la aplicación instalada.
En cuanto al editor, hay dos valores: el nombre técnico (Publisher), que debe coincidir exactamente con el sujeto del certificado con el que firmas, y el nombre de editor para mostrar, que es lo que verá el usuario en los diálogos de instalación y en la Store. El primero es una cadena con formato de nombre distintivo (CN=, O=, etc.), mientras que el segundo es un texto libre más amigable.
La versión del paquete utiliza notación cuádruple tipo Mayor.Menor.Compilación.Revisión. Este valor es importante para las actualizaciones, ya que Windows usará esa numeración para decidir si un paquete nuevo reemplaza a uno antiguo o no.
Además puedes indicar una descripción opcional y la ubicación de instalación donde el instalador copia los archivos de la aplicación (típicamente Program Files). Si la app instala componentes fuera de Program Files, es buena idea reflejarlo aquí y asegurarte de que la ruta coincide durante la instalación para evitar sorpresas.
Por último, existe una casilla para añadir compatibilidad con MSIX Core, seleccionando la versión mínima de Windows que quieres soportar. MSIX Core permite instalar paquetes MSIX en sistemas que no tienen soporte nativo completo, ampliando un poco el rango de máquinas donde puedes desplegar.
Fase de instalación y captura
Con toda la información de identidad definida, el asistente pasa a la fase de instalación supervisada, donde realmente se captura lo que hace el instalador para convertirlo en un paquete MSIX.
La herramienta lanza el instalador (o te deja ejecutarlo manualmente) dentro del entorno que hayas definido. A partir de ahí, debes seguir el asistente de instalación de la aplicación como lo harías normalmente, pero con algunas recomendaciones: usar rutas de instalación coherentes y crear los accesos directos necesarios con las que has indicado antes, crear los accesos directos necesarios y desactivar cualquier mecanismo de actualización automática integrado.
Si la aplicación necesita varios instaladores, componentes adicionales o prerrequisitos como .NET Framework 3.5, puedes aprovechar esta fase para instalarlos, ya que todo quedará recogido en la captura. Lo mismo aplica si debes ejecutar scripts o registrar DLL adicionales.
Si el instalador exige un reinicio, la herramienta ofrece un botón de reinicio controlado para que el sistema se reinicie y luego retome el proceso de conversión donde lo dejó, sin perder el contexto de lo que se estaba monitorizando.
Gestión del primer inicio y puntos de entrada
Una vez finaliza la parte “visible” de la instalación, MSIX Packaging Tool muestra un listado con los ejecutables detectados durante la captura. Aquí es donde defines qué accesos se expondrán como entradas de la aplicación en el menú Inicio y cuál de ellos es el principal.
Se recomienda lanzar al menos una vez la aplicación principal desde esta pantalla para que queden registradas todas las tareas de primer inicio (creación de carpetas de usuario, generación de configuración inicial, etc.), que también formarán parte del paquete.
Desde la misma vista puedes eliminar puntos de entrada innecesarios (herramientas auxiliares, desinstaladores, etc.) y marcar el ejecutable que actuará como entrada principal. Si la app principal no aparece en la lista, siempre puedes buscarla manualmente en disco, ejecutarla y después actualizar la lista de ejecutables detectados.
Al hacer clic en el siguiente paso, la herramienta te pedirá que confirmes si has terminado de gestionar estos primeros arranques o si necesitas volver atrás para completar alguna configuración adicional, instalar más archivos o lanzar otros ejecutables.
Detección y configuración de servicios
En versiones recientes, MSIX Packaging Tool incluye una página específica para informes de servicios. Si durante la instalación se han creado servicios de Windows, estos se mostrarán clasificados en dos tablas: incluidos (con la información necesaria) y excluidos (cuando faltan datos o el servicio no es compatible con MSIX tal cual).
Al hacer doble clic sobre un servicio podrás ver y, en algunos casos, editar campos como la descripción, el nombre para mostrar, la cuenta de inicio, la tipo de arranque, argumentos de inicio o dependencias. La clave del servicio y la ruta al ejecutable no son editables desde esta interfaz.
Una vez que hayas ajustado lo que haga falta, puedes mover el servicio desde la tabla de excluidos a la de incluidos para que pase a formar parte del paquete MSIX final, o dejarlo excluido si prefieres gestionarlo por otras vías.
Creación, guardado y edición del paquete MSIX
Con todo lo anterior definido, el asistente llega al paso de creación del paquete, donde eliges la carpeta en la que se guardará el MSIX generado y, si lo necesitas, la ubicación para un archivo de plantilla de conversión que te permita repetir el proceso en otras máquinas de forma estandarizada.
Por defecto, los paquetes se guardan en la carpeta de datos de aplicación local del usuario, pero puedes cambiar tanto la ruta en ese momento como la ubicación predeterminada desde la configuración de la propia herramienta para adaptarla a tu flujo de trabajo.
Antes de pulsar en crear, tienes la opción de abrir el Editor de paquetes, que permite revisar y modificar el contenido del MSIX: archivos incluidos, manifiesto, capacidades, accesos, etc. Es muy útil para aplicar pequeños ajustes sin tener que repetir toda la captura.
Al terminar la creación, la herramienta muestra una ventana emergente con un enlace directo a la carpeta donde se ha guardado el paquete y otro enlace a los archivos de log generados durante la conversión (útiles para diagnosticar problemas o documentar el proceso).
Instalar y probar paquetes MSIX en otras máquinas
Instalar un paquete MSIX en un equipo de pruebas o en producción es bastante simple una vez que el sistema confía en el certificado con el que está firmado. En entornos de laboratorio suele bastar con importar el certificado en el almacén adecuado y luego hacer doble clic sobre el archivo .msix o .msixbundle para lanzar el instalador de aplicaciones de Windows.
En máquinas unidas a dominio o con políticas más estrictas, lo habitual es distribuir el certificado a través de GPO o soluciones de gestión para que todos los equipos reconozcan el emisor como de confianza y puedan instalar los paquetes sin errores de firma.
También puedes instalar y desinstalar MSIX desde PowerShell, lo cual es muy práctico para automatizar pruebas o despliegues controlados. Comandos como Add-AppxPackage o Remove-AppxPackage permiten manejar los paquetes de forma scriptable, y con Get-AppxPackage puedes consultar información de las apps instaladas.
Una vez instalada, la aplicación ya no aparece como un programa clásico en “Programas y características”, sino como una app moderna en el entorno UWP, alojada normalmente en C:\Program Files\WindowsApps, con el aislamiento y modelo de permisos correspondiente.
Uso de Visual Studio para crear paquetes MSIX
Si la aplicación está en desarrollo y usas Visual Studio, lo más cómodo es generar el MSIX directamente desde el proyecto, especialmente en aplicaciones UWP o en proyectos de empaquetado de aplicaciones de Windows que envuelven una app Win32.
El corazón de este proceso es el archivo Package.appxmanifest, un XML que describe identidad, capacidades, iconos, orientaciones de pantalla, declaraciones de extensiones y otros detalles necesarios para construir el paquete. Visual Studio ofrece un diseñador gráfico para editarlo sin tocar el XML a mano.
Desde el Explorador de soluciones puedes abrir el manifiesto haciendo doble clic sobre Package.appxmanifest. En las distintas pestañas defines, por ejemplo, los recursos visuales (iconos, logotipos, splash screens) o los parámetros de empaquetado, incluido el certificado con el que se firmará el MSIX.
Si vas a publicar en Microsoft Store, es recomendable asociar el proyecto con una aplicación en la tienda usando la opción Publicar → Asociar la aplicación con la Tienda. Esto sincroniza automáticamente ciertos campos de empaquetado (identidad, publisher, etc.) con la información del Centro de partners.
Una vez que el manifiesto está configurado, puedes lanzar el asistente para Crear paquetes de aplicaciones desde el menú de Publicar del proyecto. Ahí eliges si el destino es sideloading (distribución fuera de la Store) o Microsoft Store, las arquitecturas a incluir, si se generará un bundle y cómo se firmará el paquete.
Archivos de carga y envío a Microsoft Store
Cuando tu objetivo es distribuir la aplicación a través de Microsoft Store, además del paquete en sí necesitas un archivo de carga .msixupload o .appxupload, que empaqueta el bundle y los símbolos necesarios para análisis de telemetría y fallos.
Visual Studio puede generar este archivo automáticamente si seleccionas la opción de crear paquetes para Microsoft Store en el asistente. En ese caso, al finalizar la creación tendrás disponible el .msixupload en la carpeta de salida del proyecto, listo para validarlo y subirlo al Centro de partners.
Si por cualquier motivo necesitas construir el archivo de carga de forma manual, puedes agrupar en una carpeta uno o varios paquetes .msix o bundles .msixbundle junto con su archivo .appxsym de símbolos, comprimirlos en ZIP y después cambiar la extensión del archivo resultante a .msixupload o .appxupload.
En estas publicaciones de Store es muy importante incluir símbolos públicos si quieres aprovechar las capacidades de análisis de fallos y rendimiento que ofrece el Centro de partners; de lo contrario, la información de depuración será limitada.
Validación con el Kit de certificación de aplicaciones de Windows
Antes de subir cualquier paquete a la Store (y también para despliegues internos serios) es buena práctica pasar el Windows App Certification Kit (WACK), que ejecuta un conjunto de pruebas automatizadas sobre el paquete.
Desde el propio asistente de Visual Studio, cuando terminas de crear paquetes, puedes lanzar directamente el WACK sobre el equipo local o bien sobre un dispositivo remoto que tenga el kit instalado. Las pruebas revisan aspectos como rendimiento, uso de API, seguridad y cumplimiento de requisitos de la plataforma.
Si tienes un dispositivo remoto con Windows 10, puedes habilitarlo para desarrollo, instalar en él las herramientas remotas de Visual Studio y el kit de certificación, y luego usar la opción de Máquina remota en el asistente para ejecutar las pruebas desde tu máquina de desarrollo contra ese equipo.
Una vez que el paquete supera las pruebas del WACK, quedas en una buena posición para enviarlo al Centro de partners. El archivo .msixupload generado se suele encontrar en la carpeta AppPackages de la solución, con un nombre que incluye la versión y las arquitecturas soportadas.
Automatizar envíos a Microsoft Store desde Visual Studio
En versiones recientes de Visual Studio es posible ir un paso más allá y automatizar el envío a Microsoft Store directamente desde el IDE, una vez que el paquete ha pasado la validación del WACK.
Para ello necesitas tener asociada tu cuenta del Centro de partners con un inquilino de Azure Active Directory, y registrar en dicha cuenta una aplicación de Azure AD con permisos de administrador sobre los envíos. Desde el panel del Centro de partners obtendrás el identificador de inquilino, el identificador de cliente y una clave secreta.
Con estas credenciales configuradas en Visual Studio, en la parte final del asistente para crear paquetes puedes marcar la opción de enviar automáticamente a la Store tras la validación. A partir de ese momento, al terminar WACK, el propio IDE iniciará el envío y podrás seguir el progreso desde la ventana de comprobar y publicar.
Este flujo resulta especialmente útil en equipos de desarrollo que hacen entregas frecuentes a Store y quieren reducir pasos manuales, manteniendo al mismo tiempo la seguridad que aporta Azure AD en la autenticación.
MSIX app attach y contenedores VHD/CIM
En escenarios de virtualización de escritorios (Windows 10/11 multiusuario, Azure Virtual Desktop, etc.), MSIX cobra todavía más interés gracias a MSIX app attach, una tecnología que permite desacoplar las aplicaciones de la imagen base y cargarlas desde contenedores.
En este modelo, en lugar de instalar la aplicación dentro de la imagen de SO, se transforma el paquete MSIX en un contenedor VHD, VHDX o CIM. Estos contenedores se montan en tiempo de ejecución y el sistema “adjunta” la aplicación al perfil del usuario, reduciendo el tamaño de la imagen y simplificando la gestión de versiones.
Los archivos CIM se apoyan en Composite Image File System (CimFS), que ofrece montajes más rápidos y menor consumo de recursos frente a VHD clásicos. Microsoft proporciona herramientas como MSIX Manager Tool para convertir MSIX en VHD de forma manual, y existen utilidades de terceros (MSIX Hero, herramientas de AppVentiX, etc.) que simplifican el proceso y lo integran en flujos más amplios.
Eso sí, para aprovechar MSIX app attach es necesario cumplir ciertos requisitos de versión de Windows (por ejemplo, Windows 10 2004 o posterior) y contar con certificados válidos que permitan que el sistema confíe en las aplicaciones firmadas que se van a montar como contenedores.
En conjunto, MSIX, la herramienta de empaquetado, Visual Studio y app attach forman un ecosistema bastante potente que permite modernizar despliegues, reducir conflictos entre aplicaciones y mejorar la gestión en entornos tanto tradicionales como en la nube, siempre que dediques algo de tiempo a entender bien cada pieza y a definir una estrategia de empaquetado coherente con tus necesidades.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.