Windows 10: MSIX-Installationspakete unterstützen Programme mit Plugins

Windows 10: MSIX-Installationspakete unterstützen Programme mit Plugins

Das Installations-Paketformat MSIX soll der neue Rockstar unter Windows 10 werden. MSIX-Pakete bringen alle Vorteile, die bislang dem Microsoft Store vorbehalten waren, und darüber hinaus noch ein paar mehr. Per MSIX installierte Programme unterstützen automatische Updates, laufen in einer virtualisierten Umgebung und werden bei der Deinstallation rückstandslos aus dem System entfernt. Keine verwaisten Registry-Einträge, keine DLL-Leichen. Sowohl klassische Win32-Programme als auch Windows 10 Universal Apps können in ein MSIX-Paket gepackt und vertrieben werden – man kann sie zwar auch in den Store stellen, nötig ist das aber nicht (mehr).

Es besteht eine gewisse Ähnlichkeit mit der Desktop-Bridge, über die man Win32-Software in den Microsoft Store schicken kann. Jener Desktop Bridge fehlt allerdings eine wichtige Eigenschaft: Auf diese Weise installierte Programme unterstützen keine Plugins, die man nachträglich hinzufügen kann. Viele Programme setzen aber auf einen solch modularen Aufbau, wie Beispielsweise Paint.NET, der Bildbetrachter IrfanView, der Editor Notepad++ oder natürlich auch Microsoft Office, um nur ein paar Beispiele zu nennen.

Die gute Nachricht: Per MSIX gepackte Anwendungen haben dieses Problem nicht. Zwar laufen sie auch in einem Container mit einem virtualisierten Dateisystem, es gibt aber zwei definierte Methoden, wie diese Anwendungen dennoch Plugins unterstützen können. Microsoft hat diese in einem Blogpost beschrieben. Die erste Methode sind „Modification Packages“, die sozusagen in das virtuelle Dateisystem der Haupt-Applikation eindringen und sich im definierten Plugin-Verzeichnis platzieren. Diese Methode ist einfach, weil dafür der Code der Haupt-Applikation nicht angepasst werden muss, gleichzeitig müssen sich die Plugins aber genau an die Vorgaben halten, die der Entwickler festgelegt hat. Mit den „Optional Packages“ ist deutlich mehr möglich, weil sie die Haupt-Applikation wirklich verändern. Dementsprechend muss deren Code dafür aber auch angepasst werden.

Beispiele sind im oben verlinkten Blogpost beschrieben und verlinkt, auf GitHub findet man außerdem eine Beispiel-Anwendung nebst der entsprechenden Beispiel-Plugins.

Eine Einschränkung gibt es dann aber doch: Der Microsoft Store bleibt bei dieser Lösung außen vor. Die eigentliche Anwendung kann zwar als MSIX-Paket über den Store verteilt werden, die optionalen Plugin-Pakete allerdings nicht.

Quelle: Microsoft

Über den Autor
Martin Geuß
  • Martin Geuß auf Facebook
  • Martin Geuß auf Twitter
Ich bin Martin Geuß, und wie unschwer zu erkennen ist, fühle ich mich in der Windows-Welt zu Hause. Seit mehr als zwölf Jahren lasse ich die Welt an dem teilhaben, was mir zu Windows und anderen Microsoft-Produkten durch den Kopf geht, und manchmal ist das sogar interessant. Das wichtigste Motto meiner Arbeit lautet: Von mir - für Euch!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.



Kommentare
  1. Mit einer der Gründe für MSIX ist übrigens auch Intune, da können diese Pakete nativ verteilt werden. Interessant für das Modern Management Scenario.
    Die Formulierung finde ich etwas missverständlich. Eine Software die über MSIX installiert wurde ist nicht wirklich richtig virtualisiert. Ein paar Dinge wie _bestimmte_ Datei/ oder Registry-Zugriffe werden von Windows umgeleitet, aber alle Benutzerdateien auf links drehen kann eine Anwendung die über .msix installiert wurde auch ;-)
    Ok. Dann bitte den Artikel nächste Mal singend vortragen zu der Musik ?
    https://youtu.be/M7JVlpm0eRs
    Und hier die Hintergrundmusik für den Artikel:
    https://youtu.be/iC8oP4Z_xPw
    Entschuldigt, aber nach dem ersten Satz hatte ich gleich solche Gedanken, Martin ist schuld!
    ?
    Ich halte die Stimmung, die bei der Vorstellung dieser Installationspakete gemacht wird, ist jene, dass damit auf dem Microsoft Store verzichten werden könnte. Wenn ich z. B. in den Baumarkt gehe, dann nicht deswegen, nach welcher Betriebsanleitung das eine oder andere Produkt aufgebaut wird. Ich gehe in den Baumarkt, weil ich ein bestimmtes Produkt suche und ich dort vielfache Auswahl vorfinde. Es wäre schlimm, wenn ich zu den Herstellern direkt fahren müsste um ein Produkt zu kaufen.
    Will damit sagen, die neuen Installationspakete beheben nicht die Notwendigkeit eines Stores, wo man vielfache Auswahl bekommt. Wenn ich ein kleines produktives Programm suche, dann werde ich nicht einzelne Webseiten stundenweise abklappern. Wenn ein Entwickler diese Notwendigkeit nicht erkennt, dann hat er eben Pech gehabt.
    Ich kenne mich mit diesem ganzen technischen Dateienkram nicht aus.
    Für mich klingt das aber so als ob der Store in Zukunft noch überflüssiger werden könnte.
    Ich finde die Formulierung korrekt. Schließlich kann mit diesem Format keine Software im klassischen Sinn installiert werden. Und umgekehrt kann man an der Software auch nichts ändern wenn es der Entwickler nicht explizit vorgesehen hat.
    Warum die Erweiterungen nicht in den Store dürfen kann ich nur vermuten: Jeder kann sie erstellen und der Urheber des Hauptprogramms kann nichts dagegen tun. Erweiterungen können theoretisch böswillig sein...
    @skalar
    Im Zweifel vertraue ich einem Entwickler und seiner Webseite mehr als dubiosen Storeeinträgen.
    Optional packages gibt es auch für den Store, aber Microsoft erlaubt das leider nicht jedem (siehe https://docs.microsoft.com/en-us/windows/msix/package/optional-packages "To submit an app that uses optional packages and/or related sets to the Microsoft Store, you will need permission.")
    Möglich war das da bereits seit über 3 Jahren... nutzen darfs halt keiner.
    Gibt noch viel andere API im Store Umfeld die nur nach expliziter Freischaltung funktioniert (oder mal funktioniert hat - habe den Eindruck manches ist nie freigegebenen worden und wurde dann nicht weiter getestet obs überhaupt noch in aktuellen Windows-Builds funktioniert.)
    @ntoskernel Falsch vermutet, optional packages müssen vom selben Publisher kommen wie die eigentliche App. Also kann nicht "jeder" etwas dem Hauptprogramm unterschieben.
    Gehe eher davon aus, dass das Thema einfach keine Priorität mehr hatte und wegen Aufwänden im Zustand "Zugang nur nach Freischaltung" verharrt. Wahrscheinlich wären insbesondere einige Änderungen am Entwicklerportal dazu notwendig, damit die Zertifizierung von solchen Zusatz-Paketen funktioniert, uvm.
    Lange Rede kurzer Sinn: Technisch kein Problem, schon lange für den Store erfunden (mit tollen Features wie separates Lizenzieren über InApp-Käufe - auch hier hätte man wohl die Store Oberfläche noch anpacken müssen), aber die Aufwände sind halt unverhältnismäßig hoch...
    Und bitte nicht falsch verstehen (wollen), das muss nicht mal bedeuten, dass Microsoft MSIX viel cooler findet und den Store neuerdings hasst (auch wenn ich selbst bei Twitter schon das Hashtag #storeshaming verwendet habe:angel). Aber Themen wie Lizenzierung, Zertifizierung uvm. stellen sich dort halt gar nicht. So musste man quasi "nur" den Installer etwas pimpen, damit er das beherrscht was sowieso schon rudimentär im System vorhanden war.
    Dachte immer, das ginge auch so schon über den Ordner "Program Files\ModifiableWindowsApps"? Den hat Windows mit irgendeinem früheren Update, entweder 1809 oder 1903 auf jeder Partition angelegt. Im Unterschied zum normalen WindowsApps Folder hat man auf diesen standardmäßig volle Zugriffsrechte. Dachte immer das wäre genau für sowas. Oder ist das nur ein Platzhalter für eben dieses Feature was nun kommt?
    DonRolando

    @ntoskernel Falsch vermutet, optional packages müssen vom selben Publisher kommen wie die eigentliche App. Also kann nicht "jeder" etwas dem Hauptprogramm unterschieben.

    Das war sogar meine erste Vermutung, daß MS so einen Blödsinn* einbaut. Im verlinkten Artikel ist davon aber an keiner Stelle die Rede. Daher habe ich dahingehend keine Einschränkungen angenommen.
    *Warum das zumindest in manchen Fällen Blödsinn ist:
    1) Der Hersteller selbst bietet Erweiterungen zu seiner Software an. Klassischer Fall, den es auch schon immer im Store/UWP gibt, ist DLC für Spiele. Da ist das verständlich, der Hersteller will nur seine eigenen Erweiterungen haben.
    2) Der Hersteller baut eine Schnittstelle für Dritthersteller bewußt ein. Oder noch universeller, die Schnittstelle wird von mehreren Programmen unterstützt (z.B. Photoshop Plugins, NPAPI). Dann weiß der Entwickler des Plugins u.U. gar nicht mit welcher Software sein Plugin verwendet wird. Dieser Fall läßt sich mit den UWP Mechanismen sowieso nicht abbilden. Aber auch für den spezielleren Fall will man es nicht immer, daß der Entwickler des Hauptprogramms alles signieren muß: Es ist Zusatzaufwand für den Entwickler, es verlangsamt den Releaseprozess, ein Bugfix kann nicht auf die Schnelle veröffentlicht werden und der Entwickler will dort vielleicht gar nicht seine Signatur auf fremdem Code sehen, da dies dann im Falle von Fehlern etc. auf ihn zurückgeführt wird.
    @ntoskrnl: Die Einschränkung mit dem selben Publisher galt zumindest für den Store. Eventuell gilt das nicht für MSIX und wird daher nicht im Blogpost erwähnt.
    Und ich würde "optionale Pakete" nicht mit Extensions in einen Topf schmeißen.
    Hier gibts eine nette Übersicht der verschiedenen Erweiterungs-Mechanismen:
    https://docs.microsoft.com/en-us/windows/uwp/launch-resume/extend-your-app-with-services-extensions-packages
    Und auch Microsoft schreibt "The key differentiator between optional packages and app extensions are open ecosystem versus closed ecosystem, and dependent package versus independent package."
    Dein erster Punkt mit den DLCs wird wahrscheinlich tatsächlich als optional package gelöst (und die großen Publisher dürfen im Unterschied zu den "kleinen" Entwicklern das Feature wohl auch im Store nutzen), der zweite Punkt wäre hingegen eine "app extension".
Nach oben