EtherApps Forge 1.0.6 ist da und erweitert das Produkt gleich in zwei Richtungen. Legacy-Anwendungen, die sich sauber paketieren lassen, sich danach im MSIX-Container aber fehlerhaft verhalten, können jetzt mit Package-Support-Framework-Fix-ups behoben werden, die als Teil der Paketierung bereitgestellt werden. Und zum ersten Mal ist Forge nicht nur für Anwendungen da, die Sie aus fremden Umgebungen erfassen: Die forge_msix-CLI ist ein Drop-in-Ersatz für Microsofts makeappx.exe, sodass ein Entwicklungsteam oder ein Softwarehersteller den eigenen Build-Ordner innerhalb einer bestehenden Pipeline in ein signiertes, validiertes MSIX verwandeln kann.
Beide Änderungen adressieren dieselbe Beschwerde von entgegengesetzten Enden des Paketierungsproblems. Ein Paket überhaupt zu bauen ist schon länger nicht mehr der schwierige Teil. Es korrekt zum Laufen zu bringen, und zwar bei jedem einzelnen Build, ist die eigentliche Arbeit.
PSF-Kompatibilitäts-Fix-ups: wenn die App sauber paketiert, sich aber nicht benimmt
Das frustrierendste Ergebnis in einem MSIX-Programm ist nicht ein Paket, das nicht baut. Es ist ein Paket, das baut, signiert, installiert, startet und dann stillschweigend das Falsche tut.
Das passiert, weil der MSIX-Container die Regeln ändert, gegen die eine ältere Anwendung geschrieben wurde. Drei Muster verursachen den größten Teil davon:
- Schreiben neben die eigene EXE. Anwendungen, die Einstellungen, Logs oder Lizenzdateien in ihren eigenen Installationsordner ablegen, schreiben an eine Stelle, die der Container schützt.
- Annahme eines festen Installationspfads. Alles mit einem fest codierten
C:\Program Files\Vendor\App-Pfad oder ein Launcher, der ein bestimmtes Arbeitsverzeichnis erwartet, findet beides nicht dort, wo es erwartet wird. - Lesen von Maschinen-Registry-Pfaden. Konfiguration unter
HKLM, die der Container umleitet, liegt nicht mehr dort, wo die Anwendung sie sucht.
Das Package Support Framework ist Microsofts Open-Source-Antwort auf genau das. Es wendet gezielte Fix-ups zur Laufzeit an, ohne jede Änderung am Quellcode der Anwendung, und die wichtigen sind Datei- und Registry-Umleitung sowie die Korrektur des Arbeitsverzeichnisses. Wenn es für eine Legacy-Anwendung keinen Hersteller mehr gibt, der sie neu baut, ist PSF oft der Unterschied zwischen einer Anwendung, die ausgeliefert wird, und einer, die abgeschrieben wird.
Ab 1.0.6 stellt Forge das Framework als Teil der Paketierung bereit, statt es als manuellen Schritt danach zu hinterlassen. Der praktische Effekt auf eine Bewertung: Die Kategorie der Anwendungen mit dem Vermerk "läuft mit Fix-ups" wird deutlich größer, und die Kategorie "kann noch nicht umziehen" wird kleiner. Warum diese Remediation-Schicht für App Attach und MSIX-Auslieferung zählt, haben wir in Package Support Framework und das MSIX-App-Attach-Risiko beschrieben, und es gilt genauso direkt für über Intune ausgelieferte Pakete auf physischen Geräten.
Entwickler- und ISV-Paketierung: Ihre eigenen Builds, signiert und validiert
Capture-First-Paketierung löst ein Legacy-Problem: Der Installer ist weg, also wird die laufende Anwendung zur Quelle der Wahrheit. Das war nie der ganze Markt. Viele Teams haben einen völlig intakten Build-Ordner und finden MSIX trotzdem sperrig, weil das Werkzeug drumherum eine installierte Windows-SDK, einen nachträglich angeflanschten Signierschritt und einen Menschen zur Prüfung des Ergebnisses voraussetzt.
forge_msix ist als Drop-in-Ersatz für makeappx.exe gebaut. Es ruft die Windows-Paketierungs-Engine direkt auf, statt darauf angewiesen zu sein, dass die SDK auf dem Build-Agent installiert ist, und die Paketierungsbefehle nehmen dieselben Schalter, sodass ein bestehendes Skript weiterläuft, wenn Sie die Binärdatei austauschen.
Über die Parität hinaus ergänzt das Release die Teile, die eine Release-Pipeline wirklich braucht:
# 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
Drei Details sind wichtig, wenn Sie das in CI verdrahten. Signieren Sie über einen Zertifikatsspeicher per Thumbprint statt über eine PFX-Datei auf der Platte, damit kein Passwort in einer Build-Definition landet. Fügen Sie einen RFC-3161-Zeitstempel hinzu, damit Signaturen nach Ablauf des Zertifikats gültig bleiben. Und verzweigen Sie über den Exit-Code, denn validate unterscheidet "das Paket wurde analysiert und ist ungültig" von "der Lauf selbst ist fehlgeschlagen", und das ist der Unterschied zwischen einem kaputten Build und einem kaputten Agenten.
Es gibt außerdem einen Smoke-Test-Befehl, der das signierte Paket installiert, startet und schließt, deinstalliert und einen JSON-Report schreibt, sowie einen Bewertungslauf, der ein Paket gegen Best-Practice-Signale der Paketierung bewertet. Keiner von beiden gehört in jeden Commit. Beide lohnen sich für einen Release-Kandidaten.
Für Teams, die außerhalb eines Stores ausliefern, erzeugt make-appinstaller das .appinstaller-Manifest aus der echten Identität des signierten Pakets, sodass sich seitlich geladene Kopien von einem HTTPS-Speicherort selbst aktualisieren können.
Was das bedeutet, wenn Ihre Umgebung gemischt ist
Die meisten Organisationen sind nicht rein das eine oder das andere. Sie haben zugekaufte Software mit verlorenen Installern, eine Handvoll intern gebauter Branchenanwendungen und eine Windows-11- oder Intune-Frist, die für alles gilt. Bisher nahmen diese beiden Hälften unterschiedliche Wege und unterschiedliche Werkzeuge.
Mit 1.0.6 teilen sie sich einen Paketierungsweg: Capture-First für die Anwendungen, deren Installer verschwunden ist, Build-Ordner-Paketierung für die, die Ihre eigenen Entwickler kompilieren, PSF-Remediation für alles, was der Container stört, und am Ende dieselbe Signierung, Validierung und Intune-Auslieferung. Die Routenentscheidung bleibt bei einem Menschen. Die Mechanik hört auf, zwei getrennte Projekte zu sein.
Verfügbarkeit
EtherApps Forge 1.0.6.0 ist ab sofort verfügbar. Forge ist eine Win32-Anwendung, die Sie in Ihrer eigenen Umgebung betreiben statt als gehosteter Dienst, sodass Captures und Paketierung unter Ihrer Kontrolle bleiben, und es erfasst sowohl von älteren als auch von aktuellen Windows-Versionen. Jede Lizenz enthält Training und Support, und es gibt einen kostenlosen 7-Tage-Test, damit ein Paketierungs-, Endpoint- oder Entwicklungsteam das Ergebnis an einer echten Anwendung nachweisen kann, bevor die breitere Umgebung angegangen wird.
Wenn Ihr Blocker eine Legacy-Anwendung ist, die niemand neu bauen kann, starten Sie mit Legacy-Windows-Anwendungen modernisieren oder unserem Leitfaden zum Repackaging einer Anwendung, wenn der Installer verloren ist. Geht es um die Auslieferungsseite, deckt MSIX-Paketierung und Deployment Signierung, PSF-Prüfung und Intune-Rollout ab. Das Produkt selbst finden Sie unter EtherApps Forge.
Testen Sie EtherApps Forge 7 Tage kostenlos und paketieren Sie eine echte Anwendung, erfasst oder selbst gebaut, von der Quelle bis zum signierten MSIX.