Lösung
Für Entwickler und ISVs, die bereits eine funktionierende Desktop-App kompilieren. Konzentrieren Sie sich auf Ihr Produkt, nicht auf Installer-Technik. Die forge_msix-CLI von EtherApps Forge macht aus einem Build-Ordner ein signiertes, validiertes MSIX als Pipeline-Stufe, ohne Windows SDK auf dem Agent und ohne das Skript umzuschreiben, das Sie bereits nutzen.
7 Tage kostenlos den vollständigen Workflow testen · Lizenzen enthalten Schulung und Support
Keine Kreditkarte. Erfassen Sie eine echte Anwendung am ersten Tag.
So funktioniert es
Die Binaries haben Sie bereits. Diese Schritte machen daraus ein signiertes Paket, das Ihre Kunden installieren können.
Kopieren Sie den CLI-Ordner in den PATH. Keine Windows-SDK-Installation, kein Versions-Pinning von SDK-Tools über Agenten hinweg. Die CLI ruft die Paketierungs-Engine auf, die mit Windows geliefert wird.
Starten Sie mit dem Ordner, den Ihre CI bereits erzeugt: ausführbare Dateien, Abhängigkeiten und alles, was ins Paket gehört. Es gibt nichts zu erfassen. Der Build ist die Quelle der Wahrheit.
Führen Sie forge_msix prepare gegen die gebaute ausführbare Datei aus, um ein Manifest aus Versionsressourcen und Architektur zu erzeugen, oder behalten Sie ein geprüftes Manifest in der Quellkontrolle und übergeben Sie es.
Führen Sie forge_msix create gegen den Build-Ordner aus, mit Signierung aus dem Zertifikatspeicher per Thumbprint und RFC-3161-Zeitstempel. Die Publisher-Identität wird am Zertifikatssubjekt ausgerichtet, damit Kunden eine stabile Paketidentität erhalten.
Führen Sie forge_msix validate aus und lassen Sie den Build bei einem ungültigen Paket fehlschlagen. Liefern Sie das Artefakt für Direkt-Download, Microsoft Intune oder Configuration Manager aus, oder erzeugen Sie einen App-Installer-Update-Feed für Sideload-Kunden.
Pipeline-Passung
Ein Build als MSIX zu paketieren ist nicht eine Aufgabe. Es sind Manifest, Paket, Signatur, Validierung, Test und Update-Pfad. Verglichen nach Stufe, nicht nach Produkt:
| Pipeline-Stufe | Standard-Windows-SDK-Tooling | forge_msix |
|---|---|---|
| Build-Agent-Setup | Windows SDK installiert und auf jedem Agent versioniert | Eine Kopie des CLI-Ordners im PATH. Sie ruft die Paketierungs-Engine auf, die mit Windows kommt |
| Manifest | Handgeschrieben und manuell mit dem Build synchron gehalten | Aus den Versionsressourcen der gebauten ausführbaren Datei erzeugt, oder in der Quellkontrolle und übergeben |
| Paketieren und signieren | Getrennte Tools, Signierung nachträglich angehängt | Ein Befehl, mit Publisher-Identität am Zertifikatssubjekt ausgerichtet |
| Build fehlschlagen lassen | Exit-Codes trennen kein ungültiges Paket von einem fehlgeschlagenen Lauf | Validierung liefert einen eigenen Code für analysiert-aber-ungültig, damit das Gate klar ist |
| Sideload-Updates | App-Installer-Manifest handgeschrieben und gepflegt | Aus der echten Identität des signierten Pakets erzeugt, Bundle-fähig |
Das Problem
Entwickler und ISVs stecken nicht im gleichen Problem wie ein Migrationsteam. Es gibt keinen verlorenen Installer und nichts zu erfassen: der Build funktioniert bereits. Die Reibung ist alles danach. MSIX-Paketierung bedeutete eine Windows-SDK-Abhängigkeit auf dem Build-Agent, einen nachträglich angehängten Signierschritt, Zertifikatsverwaltung ohne klaren Owner und keinen zuverlässigen Weg, einen Build bei einem falschen Paket fehlschlagen zu lassen. Paketierung wird zu einem manuellen Job zur Release-Zeit, genau dort, wo Fehler Kunden erreichen.
Unabhängige Softwarehersteller und Produktteams verbringen zu viel Zeit mit Windows-Paketierungs-Eigenheiten statt Features zu liefern. MSIX sollte ein Release-Schritt sein, kein Nebenprojekt.
Paketierung mit dem Standardtool bedeutet, das Windows SDK auf jedem Agent zu installieren und zu versionieren. Das ist eine schwere Abhängigkeit für einen Schritt, und sie driftet zwischen Agenten, was oft erst am Release-Tag auffällt.
Kunden, die mit Intune oder Configuration Manager deployen, brauchen oft ein signiertes MSIX, bevor sie kaufen. Wenn Paketierung langsam oder manuell ist, wird sie zum kommerziellen Blocker statt nur zu einem technischen.
Ohne ein Validierungs-Gate, das ein ungültiges Paket von einem fehlgeschlagenen Lauf trennt, kann ein kaputtes Paket die Pipeline passieren und erst beim Kunden zur Installationszeit scheitern statt zur Build-Zeit.
Was sich ändert
Die Paketierungsverben nutzen dieselben Schalter wie makeappx.exe, sodass ein bestehendes Skript weiterläuft, wenn die Binary getauscht wird. Diese Verben sind lizenzfrei, sodass die Einführung nicht mit einer Beschaffung beginnt, und die Engine ist die Betriebssystemkomponente, keine Neuimplementierung.
Erzeugen Sie ein Manifest aus Versionsressourcen und Architektur der gebauten ausführbaren Datei, oder behalten Sie eines in der Quellkontrolle, damit Identität, Publisher und Capabilities wie jede andere Datei geprüft werden. Dann erstellen und signieren Sie in einem Befehl aus dem Zertifikatspeicher per Thumbprint, ohne Passwort in der Build-Definition, mit RFC-3161-Zeitstempel, damit Signaturen das Zertifikat überdauern.
Schema-Validierung läuft als Preflight, und das Validierungsverb liefert einen eigenen Exit-Code für ein analysiertes und für ungültig befundenes Paket, getrennt von einem Lauf, der einfach fehlgeschlagen ist. Auf einem Release Candidate installiert ein Smoke-Test das signierte Paket, startet und schließt es, deinstalliert es und schreibt einen JSON-Report.
Während der Entwicklung registrieren Sie die Build-Ausgabe als loses Paket statt bei jedem Rebuild neu zu paketieren, und validieren, starten und räumen in einem Durchgang auf. Für Sideload-Verteilung erzeugen Sie ein App-Installer-Manifest aus der echten Identität des signierten Pakets, damit installierte Kopien sich von einem HTTPS-Standort aktualisieren.
Forge MSIX CLI für Build-Pipelines und MSP-Packaging-Fabriken: erfassen, signieren und ein bereitstellungsbereites MSIX aus einem einzigen Befehl produzieren. Keine GUI erforderlich.
Forge bewertet jedes MSIX gegen Best-Practice-Signale aus derselben CLI-Sitzung: Capabilities, Publisher-Alignment, visuelle Assets und Trust-Status.
Hier starten
Sehen Sie das live in Ihrem eigenen Tenant.
Die Build-zu-MSIX-Pipeline
forge_msix erzeugt ein Manifest aus der gebauten ausführbaren Datei, paketiert und signiert in einem Befehl, validiert das Ergebnis mit einem Build-fehlschlagenden Exit-Code und erzeugt ein signiertes MSIX. Ein kurzer Zweig veröffentlicht einen App-Installer-Update-Feed für Sideload-Kunden. Jede Stufe läuft in der Release-Pipeline, die Sie bereits haben.
So setzen wir es um
Diese Route wird von EtherApps Forge geführt, speziell von der forge_msix-CLI. Forge ist eine Win32-Anwendung, die Sie in Ihrer eigenen Umgebung bereitstellen, kein gehosteter Dienst, sodass Build-Artefakte, Zertifikate und Paketierung unter Ihrer Kontrolle und in Ihrer Pipeline bleiben. Wenn dieselbe Organisation auch zugekaufte Software mit verlorenen Installern hat, deckt die Capture-first-Route auf der Seite MSIX-Paketierung und Bereitstellung diese Hälfte des Estates über denselben Signing- und Delivery-Pfad ab.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
7 Tage kostenlos den vollständigen Workflow testen · Lizenzen enthalten Schulung und Support
Fragen
Lizenzierung, Build-Agent-Abhängigkeiten, Signierung, CI-Integration und der Unterschied zur Capture-first-Route für Legacy-Anwendungen.
Fragen Sie uns im Packaging-Fit-CheckNein, und der Unterschied ist wichtig. Capture-first-Paketierung gibt es für Anwendungen, deren Installer verloren ist, sodass die laufende Anwendung zur Quelle der Wahrheit wird. Diese Route nimmt das Gegenteil an: Sie haben einen gesunden Build-Ordner und wollen ihn als Pipeline-Schritt paketieren, signieren und validieren. Beide teilen am Ende denselben Signing-, Validierungs- und Intune-Delivery-Pfad, weshalb Estates mit zugekaufter und selbst gebauter Software einen Weg für beides nutzen können.
Überprüft am 26. August 2026.
Hier starten
Starten Sie mit der kostenlosen 7-Tage-Testversion von EtherApps Forge und paketieren Sie einen echten Entwickler- oder ISV-Build Ende zu Ende, oder sprechen Sie mit uns über die Pipeline, die Sie bereits betreiben, und wo der Paketierungsschritt sitzen sollte.
Keine Kreditkarte. Erfassen Sie eine echte Anwendung am ersten Tag.
