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...

Klicke hier, um den Artikel zu lesen

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 schrieb:

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

Zum Vergrößern anklicken....

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/wi...nd-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".