Solution
Pensado para desarrolladores e ISV que ya compilan una app de escritorio que funciona. Céntrese en su producto, no en la fontanería del instalador. La CLI forge_msix de EtherApps Forge convierte una carpeta de build en un MSIX firmado y validado como etapa de pipeline, sin Windows SDK en el agente y sin reescribir el script que ya ejecuta.
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
Cómo funciona
Ya tiene los binarios. Estos son los pasos que convierten esa build en un paquete firmado que sus clientes pueden instalar.
Copie la carpeta de la CLI al PATH. Sin instalar Windows SDK y sin fijar versiones de herramientas SDK entre agentes. La CLI llama al motor de empaquetado que incluye Windows.
Parta de la carpeta que su CI ya produce: ejecutables, dependencias y todo lo que deba ir en el paquete. No hay nada que capturar. La build es la fuente de verdad.
Ejecute forge_msix prepare sobre el ejecutable compilado para generar un manifiesto a partir de sus recursos de versión y arquitectura, o mantenga un manifiesto revisado en el control de código y páselo.
Ejecute forge_msix create sobre la carpeta de build con firma desde el almacén de certificados por huella digital, más un sello de tiempo RFC 3161. La identidad del publisher se alinea con el subject del certificado para una identidad de paquete estable.
Ejecute forge_msix validate y haga fallar la build si el paquete no es válido. Entregue el artefacto para descarga directa, implementación con Microsoft Intune o Configuration Manager, o genere un feed de actualización de app installer para clientes en sideload.
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 desarrolladores e ISV no tienen el mismo problema que un equipo de migración. No hay un instalador perdido ni nada que capturar: la build ya funciona. La fricción es todo lo que viene después. Empaquetar en MSIX ha significado una dependencia del Windows SDK en el agente, un paso de firma añadido después, certificados sin dueño claro y ninguna forma fiable de hacer fallar la build cuando el paquete está mal. El empaquetado se convierte en un trabajo manual en el momento del release, justo donde los errores llegan al cliente.
Los fabricantes de software independientes y los equipos de producto dedican demasiado tiempo a rarezas del empaquetado de Windows en lugar de entregar funciones. MSIX debería ser un paso de release, no un proyecto paralelo.
Empaquetar con la herramienta estándar implica instalar y fijar la versión del Windows SDK en cada agente. Es una dependencia pesada para un solo paso, y diverge entre agentes de un modo que solo se nota el día del release.
Los clientes que despliegan con Intune o Configuration Manager a menudo necesitan un MSIX firmado antes de comprar. Si el empaquetado es lento o manual, se convierte en un bloqueo comercial, no solo técnico.
Sin una puerta de validación que distinga un paquete inválido de una ejecución fallida, un paquete roto puede pasar la pipeline y llegar al cliente, donde falla en la instalación en lugar de en la build.
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.
La pipeline de build a MSIX
forge_msix genera un manifiesto desde el ejecutable compilado, empaqueta y firma en un solo comando, valida el resultado con un código de salida que hace fallar la build, y produce un MSIX firmado. Una breve bifurcación publica un feed de actualización de app installer para clientes en sideload. Cada etapa se ejecuta dentro de la pipeline de release que ya tiene.
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 build, firma, integración CI y cómo esto difiere de la ruta capture-first 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.
Ponga forge_msix en el PATH del agente, apunte a su carpeta de build publicada, ejecute forge_msix prepare para generar un manifiesto desde el ejecutable compilado y luego forge_msix create con firma desde el almacén de certificados por huella digital. Controle el release con forge_msix validate y, si lo desea, genere un feed de app installer para actualizaciones sideload. Los mismos conmutadores que ya usa un script de makeappx siguen funcionando.
Sí. forge_msix es una CLI pensada para agentes desatendidos. Ejecútela desde Azure DevOps, GitHub Actions, GitLab CI, Jenkins o cualquier agente de build Windows con scripts. Empaquetado, firma y validación pasan a ser etapas de la misma definición de release que el resto de sus artefactos.
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 de punta a punta una build real de desarrollador o ISV, o hable con nosotros sobre la pipeline que ya ejecuta y dónde debe situarse el paso de empaquetado.
