Solution
Built for developers and ISVs who already compile a working desktop app. Focus on your product, not installer plumbing. The forge_msix CLI from EtherApps Forge turns a build folder into a signed, validated MSIX as a pipeline stage, with no Windows SDK on the agent and without rewriting the script you already run.
7-day free trial of the full workflow · licences include training and support
No credit card. Capture a real application on day one.
How it works
You already have the binaries. These are the steps that turn that build into a signed package your customers can install.
Copy the CLI folder onto PATH. No Windows SDK install, no version-pinning of SDK tooling across agents. The CLI calls the packaging engine that ships with Windows.
Start from the folder your CI already produces: executables, dependencies, and any files that belong in the package. There is nothing to capture. The build is the source of truth.
Run forge_msix prepare against the built executable to scaffold a manifest from its version resources and architecture, or keep a reviewed manifest in source control and pass it in.
Run forge_msix create against the build folder with signing from a certificate store by thumbprint, plus an RFC 3161 timestamp. Publisher identity is aligned to the certificate subject so customers get a stable package identity.
Run forge_msix validate and fail the build on an invalid package. Ship the artefact for direct download, Microsoft Intune or Configuration Manager deployment, or generate an app installer update feed for sideloaded customers.
Pipeline fit
Packaging a build as MSIX is not one task. It is manifest, package, sign, validate, test, and publish an update path. Compared by stage rather than by product:
| Pipeline stage | Default Windows SDK tooling | forge_msix |
|---|---|---|
| Build agent setup | Windows SDK installed and version-pinned on every agent | A copy of the CLI folder on PATH. It calls the packaging engine that ships with Windows |
| Manifest | Hand-authored and kept in step with the build by hand | Scaffolded from the built executable's version resources, or committed to source control and passed in |
| Package and sign | Separate tools, signing bolted on after packaging | One command, with the publisher identity aligned to the certificate subject |
| Fail the build | Exit codes do not separate an invalid package from a failed run | Validation returns a distinct code for analysed-but-invalid, so the gate is unambiguous |
| Sideload updates | App installer manifest written and maintained by hand | Generated from the signed package's real identity, bundle aware |
The problem
Developers and ISVs are not stuck on the same problem as a migration team. There is no lost installer and nothing to capture: the build already works. The friction is everything after it. MSIX packaging has meant a Windows SDK dependency on the build agent, a signing step bolted on afterwards, certificate handling nobody owns, and no reliable way to fail a build when the package is wrong. Packaging becomes a manual job at release time, which is exactly where mistakes reach customers.
Independent software vendors and product teams spend too long learning Windows packaging quirks instead of shipping product features. MSIX should be a release step, not a side project.
Packaging with the standard tool means installing and version-pinning the Windows SDK on every agent. That is a heavy dependency for one step, and it drifts between agents in a way that only shows up on a release day.
Customers who deploy with Intune or Configuration Manager often need a signed MSIX before they will buy. If packaging is slow or manual, it becomes a commercial blocker rather than a technical one.
Without a validation gate that distinguishes an invalid package from a failed run, a broken package can pass through the pipeline and reach a customer, where it fails at install time rather than at build time.
What changes
The packaging verbs take the same switches as makeappx.exe, so an existing script keeps working when the binary is swapped. Those verbs are licence-free, so adoption does not start with a procurement conversation, and the engine is the operating system component rather than a reimplementation.
Scaffold a manifest from the built executable's version resources and architecture, or keep one in source control so identity, publisher, and capabilities are reviewed like any other file. Then create and sign in a single command, from a certificate store by thumbprint so no password is written into a build definition, with an RFC 3161 timestamp so signatures outlive the certificate.
Schema validation runs as a preflight, and the validation verb returns a distinct exit code for a package that was analysed and found invalid, separate from a run that simply failed. On a release candidate, a smoke test installs the signed package, launches and closes it, uninstalls it, and writes a JSON report.
During development, register the build output as a loose package instead of repackaging on every rebuild, then validate, launch, and clean up in one pass. For sideloaded distribution, generate an app installer manifest from the signed package's real identity so installed copies update themselves from an HTTPS location.
Forge MSIX CLI for build pipelines and MSP packaging factories: capture, sign, and produce a deployment-ready MSIX from a single command. No GUI required.
Forge assesses each MSIX against best-practice signals from the same CLI session: capabilities, publisher alignment, visual assets, and trust state.
Start here
See this working on your own tenant.
The build-to-MSIX pipeline
forge_msix scaffolds a manifest from the built executable, packages and signs in one command, validates the result with a build-failing exit code, and produces a signed MSIX. A short branch publishes an app installer update feed for sideloaded customers. Every stage runs inside the release pipeline you already have.
How we deliver it
This route is led by EtherApps Forge, specifically its forge_msix CLI. Forge is a Win32 application you deploy inside your own environment rather than a hosted service, so build artefacts, certificates, and packaging stay within your control and inside your pipeline. If the same organisation also has bought-in software with lost installers, the capture-first route on the MSIX packaging and deployment page covers that half of the estate through the same signing and delivery path.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
7-day free trial of the full workflow · licences include training and support
Questions
Licensing, build-agent dependencies, signing, CI integration, and how this differs from the capture-first route built for legacy applications.
Ask us on a packaging fit checkNo, and the distinction matters. Capture-first packaging exists for applications whose installer is lost, so the running application becomes the source of truth. This route assumes the opposite: you have a healthy build folder and you want it packaged, signed, and validated as a pipeline step. The two share the same signing, validation, and Intune delivery path at the end, which is why estates with both bought-in and self-built software can use one route for both.
Reviewed 26 August 2026.
Start here
Start with the free 7-day EtherApps Forge trial and package one real developer or ISV build end to end, or talk to us about the pipeline you already run and where the packaging step should sit in it.
No credit card. Capture a real application on day one.
