Installer-Details fressen Entwicklungszeit
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.
Solution
Packen Sie Ihre Windows-App als signed MSIX.
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.
Kein SDK
die CLI ruft die Windows-Paketierungs-Engine direkt auf dem Build-Agent auf
Lizenzfrei
die makeappx-kompatiblen Verben brauchen überhaupt keine Lizenz
Ein Schritt
erstellen, signieren, validieren und Smoke-Test in der Release-Pipeline
So funktioniert es
Bauen Sie Ihr MSIX mit forge_msix in fünf Schritten.
Die Binaries haben Sie bereits. Diese Schritte machen daraus ein signiertes Paket, das Ihre Kunden installieren können.
forge_msix auf den Build-Agent legen
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.
Auf Ihren veröffentlichten Build-Ordner zeigen
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.
Appx-Manifest vorbereiten
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.
Erstellen und in einem Befehl signieren
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.
Validieren und das signierte MSIX ausliefern
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
Was eine Release-Pipeline braucht, und wo das Standard-Tooling endet
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 |
The problem
Warum Entwickler und ISVs immer noch mit MSIX-Paketierung kämpfen.
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.
Der Build-Agent trägt Tooling, das er nicht braucht
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.
Enterprise-Käufer verlangen ein sauberes Paket
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.
Ein schlechtes Paket scheitert still
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.
What changes
Was sich für Entwickler und ISVs ändert
Drop-in-Ersatz für makeappx
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.
Manifest, Paket und Signatur in einem Schritt
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.
Ein Build-Gate, dem Sie vertrauen können
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.
Schnellerer Inner Loop und ein Update-Feed
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.
Die Build-zu-MSIX-Pipeline
Vom Build-Ordner zum signierten MSIX als eine Pipeline-Stufe.
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.
How we deliver it
Produktzuordnung
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.
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
- Ein ISV, der ein Windows-Desktop-Produkt ausliefert, das Kunden als signiertes MSIX statt als Legacy-Installer wollen.
- Ein Entwicklungsteam, das bereits eine MSI oder setup.exe veröffentlicht und ein sauber deinstallierbares Format für Enterprise-Kunden braucht.
- Direkt-Download-Verteilung, bei der Endnutzer das signierte Paket öffnen und installieren.
- Enterprise-Bereitstellung über Microsoft Intune oder Configuration Manager, sobald das Paket signiert und validiert ist.
- Sideload-Verteilung außerhalb eines Stores, mit App-Installer-Update-Feed statt manueller Neuinstallation.
- Ersatz von makeappx.exe in einem CI-Skript, das bereits funktioniert, ohne die Pipeline umzuschreiben.
FAQ
Fragen, die Entwickler und ISVs zuerst stellen.
Lizenzierung, Build-Agent-Abhängigkeiten, Signierung, CI-Integration und der Unterschied zur Capture-first-Route für Legacy-Anwendungen.
Ist das dasselbe wie Ihre Legacy-Anwendungs-Erfassung?
Nein, 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.
Wie baue ich mit Forge ein MSIX aus meiner App?
Legen Sie forge_msix in den Agent-PATH, zeigen Sie auf Ihren veröffentlichten Build-Ordner, führen Sie forge_msix prepare aus, um ein Manifest aus der gebauten ausführbaren Datei zu erzeugen, dann forge_msix create mit Signierung aus dem Zertifikatspeicher per Thumbprint. Gate den Release mit forge_msix validate und erzeugen Sie optional einen App-Installer-Feed für Sideload-Updates. Dieselben Schalter, die ein bestehendes makeappx-Skript bereits nutzt, funktionieren weiter.
Kann ich forge_msix in meine CI/CD-Pipeline integrieren?
Ja. forge_msix ist eine CLI für unbeaufsichtigte Agenten. Führen Sie sie aus Azure DevOps, GitHub Actions, GitLab CI, Jenkins oder jedem skriptbasierten Windows-Build-Agent aus. Paketierung, Signierung und Validierung werden Stufen derselben Release-Definition wie Ihre übrigen Artefakte.
Brauchen wir eine Lizenz für den Einsatz in unserer Pipeline?
Nicht für die makeappx-kompatiblen Verben. Packen, Entpacken, Bundeln, Entbundeln, Validieren und Ressourcenindexierung sind lizenzfrei, sodass forge_msix als echter Drop-in-Ersatz für makeappx.exe ohne Kauf funktioniert. Die Mehrwert-Workflows, also Erstellen aus einem Manifest, Signieren, Testen, Assessment, Zertifikatsverwaltung und die Entwickler-Registrierungsverben, brauchen eine aktive EtherApps Forge-Lizenz.
Braucht der Build-Agent das Windows SDK?
Nein. Die CLI ruft die Windows-Paketierungs-API direkt auf, und diese Engine ist eine Betriebssystemkomponente, keine SDK-Abhängigkeit, sodass Pakete dieselbe Schema-Durchsetzung, Block Map und Layout wie makeappx erhalten. 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.
Wie sollten wir Code Signing in CI handhaben?
Signieren Sie aus dem Zertifikatspeicher per Thumbprint oder Subject statt aus einer PFX-Datei auf der Festplatte, sodass kein Passwort in der Build-Definition landet. Fügen Sie einen RFC-3161-Zeitstempelserver hinzu, damit Signaturen nach Ablauf des Zertifikats gültig bleiben. Setzen Sie den Publisher im Manifest auf das exakte Zertifikatssubjekt und lassen Sie den Publisher-Modus streng, damit eine Abweichung den Build stoppt statt die Identität still zu ändern, die Kunden bereits installiert haben.
Wie lassen wir den Build fehlschlagen, wenn das Paket falsch ist?
Führen Sie das Validierungsverb mit JSON-Ausgabe aus und verzweigen Sie nach Exit-Code. Es trennt ein analysiertes-aber-ungültiges Paket von einem betrieblichen Fehler, also den Unterschied zwischen kaputtem Paket und kaputtem Agent. Lassen Sie Schalter, die einen Build an Validierungs- oder Semantikfehlern vorbei weiterlaufen lassen, aus Release-Pipelines heraus; sie sind Diagnosewerkzeuge, keine dauerhaften Einstellungen.
Können wir unseren eigenen Build auch dann paketieren, wenn Container-Fix-ups nötig sind?
Ja. Anwendungen vor MSIX setzen oft Verhalten voraus, das der Container nicht erlaubt, etwa Schreiben neben der eigenen ausführbaren Datei oder einen festen Installationspfad. Forge stellt das Package Support Framework bereit, sodass solche Fälle mit Datei- und Registry-Umleitung sowie Working-Directory-Fix-ups korrigiert werden, ohne Quellcodeänderung. Für eigene Software bevorzugen Sie vielleicht eine Korrektur an der Quelle, aber das Framework bedeutet, dass ein Release nicht blockiert ist, während Sie das tun.
Was ist mit Updates für Kunden, die sideloaden statt einen Store zu nutzen?
Erzeugen Sie ein App-Installer-Manifest aus dem signierten Paket, das die Identität aus dem Paket selbst ableitet und Bundle-fähig ist. Veröffentlichen Sie Paket und Manifest an einem HTTPS-Standort, und installierte Kopien können sich von dort aktualisieren. So bekommen Sideload- und Enterprise-Kunden einen Update-Pfad ohne Store-Listing oder manuelle Neuinstallation.
Können wir ein bereits ausgeliefertes Paket ohne Rebuild reparieren?
Ja. Ein Paket kann in ein Arbeitsverzeichnis extrahiert, gezielt bearbeitet, validiert und neu gepackt werden: Manifestwerte, Capabilities, Payload-Dateien und die virtuelle Registry des Pakets lassen sich ändern, und jede Manifeständerung wird vor dem Schreiben validiert, sodass eine fehlerhafte Änderung abgelehnt statt gespeichert wird. Neu packen ändert den Content-Hash, daher muss das Paket danach erneut signiert werden.
Start here
Machen Sie ein signiertes MSIX zu einem Build-Artefakt, nicht zu einem Job zur Release-Zeit.
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.
- Die Paketierungsverben spiegeln makeappx eins zu eins und brauchen keine Lizenz, sodass ein funktionierendes CI-Skript Forge durch Binary-Tausch übernehmen kann statt durch Pipeline-Umschreiben.
- Paketierung, Signierung, Validierung und Smoke-Test sind Stufen desselben Tools, sodass ein signiertes MSIX aus dem Release-Build fällt wie jedes andere Artefakt, statt zur Release-Zeit von Hand zusammengebaut zu werden.
- Validierung liefert einen eigenen Exit-Code für ein ungültiges Paket, sodass das Build-Gate ein schlechtes Paket fängt, bevor ein Kunde es tut.
- Forge ist eine Win32-Anwendung in Ihrer eigenen Umgebung, sodass Build-Artefakte und Signing-Zertifikate Ihre Pipeline nie verlassen.