EtherApps Forge 1.0.6 is out, and it widens the product in two directions at once. Legacy applications that package cleanly but then misbehave inside the MSIX container can now be remediated with Package Support Framework fix-ups staged as part of packaging. And for the first time, Forge is not only for applications you capture from someone else's estate: the forge_msix CLI is a drop-in replacement for Microsoft's makeappx.exe, so a development team or software vendor can turn its own build folder into a signed, validated MSIX inside an existing pipeline.
Both changes address the same complaint from opposite ends of the packaging problem. Getting a package built has not been the hard part for a while. Getting it to run correctly, and getting it to run correctly every time a build goes out, is where the work actually sits.
PSF compatibility fix-ups: when the app packages fine but will not behave
The most frustrating outcome in an MSIX programme is not a package that fails to build. It is a package that builds, signs, installs, launches, and then quietly does the wrong thing.
That happens because the MSIX container changes the rules an older application was written against. Three patterns cause most of it:
- Writing next to its own executable. Applications that drop settings, logs, or licence files into their own installation folder are writing to a location the container protects.
- Assuming a fixed installation path. Anything with a hard-coded
C:\Program Files\Vendor\Apppath, or a launcher that expects a specific working directory, finds neither where it expects. - Reading machine registry locations. Configuration held under
HKLMthat the container redirects is no longer where the application looks for it.
The Package Support Framework is Microsoft's open-source answer to exactly this. It applies targeted fix-ups at runtime, without any change to the application's source code, and the important ones are file and registry redirection plus working-directory correction. If a legacy application has no vendor left to rebuild it, PSF is often the difference between an application that ships and one that gets written off.
From 1.0.6, Forge stages the framework as part of packaging rather than leaving it as a manual step afterwards. The practical effect on an assessment is that the category of applications marked "ships with fix-ups" gets meaningfully larger, and the category marked "cannot move yet" gets smaller. We wrote about why this remediation layer matters for app attach and MSIX delivery in the Package Support Framework and MSIX app attach risk, and it applies just as directly to Intune-delivered packages on physical devices.
Developer and ISV packaging: your own builds, signed and validated
Capture-first packaging solves a legacy problem: the installer is gone, so the running application becomes the source of truth. That was never the whole market. Plenty of teams have a perfectly good build folder and still find MSIX awkward, because the tooling around it assumes a Windows SDK installation, a signing step bolted on afterwards, and a human to check the result.
forge_msix is built as a drop-in replacement for makeappx.exe. It calls the Windows packaging engine directly rather than depending on the SDK being installed on the build agent, and the packaging verbs take the same switches, so an existing script keeps working when you swap the binary.
Beyond parity, the release adds the parts a release pipeline actually needs:
# Scaffold a manifest from the built executable
forge_msix prepare .\publish\MyApp.exe
# Create and sign in one step, from the agent certificate store
forge_msix create -s .\publish --package-output .\artifacts\MyApp.msix `
--sign --cert-sha1 $env:SIGNING_THUMBPRINT --cert-store My --cert-machine-store `
--timestamp-server http://timestamp.digicert.com --validate-schema
# Gate the build on structural validation
forge_msix validate /p .\artifacts\MyApp.msix --json
Three details matter for anyone wiring this into CI. Sign from a certificate store by thumbprint rather than a PFX on disk, so no password ends up in a build definition. Add an RFC 3161 timestamp so signatures stay valid after the certificate expires. And branch on the exit code, because validate distinguishes "the package was analysed and is invalid" from "the run itself failed", which is the difference between a broken build and a broken agent.
There is also a smoke-test verb that installs the signed package, launches and closes it, uninstalls it, and writes a JSON report, plus an assessment pass that scores a package against packaging best-practice signals. Neither belongs on every commit. Both are worth running on a release candidate.
For teams shipping outside a store, make-appinstaller generates the .appinstaller manifest from the signed package's real identity, so sideloaded copies can update themselves from an HTTPS location.
What this means if your estate is mixed
Most organisations are not purely one thing or the other. They have bought-in software with lost installers, a handful of internally built line-of-business applications, and a Windows 11 or Intune deadline covering all of it. Until now those two halves took different routes and different tools.
With 1.0.6 they share a packaging path: capture-first for the applications where the installer is gone, build-folder packaging for the ones your own developers compile, PSF remediation for anything the container upsets, and the same signing, validation, and Intune delivery at the end. The route decision still belongs to a person. The mechanics stop being two separate projects.
Availability
EtherApps Forge 1.0.6.0 is available now. Forge is a Win32 application you deploy inside your own environment rather than a hosted service, so captures and packaging stay under your control, and it captures from older Windows versions as well as current ones. Every licence includes training and support, and there is a free 7-day trial so a packaging, endpoint, or development team can prove the outcome on one real application before committing to the wider estate.
If your blocker is a legacy application nobody can rebuild, start with modernise legacy Windows applications or our guide on repackaging an application when the installer is lost. If it is the delivery side, MSIX packaging and deployment covers signing, PSF review, and Intune rollout. The product itself is on EtherApps Forge.
Try EtherApps Forge free for 7 days and package one real application, captured or built, from source to signed MSIX.