Wenn der Paketmanager dreimal klingelt...

MSIX jetzt allgemein verfügbar: Microsoft baut Support für neues Paketformat aus
Keine Kommentare

Unixoide Betriebssysteme waren Windows seit jeher in Sachen Einfachheit der Applikationsinstallation überlegen – es geht nun einmal nichts darüber, Arbeit an Paketmanager zu delegieren. Mit MSIX wagt Microsoft einen weiteren Anlauf, der sich an die Bedürfnisse von Enterprise-Entwicklern und Systemadministratoren richtet.

Beginnen wir mit einem historischen Rückblick: Einer der ersten Artikel des Autors für diese damals noch dot.net Magazin genannte Fachzeitschrift befasste sich mit dem .cab-Format. Microsoft nutzte Windows Mobile, um erste Gehversuche mit einem „Paketierungsformat“ zu wagen. Als Windows 8 das Konzept der App auf den Desktop brachte, war die Universal Windows Platform (UWP) naturgemäß mit einem ähnlichen Feature ausgestattet.

Problematisch war in diesem Zusammenhang, dass klassische Apps von der Verteilung in der UWP ausgenommen waren. Mit der Desktop Bridge schuf Microsoft hier zu einem gewissen Grad Abhilfe, eine hundertprozentige Lösung wurde allerdings nicht erreicht.

Auf seiner Entwicklerkonferenz Microsoft Build identifizierte das Unternehmen in diesem Jahr ganz konkret zwei Problempunkte: Zum einen die mangelnde Kompartmentalisierung und zum anderen unnötigen Arbeitsaufwand bei der Auslieferung von Applikationen im Enterprise-Umfeld. In vielen, wenn nicht sogar in allen Fällen ist es so, dass die .msi-Datei vor der Auslieferung vom Administrator „umgepackt“ wird. Das verlangsamt die Auslieferung von Updates und reduziert die Agilität der Infrastruktur – ein Problem, das Kunden immer wieder rückmelden.

Auf Basis der Blockmap

Die wichtigste Feststellung beim Umstieg von klassischen Installationsprogrammen zu .cab-Dateien war, dass ein Installationspaket fortan kein Programm, sondern nur noch eine Ansammlung von Metadaten war. Das eigentliche Ausliefern erfolgte fortan durch eine Betriebssystemkomponente, die in der Metadatei befindliche Informationen auslas und gegen das vorliegende System ausführte.

MSIX ist von den schon bekannten APPX-Paketen abgeleitet. APPX-Files bringen mit der „Blockmap“ eine Art Übersicht des Gesamtpakets mit, die die im Archiv enthaltenen Elemente anhand ihrer kryptographischen Hashes beschreibt. Microsoft nutzte diese Funktion bisher zur Verifikation heruntergeladener Elemente, um Transferfehler oder Manipulationen auszuschließen.

Laut dem auf der Build gehaltenen Vortrag „MSIX: Inside and Out“ möchte Microsoft die Blockmap in Zukunft vielseitiger nutzen. Zum einen sollen Updates fortan „differenziell“ erfolgen – das bedeutet, dass das Betriebssystem nur jene Elemente herunterlädt und bearbeitet, die sich auch wirklich geändert haben. Der Vortragende sprach dabei von Arbeit mit 64 KB großen Blöcken – zum Zeitpunkt der Drucklegung findet sich noch nichts Genaueres.

Ein weiterer Aspekt ist, dass Daten zwischen Nutzern und Applikationen geteilt werden. Verwenden zwei verschiedene Versionen eines Programms beispielsweise dieselbe DLL, muss sie nur noch einmal auf der Maschine liegen. Kommt später mit einem der Programme eine verbesserte Version der Bibliothek, erkennt der MSIX-Parser die Situation und führt erst dann die Duplikation durch.

Zu guter Letzt sei angemerkt, dass Microsoft das Paketformat nicht nur für Windows vorsieht. Im bei GitHub zur Verfügung stehenden SDK [2] finden sich auch Versionen für Android, iOS, MacOS und sogar Linux – man wünscht sich in Redmond, dass das MSIX einst als universelles Datenformat für die Übertragung von Applikationen dient.

Das File im Fokus

MSIX-Dateien sind Monolithen, die sich – unter Auslassung der Unterstützung für Varianten – wie in Abbildung 1 gezeigt präsentieren und aus einem Header und einer Payload bestehen.

Abb. 1: MSIX-Pakete sind zweigeteilt (Quelle: Microsoft)

Abb. 1: MSIX-Pakete sind zweigeteilt (Quelle: Microsoft)

Während die Payload die diversen zu installierenden Ressourcen in einer komprimierten Form bereitstellt, sorgt der Header für das Anliefern von Metainformationen. Neben der Signatur und der weiter oben besprochenen Blockmap sorgt das AppManifest für die Abarbeitung von Aktionen während der Installation des Pakets.

Ob der permanenten Verbreiterung des Windows-Ökosystems (Stichwort hochauflösende Bildschirme) bietet MSIX die Möglichkeit, Applikationen in konditional installierbare Teile aufzuteilen – Abbildung 2 zeigt, was man in Redmond darunter versteht.

Abb. 2: Eine MSIX-Datei muss nicht immer komplett installiert werden

Abb. 2: Eine MSIX-Datei muss nicht immer komplett installiert werden

Diese derzeit noch nicht allgemein verfügbaren Funktionen sollen dafür sorgen, dass ältere oder mit wenig Speicher ausgestattete Geräte nicht mit Ressourcen belastet werden, die sie auf ihren niedrig auflösenden Bildschirmen sowieso nicht anzeigen können.

Langfristig plant man im Hause Microsoft auch, Inspirationen aus dem Hause Google anzunehmen. Android-Applikationen lassen sich schon seit längerer Zeit „teilweise“ installieren, um die insbesondere bei technisch herausgeforderten Usern für geringe Retentionsraten sorgende Wartezeit zu reduzieren.

Angemerkt sei, dass MSIX nicht nur ein Paketierungsformat ist. Per MSIX ausgelieferte Programme werden zur Laufzeit in einen Container verpackt, um das Deinstallieren ohne große Konsequenzen zu ermöglichen. Microsoft nutzt die Einführung des neuen Formats, um den Containerwildwuchs zu zähmen – Abbildung 3 zeigt, wie sich Microsoft die Rolle der Applikationscontainer in der MSIX-Welt vorstellt.

Abb. 3: MSIX-Container stehen zwischen den Welten

Abb. 3: MSIX-Container stehen zwischen den Welten

Die Einschätzung in der Bildunterschrift deckt sich übrigens mit Microsofts offizieller Ansicht. John Vintzel, der Project Lead des MSIX-Projekts, postulierte, dass das MSIX-Format die flexibelstmögliche Art zur Verwaltung von Rechten in Containern darstellt. Entwickler haben die Wahl, wie stark oder wie schwach sie ihre Applikation absichern wollen – ob man die von der Desktop Bridge bekannten Datei- und Registry-Filter oder aber die vollwertigen UWP-Container bevorzugt, ist davon abhängig, was man im MSIX-Archiv verpackt.

Visual Studio im Handbetrieb

Microsoft versprach auf der Build, dass die hauseigene Entwicklungsumgebung in nicht allzu ferner Zukunft MSIX-Pakete direkt aus dem Solution Explorer heraus erzeugen können soll. Zum Zeitpunkt der Drucklegung dieses Hefts ist das noch nicht der Fall – auch in einer aktuellen Version dee IDE sucht man den Eintrag im Kontextmenü vergeblich.

Wer schon jetzt mit MSIX-Dateien experimentieren möchte, muss Mitglied des Windows-Insider-Programms sein. Zudem ist mindestens die Windows-Edition „Pro“ mit Build 17698 oder neuer erforderlich. Auch das Windows SDK muss als Beta vorliegen, Versionen größer oder gleich 17704 sind akzeptabel. Wer mit älteren Versionen des Produkts arbeitet, darf die Schritte ebenfalls nachvollziehen – .appx-Pakete sollen sich gegen Ende des Jahres in MSIX-Files umwandeln lassen.

Im nächsten Schritt erstellen wir eine neue Applikation für die Universal-Windows-Plattform – die Auswahl der Vorlage ist irrelevant. Der Autor arbeitet in den folgenden Schritten mit „Leere App“ und vergibt als Projektnamen SUSTestApp1. Als Zielsystem wählen wir die Windows 10 Insider Preview und schließen die Generierung des Projekts wie gewohnt ab.

Als Nächstes folgt ein Rechtsklick auf die Projektmappe, um im Kontextmenü die bekannte Option Hinzufügen | Neues Projekt zu aktivieren. Wählen Sie die Projektvorlage Windows Universal | Paketerstellungsprojekt für Windows-Anwendungen, um den an CAB-Dateien erinnernden Deployment-Prozess zu starten.

Wie im Fall des Hauptprojekts ist es auch hier wichtig, die Insider-Preview-Version des SDKs zu aktivieren. Rechtsklicken Sie danach auf den Anwendungenordner des Verpackungsprojekts, um einen Verweis auf das Hauptprojekt einzupflegen. Das Fleisch des Projekts findet sich in der Manifestdatei, in der Sie Visual Studio zum Einbinden diverser Ressourcen animieren. Auf diese Art und Weise können Sie dafür sorgen, dass in der Taskleiste sowohl niedrig- als auch hochaufgelöste Programmsymbole zur Verfügung stehen. Bei Bedarf können Sie auch Capabilities anmelden, um der Payload die Interaktion mit dem Hostbetriebssystem zu erleichtern.

Von besonderer Relevanz ist, dass sich ein Deployment-Projekt auch als Ziel für die Programmausführung festlegen lässt (Abb. 4). Klicken Sie in diesem Fall auf Run, paketiert Visual Studio das Projekt im ersten Schritt, um es daraufhin auf der Entwicklerworkstation zu installieren.

Abb. 4: Deployment-Projekte lassen sich als Ausführungsziel festlegen

Abb. 4: Deployment-Projekte lassen sich als Ausführungsziel festlegen

Dieser auf den ersten Blick sinnlos erscheinende Umweg ist in der Praxis sehr wertvoll: Denken Sie daran, dass ein MSIX-Programm in einem Container läuft. Bei direktem Deployment aus Visual Studio unterliegt das Programm den diversen Einschränkungen des Containers nicht.

Auf der Build demonstrierte der Microsoft-Manager Stefan Wick das im Vortrag „Accelerating Windows 10 enterprise app deployment with MSIX“ anhand eines kleinen MFC-Projekts, das eine lokale Konfigurationsdatei anlegte. Der verwendete Pfad wurde vom Dateifilter des Containers moniert, weshalb die Ausführung im MSIX-Container scheiterte – bei einem direkten Anstoßen wäre die Auslieferung problemlos durchgelaufen.

Wollen wir eine MSIX-Datei exportieren, klicken wir das Projekt rechts an und wählen die Option Store | App-Pakete erstellen. Der Assistent möchte von Haus aus Storepakete erzeugen, weshalb wir die Option Ich möchte Pakete für das Querladen erstellen aktivieren. Entfernen Sie den Haken vor der Checkbox Automatische Updates aktivieren, um das Deployment zu vereinfachen.

Im nächsten Schritt dürfen Sie die Architektur auswählen, die für das zu erzeugende Paket vorgesehen ist. Microsofts Vorgabe Neutral ist für uns gut geeignet; auch der Zielordner C:\Users\tamha\source\repos\SUSTestApp1\WapProjTemplate1\AppPackages\ geht in Ordnung. Je nach Konfiguration entsteht an dieser Stelle entweder eine APPXBUNDLE- oder eine MSIX-Datei – eine Workstation des Autors weigerte sich auch in der aktuellsten Konfiguration, MSIX-Dateien zu generieren.

Mit dediziertem SDK

Neben der soeben besprochenen Unterstützung in Visual Studio und der von einigen Drittanbietern geplanten Toolchain gibt es zwei weitere Werkzeuge, die Entwicklern das Leben mit dem MSIX-Format erleichtern. Als Erstes sei das ausschließlich in C++ vorliegende MSIX SDK erwähnt. Es steht auf GitHub bereit und lässt sich auf einer Vielzahl verschiedener Plattformen kompilieren und nutzen. Das dem Projekt beiliegende und aufgrund der Emulation diverser Win32 APIs umfangreiche Projektbeispiel zeigt, wie man ein MSIX-Archiv unter Nutzung des API in seine Einzelteile dekompiliert.

Im Store findet sich mit dem MSIX Packaging Tool eine Art InstallShield for MSIX. Nach dem Start präsentiert das Programm die in Abbildung 5 gezeigte dreiteilige Ansicht, in der Sie verschiedene Payloads aktivieren dürfen.

Abb. 5: Das MSIX Packaging Tool ist ein veritabler Tausendsassa

Abb. 5: Das MSIX Packaging Tool ist ein veritabler Tausendsassa

Wer von Visual Studio nur eine .appxbundle-Datei bekommt, kann sie durch Anklicken der Option Application Package promoten. Hierzu müssen Sie das Programm im ersten Schritt in eine MSI-Datei umwandeln, die sich danach schrittweise konfigurieren lässt. Von besonderem Interesse ist, dass das Werkzeug das MSI-File im Rahmen der Paketierung gegen eine virtuelle Maschine ausführt, um so Informationen über Änderungen am System zu sammeln.

Hier gilt, dass Entwickler in nicht allzu ferner Zeit mit Neuerungen rechnen müssen. Die auf der Build gezeigte Version des Packagers ist in der Lage, APPX-Dateien direkt aufzunehmen – leider ist die im Store befindliche Variante dazu noch nicht befähigt.

Fazit

Auch wenn die Suppe noch dünn ist: Microsoft versucht mit dem MSIX-Paketformat, Schwächen der Windows-Plattform zu umschiffen. Es ist davon auszugehen, dass MSIX-Files im Lauf der nächsten Monate weitergehende Unterstützung erfahren – das Anbieten einer Rückportierung für Windows 7 zeigt, dass man es in Redmond ernst meint.

Noch ist es nicht an der Zeit, in den MSIX-Rausch zu verfallen. Die Technologie ist – nach Ansicht des Autors – noch mehr Preview als kommerziell nutzbares Produkt. Wer sich für die Weiterentwicklung des Windows-Systems interessiert, sollte experimentieren; für den praktischen Einsatz ist es noch zu früh.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -