Solution
Sie bauen die Software bereits. Sie zu einem signierten, validierten MSIX zu machen sollte ein Schritt in Ihrer Pipeline sein, kein eigenes Projekt. Die forge_msix-CLI von EtherApps Forge ist ein Drop-in-Ersatz für Microsofts makeappx.exe: Aus einem Build-Ordner wird ein signiertes, validiertes und per Smoke-Test geprüftes Paket, ohne Windows-SDK auf dem Build-Agenten und ohne das Skript neu zu schreiben, das Sie schon haben.
Kein SDK
Die CLI ruft die Windows-Paketierungs-Engine direkt auf dem Build-Agenten auf
Lizenzfrei
Die makeappx-kompatiblen Befehle brauchen überhaupt keine Lizenz
Ein Schritt
Erstellen, signieren, validieren und Smoke-Test in der Release-Pipeline
Pipeline-Fit
Einen Build als MSIX zu paketieren ist nicht eine Aufgabe. Es ist Manifest, Paket, Signatur, Validierung, Test und ein Update-Pfad. Verglichen nach Stufe statt nach Produkt:
| Pipeline-Stufe | Standard-Windows-SDK-Werkzeug | forge_msix |
|---|---|---|
| Setup des Build-Agenten | Windows-SDK auf jedem Agenten installiert und versionsfixiert | Eine Kopie des CLI-Ordners im PATH. Sie ruft die Engine auf, die mit Windows ausgeliefert wird |
| Manifest | Von Hand geschrieben und von Hand mit dem Build synchron gehalten | Aus den Versionsressourcen der gebauten EXE erzeugt oder in der Versionsverwaltung gepflegt und übergeben |
| Paketieren und signieren | Getrennte Werkzeuge, Signierung nachträglich angeflanscht | Ein Befehl, mit an das Zertifikatssubjekt angeglichener Publisher-Identität |
| Den Build scheitern lassen | Exit-Codes trennen ein ungültiges Paket nicht von einem fehlgeschlagenen Lauf | Die Validierung liefert einen eigenen Code für analysiert-aber-ungültig, das Gate ist damit eindeutig |
| Sideload-Updates | App-Installer-Manifest von Hand geschrieben und gepflegt | Aus der echten Identität des signierten Pakets erzeugt, Bundle-fähig |
The problem
Entwicklungsteams und Softwarehersteller stecken nicht im selben Problem wie ein Migrationsteam. Hier ist kein Installer verloren und nichts zu erfassen: Der Build funktioniert bereits. Die Reibung liegt in allem, was danach kommt. MSIX-Paketierung bedeutete bisher eine Windows-SDK-Abhängigkeit auf dem Build-Agenten, einen nachträglich angeflanschten Signierschritt, Zertifikatsverwaltung, für die sich niemand zuständig fühlt, und keinen verlässlichen Weg, einen Build scheitern zu lassen, wenn das Paket falsch ist. Das Ergebnis: Paketierung wird zur manuellen Aufgabe, die jemand zum Release erledigt, und genau dort erreichen Fehler die Kunden.
Mit dem Standardwerkzeug zu paketieren heißt, das Windows-SDK auf jedem Agenten zu installieren und die Version zu fixieren. Das ist eine schwere Abhängigkeit für einen Schritt, und sie driftet zwischen Agenten so auseinander, dass es erst am Release-Tag auffällt.
Windows installiert kein unsigniertes MSIX, Signierung ist also nicht optional. Sie nach der Paketierung anzuflanschen bedeutet meist eine Zertifikatsdatei auf der Platte mit ihrem Passwort in einer Build-Definition, oder einen manuellen Schritt von der Person, die das Zertifikat hat.
Ohne ein Validierungs-Gate, das ein ungültiges Paket von einem fehlgeschlagenen Lauf unterscheidet, kann ein kaputtes Paket die Pipeline passieren und einen Kunden erreichen, wo es zur Installationszeit statt zur Build-Zeit scheitert.
Bei jedem Rebuild ein vollständiges Paket zu bauen ist unnötig und langsam. Also testen Teams die paketierte Form erst spät, und Container-spezifisches Verhalten überrascht sie am Ende.
What changes
Die Paketierungsbefehle nehmen dieselben Schalter wie makeappx.exe, ein bestehendes Skript läuft also weiter, wenn die Binärdatei getauscht wird. Diese Befehle sind lizenzfrei, die Einführung beginnt also nicht mit einem Beschaffungsgespräch, und die Engine ist die Betriebssystemkomponente statt einer Nachbildung.
Erzeugen Sie ein Manifest aus den Versionsressourcen und der Architektur der gebauten EXE, oder pflegen Sie eines in der Versionsverwaltung, damit Identität, Publisher und Capabilities wie jede andere Datei geprüft werden. Dann erstellen und signieren Sie mit einem Befehl, über einen Zertifikatsspeicher per Thumbprint, damit kein Passwort in eine Build-Definition geschrieben wird, mit einem RFC-3161-Zeitstempel, damit Signaturen das Zertifikat überdauern.
Die Schema-Validierung läuft als Preflight, und der Validierungsbefehl liefert einen eigenen Exit-Code für ein Paket, das analysiert und als ungültig befunden wurde, getrennt von einem Lauf, der schlicht fehlschlug. Auf einem Release-Kandidaten installiert ein Smoke-Test das signierte Paket, startet und schließt es, deinstalliert es und schreibt einen JSON-Report, und ein Bewertungslauf bewertet es gegen Best Practices der Paketierung.
Registrieren Sie während der Entwicklung das Build-Ergebnis als loses Paket, statt bei jedem Rebuild neu zu paketieren, und validieren, starten und räumen Sie dann in einem Durchgang gegen eine isolierte Staging-Kopie auf. Für Sideload-Auslieferung erzeugen Sie ein App-Installer-Manifest aus der echten Identität des signierten Pakets, sodass installierte Kopien sich von einem HTTPS-Speicherort selbst aktualisieren.
How we deliver it
Diese Route wird von EtherApps Forge geführt, konkret von seiner forge_msix-CLI. Forge ist eine Win32-Anwendung, die Sie in Ihrer eigenen Umgebung betreiben statt als gehosteten Dienst, sodass Build-Artefakte, Zertifikate und Paketierung unter Ihrer Kontrolle und in Ihrer Pipeline bleiben. Hat dieselbe Organisation auch zugekaufte Software mit verlorenen Installern, deckt die Capture-First-Route auf der Seite MSIX-Paketierung und Deployment diese Hälfte der Umgebung über denselben Signier- und Auslieferungsweg ab.
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
Lizenzierung, Abhängigkeiten des Build-Agenten, Signierung und der Unterschied zur Capture-First-Route für Legacy-Anwendungen.
Nein, und der Unterschied ist wichtig. Capture-First-Paketierung existiert für Anwendungen, deren Installer verloren ist, sodass die laufende Anwendung zur Quelle der Wahrheit wird. Diese Route setzt das Gegenteil voraus: Sie haben einen intakten Build-Ordner und wollen ihn als Pipeline-Schritt paketiert, signiert und validiert haben. Beide teilen sich am Ende denselben Signier-, Validierungs- und Intune-Auslieferungsweg, weshalb Umgebungen mit zugekaufter und selbst gebauter Software eine Route für beides nutzen können.
Nicht für die makeappx-kompatiblen Befehle. Packen, Entpacken, Bundling, Unbundling, Validieren und Ressourcen-Indizierung sind lizenzfrei, forge_msix funktioniert also als echter Drop-in-Ersatz für makeappx.exe, ohne dass etwas gekauft werden muss. Die Mehrwert-Workflows, also Erstellen aus einem Manifest, Signieren, Testen, Bewertung, Zertifikatsverwaltung und die Entwickler-Registrierungsbefehle, brauchen eine aktive EtherApps Forge Lizenz.
Nein. Die CLI ruft die Windows-Paketierungs-API direkt auf, und diese Engine ist eine Betriebssystemkomponente statt einer SDK-Abhängigkeit. Pakete erhalten damit dieselbe Schema-Prüfung, Block-Map und Struktur, die makeappx erzeugt. Der Agent braucht Windows 10 Version 1709 oder neuer oder Windows 11, auf x64. Die Bereitstellung ist ein Ordner, den Sie kopieren und in den PATH legen, ohne Installer.
Signieren Sie über einen Zertifikatsspeicher per Thumbprint oder Subjekt statt über eine PFX-Datei auf der Platte, damit kein Passwort in eine Build-Definition geschrieben wird. Fügen Sie einen RFC-3161-Zeitstempelserver hinzu, damit Signaturen nach Ablauf des Zertifikats gültig bleiben. Setzen Sie den Publisher in Ihrem Manifest exakt auf das Zertifikatssubjekt und lassen Sie den Publisher-Modus strikt, damit eine Abweichung den Build stoppt, statt still die Identität zu ändern, die Ihre Kunden bereits installiert haben.
Führen Sie den Validierungsbefehl mit JSON-Ausgabe aus und verzweigen Sie über den Exit-Code. Er unterscheidet ein analysiert-aber-ungültiges Paket von einem operativen Fehler, und das ist der Unterschied zwischen einem kaputten Paket und einem kaputten Agenten. Halten Sie die Schalter, die einen Build an Validierungs- oder Semantikfehlern vorbeilaufen lassen, aus Release-Pipelines heraus; sie sind Diagnosewerkzeuge, um herauszufinden, warum ein Paket nicht baut, keine Einstellungen, die man aktiviert lässt.
Ja. Vor MSIX geschriebene Anwendungen setzen oft Verhalten voraus, das der Container nicht erlaubt, etwa das Schreiben neben die eigene EXE oder einen fest erwarteten Installationspfad. Forge stellt das Package Support Framework bereit, sodass diese Fälle mit Datei- und Registry-Umleitung sowie Korrekturen des Arbeitsverzeichnisses behoben werden, ohne Änderung an Ihrem Quellcode. Bei eigener Software beheben Sie das Verhalten vielleicht lieber an der Quelle, aber das Framework sorgt dafür, dass ein Release währenddessen nicht blockiert ist.
Erzeugen Sie ein App-Installer-Manifest aus dem signierten Paket. Es leitet die Identität aus dem Paket selbst ab und ist Bundle-fähig. Veröffentlichen Sie das Paket und dieses Manifest an einem HTTPS-Speicherort, dann können installierte Kopien sich von dort selbst aktualisieren. Das gibt Sideload- und Unternehmenskunden einen Update-Pfad ohne Store-Eintrag und ohne manuelle Neuinstallation.
Ja. Ein Paket lässt sich in ein Arbeitsverzeichnis entpacken, chirurgisch bearbeiten, validieren und neu packen: Manifestwerte, Capabilities, Payload-Dateien und die virtuelle Registry des Pakets sind alle änderbar, und jede Manifestbearbeitung wird vor dem Schreiben validiert, sodass eine fehlerhafte Änderung abgelehnt statt gespeichert wird. Neu zu packen ändert den Content-Hash, das Paket muss danach also erneut signiert werden.
Start here
Starten Sie mit dem kostenlosen 7-Tage-Test von EtherApps Forge und paketieren Sie einen echten Build von Anfang bis Ende, oder sprechen Sie mit uns über die Pipeline, die Sie bereits betreiben, und darüber, wo der Paketierungsschritt darin sitzen sollte.
