EfficientEther ha publicado una nueva investigación de acceso abierto que responde a una pregunta que los equipos de entrega de aplicaciones afrontan en casi todos los proyectos de Azure Virtual Desktop: ¿debería una aplicación distribuirse como MSIX nativo o a través de App Attach? El informe está disponible ahora en Zenodo bajo una licencia Creative Commons CC BY 4.0, de modo que cualquiera puede leerlo, descargar el PDF completo y citarlo. Escrito por Ryan Mangan, de EfficientEther Ltd, y publicado como preprint (v1, 17 de junio de 2026), lleva el DOI 10.5281/zenodo.20556143.
Su título completo delimita el alcance: "Native MSIX or App Attach for Azure Virtual Desktop? A Decision-Oriented Comparison of Package Delivery, Assignment, Image Management, and Operational Risk". El movimiento central es replantear un debate que suele quedarse atascado en el rendimiento puro. En lugar de preguntar qué modelo inicia una aplicación unos milisegundos más rápido, la investigación trata la elección como una decisión de capacidad y de coste operativo, que es la pregunta que realmente determina cómo un equipo de entrega gestiona su parque.
Qué examina el informe
Para comparar los dos modelos de forma justa, el estudio evalúa cada uno según las formas en que realmente se opera en producción, en lugar de en una única prueba idealizada.
Para MSIX nativo, recorre cuatro modelos de despliegue:
- Instalación para el usuario actual, en la que un paquete se instala en el contexto del usuario que ha iniciado sesión.
- Disponibilidad aprovisionada para todos los usuarios, en la que un paquete se aprovisiona de modo que esté disponible para todos los usuarios de la máquina.
- Base integrada en la imagen, en la que el paquete se incorpora a la imagen base.
- Bucles de estado deseado, en los que un bucle de configuración mantiene el conjunto instalado alineado con un estado previsto.
Para App Attach, examina el ciclo de vida de entrega basado en imagen en ambos formatos de imagen admitidos, VHDX y CimFS, siguiendo cada ciclo de vida de conexión de imagen (image-attach) desde la preparación (staging) hasta el punto en que la aplicación está disponible para un usuario.
En todo esto, el subtítulo nombra las cuatro dimensiones que la comparación mantiene a la vista: entrega de paquetes, asignación, gestión de imágenes y riesgo operativo. Cada dimensión pone de relieve un tipo distinto de coste. La entrega de paquetes tiene que ver con cómo un paquete llega realmente a la máquina y con lo repetible que es eso. La asignación tiene que ver con cómo una aplicación se dirige a los usuarios o hosts correctos y con lo dinámico que puede ser ese direccionamiento. La gestión de imágenes tiene que ver con si la aplicación reside dentro de la imagen base o fuera de ella, y con lo que eso significa para la frecuencia con la que hay que reconstruir la imagen. El riesgo operativo es el silencioso: los modos de fallo, las sensibilidades en el momento del inicio y las piezas móviles que un equipo debe mantener en buen estado después de la puesta en marcha. Mantener esas cuatro constantes es lo que convierte una opinión en un marco de decisión, porque obliga a cada modelo a responder a las mismas preguntas operativas en lugar de ser juzgado por la fortaleza de la que sus defensores prefieren hablar.
Qué concluyó el informe
El hallazgo principal, deliberadamente, no es "gana un modelo". Es una decisión de enrutamiento. MSIX nativo sigue siendo la opción de menor complejidad cuando la instalación y el aprovisionamiento estándar ya cumplen el requisito. App Attach se justifica cuando el requisito pasa a ser la externalización de la imagen y la asignación dinámica en AVD, el punto en el que realmente necesita que la aplicación resida fuera de la imagen y se conecte a los hosts de sesión bajo demanda. Dicho de forma sencilla, la investigación recomienda recurrir al modelo más simple hasta que el propio problema exija el más capaz.
Leído a la luz de esas cuatro dimensiones, el patrón es coherente. MSIX nativo conlleva menos riesgo operativo y menos sobrecarga de gestión de imágenes en el caso común, razón por la que sigue siendo la opción por defecto. App Attach se gana su lugar cuando la externalización de la imagen y la asignación dinámica son el requisito real, porque es precisamente ahí donde sus piezas móviles adicionales empiezan a amortizarse en lugar de limitarse a añadir coste.
En cuanto a los tiempos, el informe es prudente, y nosotros también. En pruebas locales acotadas, App Attach ofreció medianas de ciclo de vida repetido más bajas que la instalación nativa por usuario, mientras que los paquetes ya instalados mostraron tiempos de inicio similares. Ryan Mangan afirma con claridad que se trata de un resultado descriptivo de un diseño de prueba con potencia insuficiente, no de un benchmark general. Repetimos esa advertencia a propósito: sería un error leer las cifras de tiempos como prueba de que App Attach es más rápido en su entorno. El valor del informe es el marco de decisión, no una tabla de clasificación de rendimiento.
La investigación enruta una decisión de entrega entre MSIX nativo y App Attach en función de la capacidad y el coste operativo, no de la velocidad pura.
Por qué publicamos investigación de forma abierta
Este informe forma parte de un programa interno y continuo de investigación y desarrollo en EfficientEther. Lo mantenemos porque preferimos fundamentar la dirección de nuestro producto y nuestras recomendaciones en evidencia probada antes que en el folclore de los proveedores y en suposiciones repetidas. Cuando un hallazgo no es sensible y resulta útil para la comunidad en general, lo publicamos de forma abierta.
Abierto, en este caso, significa realmente abierto. El informe se publica bajo CC BY 4.0, y el registro de Zenodo incluye un paquete de evidencias público junto al PDF para que otros puedan inspeccionar la metodología, cuestionar el diseño y reproducir el razonamiento en lugar de dar por buenas las conclusiones sin más. Preferimos que el trabajo sea cuestionado a que se acepte en silencio. Si no está de acuerdo con el diseño, el planteamiento o las conclusiones, queremos saberlo, y la licencia existe precisamente para que pueda construir sobre el trabajo y citarlo.
No es el primer informe de este programa. Un estudio anterior analizó dónde el Package Support Framework añade riesgo en MSIX y App Attach, también publicado de forma abierta bajo la misma licencia. Seguirán más, porque el objetivo del programa es un cuerpo constante de evidencia, no un único titular.
Qué significa para los profesionales que gestionan parques de AVD y Windows 365
Para los administradores y equipos de entrega que gestionan parques de Azure Virtual Desktop y Windows 365, la conclusión práctica es una opción por defecto más limpia. No adopte App Attach porque sea más nuevo o porque un gráfico de tiempos tenga buen aspecto. Adopte MSIX nativo donde la instalación y el aprovisionamiento ya hacen el trabajo, y pase a App Attach cuando tenga un requisito real de externalización de la imagen y asignación dinámica. Así, la complejidad operativa se mantiene proporcional al problema que realmente está resolviendo.
También ayuda escribir el requisito antes de que empiece el debate sobre las herramientas. Si el parque realmente necesita que las aplicaciones residan fuera de la imagen para poder actualizarlas y conectarlas sin reconstruir los hosts de sesión, ese es un requisito de externalización de la imagen y App Attach entra en juego. Si no, la instalación y el aprovisionamiento de MSIX nativo suelen ser la operación más tranquila para el día a día.
La misma disciplina aparece antes en el ciclo de vida, en el empaquetado. Una ruta capture-first hacia MSIX para aplicaciones de Windows complejas señala que la ruta de entrega debería seguir la huella de aplicación descubierta en lugar de darse por supuesta de antemano. La investigación de este nuevo informe extiende esa idea a la decisión de entrega en AVD: primero entienda el requisito y luego elija el modelo que le corresponde, ya sea MSIX nativo o una imagen de App Attach.
Dónde encaja EtherApps Forge
EtherApps Forge es una aplicación Win32 que se ejecuta en el propio entorno del cliente y no como un servicio alojado, y produce tanto paquetes MSIX nativos como salidas listas para app attach. Eso significa que el marco de decisión del informe se corresponde directamente con las rutas que el producto ya admite: una vez que el descubrimiento ha establecido lo que la aplicación necesita, la misma herramienta puede producir el paquete MSIX nativo o la imagen de App Attach a la que apunta el requisito.
Su flujo de trabajo de empaquetado agéntico de aplicaciones está diseñado para eliminar las conjeturas de ese paso, recomendando una ruta a partir de la huella real de la aplicación en lugar de un hábito por defecto. Puede ponerlo a prueba con una versión de prueba gratuita de 7 días, que es una prueba real del producto y no una licencia gratuita.
Explore el empaquetado y la implementación de MSIX para ver cómo la selección de rutas basada en evidencia convierte el marco de decisión del informe en una operación de empaquetado y entrega repetible.