Solution
You already build the software. Turning it into a signed, validated MSIX should be a step in your pipeline, not a separate project. The forge_msix CLI from EtherApps Forge is a drop-in replacement for Microsoft's makeappx.exe, so a build folder becomes a signed, validated, smoke-tested package without a Windows SDK on the build agent and without rewriting the script you already have.
No SDK
the CLI calls the Windows packaging engine directly on the build agent
Licence-free
the makeappx-compatible verbs need no licence at all
One step
create, sign, validate, and smoke-test inside the release pipeline
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
Development teams and software vendors are not stuck on the same problem as a migration team. There is no lost installer here and nothing to capture: the build already works. The friction is everything that happens after it. MSIX packaging has historically meant a Windows SDK dependency on the build agent, a signing step bolted on after the fact, certificate handling that nobody owns, and no reliable way to fail a build when the package is wrong. The result is that packaging becomes a manual job somebody does at release time, which is exactly where mistakes reach customers.
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.
Windows will not install an unsigned MSIX, so signing is not optional. Bolting it on after packaging tends to mean a certificate file on disk with its password in a build definition, or a manual step performed by whoever has the certificate.
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.
Building a full package on every rebuild during development is unnecessary and slow, so teams stop testing the packaged form until late, and container-specific behaviour surprises them at the end.
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, and an assessment pass scores it against packaging best practice.
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 against an isolated staging copy. For sideloaded distribution, generate an app installer manifest from the signed package's real identity so installed copies update themselves from an HTTPS location.
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.
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
Licensing, build-agent dependencies, signing, and how this differs from the capture-first route built for legacy applications.
No, 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.
Not for the makeappx-compatible verbs. Packing, unpacking, bundling, unbundling, validating, and resource indexing are licence-free, so forge_msix works as a true drop-in replacement for makeappx.exe with nothing to buy. The value-added workflows, which are creating from a manifest, signing, testing, assessment, certificate management, and the developer registration verbs, require an active EtherApps Forge licence.
No. The CLI calls the Windows packaging API directly, and that engine is an operating system component rather than an SDK dependency, so packages get the same schema enforcement, block map, and layout that makeappx produces. The agent needs Windows 10 version 1709 or later, or Windows 11, on x64. Deployment is a folder you copy and put on PATH, with no installer.
Sign from a certificate store by thumbprint or subject rather than from a PFX file on disk, so no password is written into a build definition. Add an RFC 3161 timestamp server so signatures stay valid after the certificate expires. Set the publisher in your manifest to the exact certificate subject and leave the publisher mode strict, so a mismatch stops the build rather than quietly changing the identity your customers have already installed.
Run the validation verb with JSON output and branch on the exit code. It distinguishes an analysed-but-invalid package from an operational failure, which is the difference between a broken package and a broken agent. Keep the switches that allow a build to continue past validation or semantic errors out of release pipelines; they are diagnostic tools for working out why a package will not build, not settings to leave enabled.
Yes. Applications written before MSIX often assume behaviour the container does not allow, such as writing next to their own executable or expecting a fixed installation path. Forge stages the Package Support Framework so those cases are corrected with file and registry redirection and working-directory fix-ups, with no change to your source code. For your own software you may prefer to fix the behaviour at source, but the framework means a release is not blocked while you do.
Generate an app installer manifest from the signed package, which derives the identity from the package itself and is bundle aware. Publish the package and that manifest to an HTTPS location, and installed copies can update themselves from there. That gives sideloaded and enterprise customers an update path without a store listing or a manual reinstall.
Yes. A package can be extracted into a working directory, edited surgically, validated, and repacked: manifest values, capabilities, payload files, and the package virtual registry can all be changed, and every manifest edit is validated before it is written so a malformed change is rejected rather than saved. Repacking changes the content hash, so the package has to be signed again afterwards.
Start here
Start with the free 7-day EtherApps Forge trial and package one real build end to end, or talk to us about the pipeline you already run and where the packaging step should sit in it.
