Solución
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.
Prueba gratuita de 7 días del flujo de trabajo completo · las licencias incluyen formación y soporte
Sin tarjeta de crédito. Capture una aplicación real el primer día.
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 |
El problema
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.
Qué cambia
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.
Forge MSIX CLI para pipelines de build y fábricas de empaquetado MSP: capture, firme y produzca un MSIX listo para despliegue con un único comando. Sin GUI necesaria.
Forge evalúa cada MSIX contra señales de mejores prácticas desde la misma sesión CLI: capabilities, alineación del publisher, assets visuales y estado de trust.
Empiece aquí
Véalo funcionando en su propio tenant.
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.
Cómo lo ofrecemos
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.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
Prueba gratuita de 7 días del flujo de trabajo completo · las licencias incluyen formación y soporte
Preguntas
Licencias, dependencias del agente de build, firma, integración CI y cómo esto difiere de la ruta capture-first para aplicaciones heredadas.
Pregúntenos en una comprobación de encaje de empaquetadoNo, 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.
Revisado el 26 de agosto de 2026.
Empiece aquí
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.
Sin tarjeta de crédito. Capture una aplicación real el primer día.
