Solution
Usted ya construye el software. Convertirlo en un MSIX firmado y validado debería ser un paso de su pipeline, no un proyecto aparte. La CLI forge_msix de EtherApps Forge es un reemplazo directo de makeappx.exe de Microsoft, así que una carpeta de compilación se convierte en un paquete firmado, validado y probado sin un SDK de Windows en el agente de compilación y sin reescribir el script que ya tiene.
Sin SDK
la CLI llama al motor de empaquetado de Windows directamente en el agente
Sin licencia
los comandos compatibles con makeappx no requieren licencia alguna
Un paso
crear, firmar, validar y probar dentro de la pipeline de release
Encaje con la pipeline
Empaquetar una build como MSIX no es una tarea. Es manifiesto, paquete, firma, validación, prueba y una vía de actualización. Comparado por etapa en lugar de por producto:
| Etapa de la pipeline | Herramienta estándar del SDK de Windows | forge_msix |
|---|---|---|
| Preparación del agente | SDK de Windows instalado y con versión fijada en cada agente | Una copia de la carpeta de la CLI en el PATH. Llama al motor que viene con Windows |
| Manifiesto | Escrito a mano y mantenido a mano al ritmo de la build | Generado desde los recursos de versión del ejecutable, o versionado en el control de código y pasado como parámetro |
| Empaquetar y firmar | Herramientas separadas, la firma añadida después del empaquetado | Un solo comando, con la identidad del publicador alineada al sujeto del certificado |
| Hacer fallar la build | Los códigos de salida no separan un paquete inválido de una ejecución fallida | La validación devuelve un código propio para analizado-pero-inválido, así la puerta es inequívoca |
| Actualizaciones sideload | Manifiesto de app installer escrito y mantenido a mano | Generado desde la identidad real del paquete firmado, compatible con bundles |
The problem
Los equipos de desarrollo y los fabricantes de software no están atascados en el mismo problema que un equipo de migración. Aquí no hay instalador perdido ni nada que capturar: la build ya funciona. La fricción está en todo lo que viene después. El empaquetado MSIX ha significado históricamente una dependencia del SDK de Windows en el agente de compilación, un paso de firma añadido a posteriori, una gestión de certificados que nadie asume y ninguna forma fiable de hacer fallar una build cuando el paquete está mal. El resultado es que el empaquetado se convierte en una tarea manual que alguien hace el día del release, que es exactamente donde los errores llegan a los clientes.
Empaquetar con la herramienta estándar implica instalar y fijar la versión del SDK de Windows en cada agente. Es una dependencia pesada para un solo paso, y se descuadra entre agentes de una forma que solo aparece el día de un release.
Windows no instalará un MSIX sin firmar, así que firmar no es opcional. Añadirlo después del empaquetado suele significar un archivo de certificado en disco con su contraseña en una definición de compilación, o un paso manual que hace quien tiene el certificado.
Sin una puerta de validación que distinga un paquete inválido de una ejecución fallida, un paquete roto puede atravesar la pipeline y llegar a un cliente, donde falla en el momento de instalar en lugar de al construir.
Construir un paquete completo en cada recompilación durante el desarrollo es innecesario y lento, así que los equipos dejan de probar la forma empaquetada hasta tarde, y el comportamiento propio del contenedor les sorprende al final.
What changes
Los comandos de empaquetado aceptan los mismos parámetros que makeappx.exe, así que un script existente sigue funcionando al cambiar el binario. Esos comandos no requieren licencia, de modo que la adopción no empieza con una conversación de compras, y el motor es el componente del sistema operativo en lugar de una reimplementación.
Genere un manifiesto desde los recursos de versión y la arquitectura del ejecutable compilado, o mantenga uno en el control de código para que identidad, publicador y capacidades se revisen como cualquier otro archivo. Después cree y firme en un único comando, desde un almacén de certificados por huella digital para que ninguna contraseña se escriba en una definición de compilación, con una marca de tiempo RFC 3161 para que las firmas sobrevivan al certificado.
La validación de esquema se ejecuta como comprobación previa, y el comando de validación devuelve un código de salida propio para un paquete analizado y encontrado inválido, distinto del de una ejecución que simplemente falló. En una candidata a versión, una prueba de humo instala el paquete firmado, lo arranca y lo cierra, lo desinstala y escribe un informe JSON, y una pasada de evaluación lo puntúa frente a las buenas prácticas de empaquetado.
Durante el desarrollo, registre la salida de compilación como paquete suelto en lugar de reempaquetar en cada recompilación, y luego valide, arranque y limpie en una sola pasada contra una copia de staging aislada. Para distribución sideload, genere un manifiesto de app installer desde la identidad real del paquete firmado para que las copias instaladas se actualicen solas desde una ubicación HTTPS.
How we deliver it
Esta ruta la lidera EtherApps Forge, en concreto su CLI forge_msix. Forge es una aplicación Win32 que se despliega dentro de su propio entorno en lugar de un servicio alojado, así que los artefactos de compilación, los certificados y el empaquetado permanecen bajo su control y dentro de su pipeline. Si la misma organización tiene además software comprado con instaladores perdidos, la ruta capture-first de la página de empaquetado y despliegue MSIX cubre esa mitad del entorno por la misma vía de firma y entrega.
EtherApps Forge captures installed Windows applications from running systems, analyses the real application footprint, supports AI-guided packaging decisions, and produces deployment-ready outputs for modern environments.
Where this fits
FAQ
Licencias, dependencias del agente de compilación, firma y en qué se diferencia de la ruta capture-first pensada para aplicaciones heredadas.
No, y la distinción importa. El empaquetado capture-first existe para aplicaciones cuyo instalador se ha perdido, de modo que la aplicación en ejecución se convierte en la fuente de verdad. Esta ruta asume lo contrario: usted tiene una carpeta de compilación sana y quiere empaquetarla, firmarla y validarla como un paso de la pipeline. Ambas comparten al final la misma vía de firma, validación y entrega por Intune, y por eso los entornos con software comprado y propio pueden usar una sola ruta para ambos.
No para los comandos compatibles con makeappx. Empaquetar, desempaquetar, agrupar, desagrupar, validar e indexar recursos no requieren licencia, así que forge_msix funciona como verdadero reemplazo directo de makeappx.exe sin nada que comprar. Los flujos de valor añadido, es decir crear desde un manifiesto, firmar, probar, evaluar, gestionar certificados y los comandos de registro para desarrollo, requieren una licencia activa de EtherApps Forge.
No. La CLI llama directamente a la API de empaquetado de Windows, y ese motor es un componente del sistema operativo en lugar de una dependencia del SDK, así que los paquetes obtienen la misma validación de esquema, block map y estructura que produce makeappx. El agente necesita Windows 10 versión 1709 o posterior, o Windows 11, en x64. El despliegue es una carpeta que se copia y se añade al PATH, sin instalador.
Firme desde un almacén de certificados por huella digital o por sujeto en lugar de desde un PFX en disco, para que ninguna contraseña se escriba en una definición de compilación. Añada un servidor de marca de tiempo RFC 3161 para que las firmas sigan siendo válidas tras caducar el certificado. Ponga el publicador de su manifiesto exactamente igual al sujeto del certificado y deje el modo de publicador en estricto, para que una discrepancia detenga la compilación en lugar de cambiar en silencio la identidad que sus clientes ya tienen instalada.
Ejecute el comando de validación con salida JSON y bifurque según el código de salida. Distingue un paquete analizado pero inválido de un fallo operativo, que es la diferencia entre un paquete roto y un agente roto. Mantenga fuera de las pipelines de release los parámetros que permiten continuar pese a errores de validación o semánticos; son herramientas de diagnóstico para averiguar por qué un paquete no se construye, no ajustes para dejar activados.
Sí. Las aplicaciones escritas antes de MSIX a menudo asumen comportamientos que el contenedor no permite, como escribir junto a su propio ejecutable o esperar una ruta de instalación fija. Forge prepara el Package Support Framework para que esos casos se corrijan con redirección de archivos y de registro y ajustes del directorio de trabajo, sin cambiar su código fuente. Para software propio quizá prefiera corregir el comportamiento en origen, pero el framework evita que un release quede bloqueado mientras lo hace.
Genere un manifiesto de app installer desde el paquete firmado, que deriva la identidad del propio paquete y es compatible con bundles. Publique el paquete y ese manifiesto en una ubicación HTTPS, y las copias instaladas podrán actualizarse solas desde allí. Eso da a los clientes sideload y corporativos una vía de actualización sin listado en tienda ni reinstalación manual.
Sí. Un paquete puede extraerse a un directorio de trabajo, editarse quirúrgicamente, validarse y volver a empaquetarse: valores del manifiesto, capacidades, archivos de payload y el registro virtual del paquete pueden cambiarse, y cada edición del manifiesto se valida antes de escribirse, de modo que un cambio malformado se rechaza en lugar de guardarse. Reempaquetar cambia el hash de contenido, así que el paquete debe firmarse de nuevo después.
Start here
Empiece con la prueba gratuita de 7 días de EtherApps Forge y empaquete una build real de principio a fin, o hablemos de la pipeline que ya tiene y de dónde debería situarse el paso de empaquetado dentro de ella.
