15. Aug 2022
Lesedauer 14 Min.
Sauber getrennte Pakete
MSIX-Anwendungseinstellungen, Teil 2
MSIX verringert die Fehleranfälligkeit und bietet zukunftsweisende Ansätze.
Es ist ein altes Problem, das wohl jeder Softwareentwickler kennt: Während auf dem Entwicklungsrechner alles problemlos funktionierte, kommt es auf dem Produktivsystem, auf dem die neue Anwendung installiert wird, zu massiven Problemen. Fehlende Ressourcen, Instabilitäten, Seiteneffekte mit anderen Anwendungen und komplexe Nutzereinstellungen torpedieren die Ausführung.Glücklicherweise gibt es heute Technologien, die diese Probleme in den Griff bekommen, sodass solche Erfahrungen der Vergangenheit angehören sollten. Dazu gehört Microsofts MSIX-Technologie, welche die dotnetpro in einem zweiteiligen Artikel genauer erläutert. Der erste Teil ist in der August-Ausgabe erschienen [1]. Was nun noch fehlt, klärt der vorliegende zweite Teil: das Zuweisen von Argumenten und das Verknüpfen von Anwendungspaketen.
Zuweisen von Argumenten
Bei der bereits im ersten Teil verwendeten Beispielanwendung MSIX Media Player handelt es sich um eine Windows-Forms-Anwendung, die über Aufrufparameter gesteuert werden kann. Listing 1 zeigt, wie beim Programmstart zunächst geprüft wird, ob es eine Konfigurationsdatei gibt. Falls nicht, erfolgt ein Upgrade und die Einstellungen der Vorversion werden übernommen. Die Variable FirstRun steuert dabei den automatisierten Aufruf des Konfigurationsdialogs, sodass er nur beim ersten Start erscheint. Hierzu wird die Variable nach der Konfiguration auf false gesetzt.Listing 1: Steuerung der Anwendungskonfiguration
[STAThread] <br/>static void Main(<span class="hljs-built_in">string</span>[] <span class="hljs-built_in">args</span>) <br/>{ <br/> // Prüfen auf erforderliches Upgrade der<br/> // Konfigurationsdatei <br/> <span class="hljs-keyword">if</span> (!ConfigurationManager.OpenExeConfiguration(<br/> ConfigurationUserLevel.PerUserRoamingAndLocal).<br/> HasFile) <br/> Properties.Settings.Default.Upgrade(); <br/><br/> // Standard ist True: Sofern kein Upgrade stattfand,<br/> // wird der Einstellungsdialog aufgerufen <br/> bool showSettingsDialog =<br/> Properties.Settings.Default.FirstRun; <br/> bool resetSettings = <span class="hljs-literal">false</span>; <br/><br/> // Argumente auswerten: Übergabe von -config ist<br/> // höherwertig <span class="hljs-literal">und</span> zeigt den Konfiguraionsdialog <br/> // unabhängig von den bisherigen Einstellungen an. <br/> foreach (<span class="hljs-built_in">string</span> arg <span class="hljs-keyword">in</span> <span class="hljs-built_in">args</span>) <br/> { <br/> <span class="hljs-keyword">if</span> (arg.Equals(<span class="hljs-string">"-config"</span>)) <br/> showSettingsDialog = <span class="hljs-literal">true</span>; <br/> <span class="hljs-keyword">else</span> <span class="hljs-keyword">if</span> (arg.Equals(<span class="hljs-string">"-safe"</span>)) <br/> Program.IsSafeMode = <span class="hljs-literal">true</span>; <br/> <span class="hljs-keyword">else</span> <span class="hljs-keyword">if</span> (arg.Equals(<span class="hljs-string">"-reset"</span>)) <br/> resetSettings = <span class="hljs-literal">true</span>; <br/> } <br/><br/> <span class="hljs-keyword">if</span> (resetSettings) <br/> Program.ResetSettings(); <br/><br/> <span class="hljs-keyword">if</span> (showSettingsDialog) <br/> Program.ShowConfigForm(<span class="hljs-literal">true</span>); <br/> <span class="hljs-keyword">else</span> <br/> Application.Run(<span class="hljs-built_in">new</span> MainForm()); <br/><br/>}
Zur unabhängigen Steuerung kann zudem das Argument -config übergeben werden, sodass der Konfigurationsdialog auch ohne Abhängigkeit von der Variablen FirstRun aufgerufen wird. Die zusätzlichen Argumente -safe und -reset ermöglichen weitere Anwendungssteuerungen.Die Anwendung selbst ist in einer MSIX-Datei verpackt, sodass sie über die Kachel gestartet werden kann. Hierbei kommt zunächst nur der Konfigurationsautomatismus zum Tragen, da die Verwendung von Argumenten bei MSIX ein Umdenkens erfordert.MSIX-Pakete werden unterhalb des geschützten Verzeichnisses %ProgramFiles%\WindowsApps installiert. Somit finden sich in %ProgramFiles%\WindowsApps\MSIXMediaPlayerApp_1.0.55.0_x64__p1z 46hfsarpje\MSIXMedia die Binärdateien der Anwendung. Sofern der Nutzer Zugriff auf den Ordner hat, kann sie als Win32-Anwendung gestartet werden:
Process.Start(
@"C:<span class="hljs-symbol">\P</span>rogram Files<span class="hljs-symbol">\W</span>indowsApps<span class="hljs-symbol">\</span>
<span class="hljs-symbol"> </span> MSIXMediaPlayerApp_1.0.55.0_
x64__p1z46hfsarpje<span class="hljs-symbol">\M</span>SIXMedia<span class="hljs-symbol">\</span>
<span class="hljs-symbol"> </span> MSIXMedia.exe");
Falls die Anwendung keine Funktionalitäten der Windows-Runtime nutzt oder diese bei nativer Ausführung ignoriert, sollte sie wie erwartet funktionieren. Da sie im Win32-Modus ausgeführt wird, lassen sich wie gewohnt Befehlszeilenargumente übergeben. Allerdings ist das nicht zielführend und hat mit der MSIX-Technologie nichts zu tun. Die Nutzung des Anwendungscontainers steht hierbei im Fokus, wofür ein Aufruf von CreateProcess() mit Angabe der EXE-Datei nicht ausreicht. Hierfür müssen die Kernkomponenten verwendet werden, die auch in der Manifestdatei zu finden sind, siehe Listing 2:
Listing 2: Paket und Anwendungsidentität
<span class="hljs-tag">&lt;<span class="hljs-name">Package</span> <span class="hljs-attr">...</span> &gt;</span> <br/> <span class="hljs-tag">&lt;<span class="hljs-name">Identity</span> </span><br/><span class="hljs-tag"> <span class="hljs-attr">Name</span>=<span class="hljs-string">"MSIXMediaPlayerApp"</span> <span class="hljs-attr">Publisher</span>=<span class="hljs-string">"CN=MSIX"</span> </span><br/><span class="hljs-tag"> <span class="hljs-attr">Version</span>=<span class="hljs-string">"1.0.55.0"</span> <span class="hljs-attr">ProcessorArchitecture</span>=<span class="hljs-string">"x64"</span>/&gt;</span> <br/> <span class="hljs-tag">&lt;<span class="hljs-name">Applications</span>&gt;</span> <br/> <span class="hljs-tag">&lt;<span class="hljs-name">Application</span> <span class="hljs-attr">Id</span>=<span class="hljs-string">"App1"</span></span><br/><span class="hljs-tag"> <span class="hljs-attr">Executable</span>=<span class="hljs-string">"MSIXMedia.exe"</span> <span class="hljs-attr">...</span> /&gt;</span> <br/> <span class="hljs-tag">&lt;<span class="hljs-name">Application</span> <span class="hljs-attr">Id</span>=<span class="hljs-string">"App2"</span> <span class="hljs-attr">Executable</span>=<span class="hljs-string">"Helper.exe"</span> </span><br/><span class="hljs-tag"> <span class="hljs-attr">...</span> /&gt;</span> <br/> <span class="hljs-tag">&lt;/<span class="hljs-name">Applications</span>&gt;</span> <br/><span class="hljs-tag">&lt;/<span class="hljs-name">Package</span>&gt;</span> - <Package>: Definiert die Umgebung, in welcher der gesamte Code ausgeführt wird, und beschreibt somit die Struktur und die Funktionen der Software auf dem System. Entscheidend für die Paketausführung ist die Angabe von PackageFamilyName, der sich wie in Bild 1 gezeigt aus dem Paketnamen und einem Hashwert des Publishers zusammensetzt, wobei die Werte durch einen Unterstrich voneinander getrennt sind; siehe hierzu auch den ersten Teil dieser Serie [1].
Die Bestandteileeiner MSIX-Paketidentität(Bild 1)
Autor
- <Application>: Eine oder mehrere Anwendungen, die über eine Kachel gestartet werden. Erforderlich ist hierzu die Definition der Anwendungs-ID (Id). Dies ist ein ASCII-String mit einer Länge zwischen 1 und 64 Zeichen. Diese ID fungiert als eindeutiges Identifizierungsmerkmal der Anwendung innerhalb des Pakets. Die Identifizierung ist nötig, da es in einem Paket mehrere Anwendungen geben kann.
PS C:\> (Get-AppxPackage -Name
"msixmediaplayerapp").
PackageFamilyName
PS C:\> (Get-AppxPackage -Name
"msixmediaplayerapp" |
Get-AppxPackageManifest).
package.applications.
application.id
Es geht aber auch über die Windows-Nutzeroberfläche. Im Dialog Ausführen oder in der Adresszeile des Windows-Explorers ist hierzu der Befehl shell:appsFolder einzugeben. Daraufhin öffnet sich ein Explorer-Fenster, das alle installierten Anwendungen auflistet. Nun ist lediglich eine Verknüpfung zu der benötigten Anwendung auf dem Desktop zu erstellen. Obwohl hiermit ein Anwendungspaket referenziert wurde, verfügt die Verknüpfung über das Standardkontextmenü, in dem die in Bild 2 dargestellten Paketeigenschaften angezeigt werden.
Der Eigenschaftendialogeiner Verknüpfung zu einem Anwendungspaket(Bild 2)
Autor
Entscheidend ist hier das Ziel der Verknüpfung. Hier finden sich die Bezeichnung PackageFamiliyName und die Anwendungs-ID, die durch ein Ausrufzeichen voneinander getrennt sind. Leider können die Werte nicht editiert werden, sodass sich der Verknüpfung keine Argumente anfügen lassen.Da nun die Identifizierungsmerkmale und somit die Aufrufsyntax bekannt sind, ist der parametrisierte Anwendungsaufruf über Konsole oder PowerShell möglich:
PS C:\> start-process shell:appsfolder\MSIXMediaPlayerApp
_p1z46hfsarpje!App -ArgumentList -config
C:\> start shell:appsfolder\MSIXMediaPlayerApp_
p1z46hfsarpje!App -config
Der Aufruf ist durch die kryptische Zielangabe nicht gerade intuitiv zu verwenden. Effektiver und einfacher wäre es, einen Alias zu nutzen. In den Windows-Einstellungen sind unter Apps | Apps und Features | Aliase für die App-Ausführung alle konfigurierten Aliase aufgeführt. Sofern es bereits einen Alias für die benötigte Anwendung gibt, umso besser. Falls nicht, muss das Anwendungspaket durch Modifikation der Datei AppxManifest.xml erweitert werden, wie es in Listing 3 geschieht. Erkennbar ist zunächst die Anwendung, die durch die Zeichenfolge App identifiziert wird und auf die Datei MSIXMedia
.exe verweist. Darunter finden sich die Erweiterungen. Zur Nutzung eines Alias wurde die Extension <uap3:AppExecutionAlias /> hinzugefügt und der Alias msix-media.exe zugeordnet.
.exe verweist. Darunter finden sich die Erweiterungen. Zur Nutzung eines Alias wurde die Extension <uap3:AppExecutionAlias /> hinzugefügt und der Alias msix-media.exe zugeordnet.
Listing 3: Definition von Alias und Parameter
&lt;Application Id="App"<br/> Executable="MSIXMedia\MSIXMedia.exe"<br/> EntryPoint="Windows.FullTrustApplication"<br/> uap10:Parameters="-safe"&gt; <br/> &lt;Extensions&gt; <br/> &lt;uap3:Extension<br/> Category="windows.appExecutionAlias"<br/> EntryPoint="Windows.FullTrustApplication"<br/> Executable="MSIXMedia\MSIXMedia.exe"&gt; <br/> &lt;uap3:AppExecutionAlias&gt; <br/> &lt;desktop:ExecutionAlias<br/> Alias="msix-media.exe"/&gt; <br/> &lt;/uap3:AppExecutionAlias&gt; <br/> &lt;/uap3:Extension&gt; <br/> &lt;/Extensions&gt; <br/>&lt;/Application&gt;
Fortan lässt sich das Anwendungspaket über den Alias starten, wobei Argumente verwendet werden können. Angaben zu dem Alias lassen sich über die Windows-Einstellungen, aber auch mit entsprechenden Tools wie MSIX Hero [2] herausfinden. Bild 3 zeigt, dass die Beispielanwendung sowohl über eine Startmenükachel als auch über den Alias aufgerufen werden kann. Der Aufruf über die Konsole oder die Windows PowerShell ist natürlich ebenfalls möglich:
Die AufrufoptionenderBeispielanwendung(Bild 3)
Autor
PS C:\> Start-Process msix-media.exe -ArgumentList
-config
C:\> msix-media.exe -config
Einen Überblick über alle Aliase auf dem System kann man sich mit dem Windows-Explorer oder der Konsole auf Dateiebene verschaffen, da Windows alle Aliase unter %LocalAppData%\Microsoft\WindowsApps speichert. An diesem Ort wird für jede Anwendung, die über einen Alias verfügt, ein Unterordner angelegt. Als Ordnername wird der Wert von PackageFamilyName verwendet. In dem jeweiligen Ordner befindet sich für jede mit einem Alias versehene Anwendung des Pakets eine EXE-Datei, die eine spezielle Form von IO_REPARSE_TAG_APPEXECLINK [3] verwendet, um auf das eigentliche Anwendungspaket zu verweisen. Die EXE-Datei trägt den Namen des Alias.Sofern die Verwendung des Alias für die jeweilige Anwendung in den Windows-Einstellungen unter Apps | Apps und Features | Aliase für die App-Ausführung aktiviert wurde, wird die EXE-Datei zusätzlich in den Windows-Apps-Ordner kopiert und der Aufruf ist fortan über den Alias möglich. Falls der Aufruf fehlschlagen sollte, ist die Ursache häufig in den Umgebungsvariablen des Nutzers zu finden. Zur fehlerfreien Verwendung muss der Windows-Apps-Ordner in die PATH-Variable aufgenommen sein.Mit der PowerShell ist es ebenfalls möglich, die Aliase zu betrachten und zu verwalten. Hierzu muss jedoch das PowerShell-Modul NtObjectManager [4] installiert werden. Danach stehen die Funktionen Get-ExecutionAlias und Set-ExecutionAlias für diese Zwecke zur Verfügung. Einen tieferen Einblick in die Alias-Nutzung sowie die Verwendung des Moduls gibt das Blog „Tyranid’s Lair“ [5].Der parametrisierte Aufruf des Anwendungspakets kann innerhalb der Datei AppxManifest.xml definiert werden. Hierzu sind dem Attribut uap10:Parameters die benötigten Argumente zuzuordnen, wie es Listing 3 zeigt. Die Umsetzung ist einfach, offenbart aber einige Probleme:
- Die zugeordneten Argumente werden bei jedem Anwendungsstart über die Kachel verwendet.
- Bei der Verwendung des Befehls shell:appsfolder\MSIXMediaPlayerApp_p1z46hfsarpje!App -config wird das Argument -config der Parameters-Auflistung des Manifests hinzugefügt. Das gilt auch bei Parametern mit Wertzuweisung. Wurde im Manifest Test=1 definiert und über die Konsole Test=2 zugewiesen, werden beide Wertepaare an die Anwendung übertragen.
- Bei der Verwendung des Alias werden die im Manifest definierten Parameter nicht berücksichtigt.
Listing 4: App mit verschiedenen Parametern starten
&lt;Package...&gt; <br/> &lt;Applications&gt; <br/> &lt;Application Id="App1"<br/> Executable="MSIXMedia.exe"<br/> uap10:Parameters="-config" ...&gt; <br/> &lt;uap:VisualElements<br/> DisplayName="MSIX Media Player Config" ... /&gt; <br/> &lt;/Application&gt; <br/> &lt;Application Id="App2"<br/> Executable="MSIXMedia.exe" ...&gt; <br/> &lt;uap:VisualElements<br/> DisplayName="MSIX Media Player" /&gt; <br/> &lt;/Application&gt; <br/> &lt;/Applications&gt; <br/>&lt;/Package&gt;
Sofern die Anwendung mit dem Microsoft DesktopApp-Installer bereitgestellt wird, findet sich auf der Nutzeroberfläche eine Option zum automatischen Starten der Anwendung nach Fertigstellung der Installation, wie es in Bild 4 zu sehen ist. Sofern ein Paket mehrere Anwendungen enthält, wird immer die gestartet, die in der Applications-Auflistung an erster Stelle steht. Von daher scheint es ideal, die Anwendung mit dem Konfigurationsaufruf dort zu platzieren.
Die Nutzeroberflächeeiner MSIX-Installation(Bild 4)
Autor
Deaktivierung des ms-appinstaller-Protokolls
Grundsätzlich besteht auch die Möglichkeit, Installationsparameter über einen Download- oder Installations-URI zu übergeben [6]. Hierzu wird das Protokoll ms-appinstaller verwendet, das letztlich den Microsoft DesktopApp-Installer aufruft. Aus Sicherheitsgründen hat Microsoft die Nutzung dieses Protokolls deaktiviert. Zum Zeitpunkt, als dieser Artikels entstand, war nicht abzusehen, ob und wann die Nutzung wieder möglich ist.Flexible Virtualisierung
Klassische Win32-Anwendungen können Ordner und Dateien an vielen Stellen des Dateisystem erstellen, ändern oder löschen, sofern die erforderlichen Berechtigungen vorliegen. Gleiches gilt für Eintragungen in der Systemregistrierung. Charakteristisch ist hierbei die identische Sicht aller Anwendungen auf die Ressourcen. Änderungen können von allen Anwendungen ausgeführt werden, sodass Inkonsistenzen und sich daraus ergebende Seiteneffekte zwischen den Anwendungen nahezu unvermeidbar scheinen. Bei der Deinstallation der Anwendung bleiben die Ressourcen auf dem System, obwohl sie oft nicht mehr benötigt werden.Wie bereits erläutert, hat Microsoft dieses Verhalten im MSIX-Umfeld gravierend gerändert. Dateien, Ordner und Registrierungseinträge werden in einem privaten Bereich virtualisiert, sodass sie sich nur von derjenigen Anwendung wahrnehmen und ändern lassen, die sie auch erstellt hat. Bei der Deinstallation werden auch diese Elemente entfernt, sodass keine unnötigen Ressourcen auf dem System verbleiben.Sofern ausschließlich paketierte Anwendungen betrachtet werden, ist diese Lösung ideal. Die Vorsteile sind:- rückstandsfreie Deinstallation,
- keine Beeinträchtigung anderer Anwendungen.
<rescap:Capability Name="unvirtualizedResources"/>
Darüber hinaus kann der Schreibzugriff durch die Eigenschaften RegistryWriteVirtualization und FileSystemWriteVirtualization des Namensraums uap6 konfiguriert werden. Sofern die Eigenschaften auf Disabled gesetzt wurden, werden die Schreibzugriffe auf HKCU und/oder den AppData-Ordner nicht virtualisiert und erfolgen somit im nativen Speicherbereich. Hierdurch sind die Modifikationen auch für Prozesse außerhalb des Pakets sichtbar. Bei der Deinstallation erfolgt keine Bereinigung des Speicherbereichs. Der Standardwert beider Eigenschaften ist Enabled.Was auf den ersten Blick spannend anmutet, offenbart bei genauerer Betrachtung zwei große Schwachpunkte:
- Der Mechanismus schaltet die Dateisystem- und HKCU-Virtualisierung aus, was dem eigentlichen Grundgedanken der Paketisolierung widerspricht.
- Die Installation per DesktopApp-Installer wird nicht unterstützt, da das Paket die eingeschränkte Funktion unvirtualizedResources verwendet; die Installation ist somit nur per PowerShell möglich.
- Es können nur Orte im Dateisystem verwendet werden, die sich innerhalb von %USERPROFILE%\AppData befinden.
- Es können nur Speicherorte der Systemregistrierung deklariert werden, die in HKCU enthalten sind.
Listing 5: Flexible Virtualisierung bei MSIX-Paketen
&lt;Package ...&gt; <br/> &lt;Properties&gt; <br/> &lt;uap6:FileSystemWriteVirtualization&gt;disabled<br/> &lt;/uap6:FileSystemWriteVirtualization&gt; <br/> &lt;uap6:RegistryWriteVirtualization&gt;enabled<br/> &lt;/uap6:RegistryWriteVirtualization&gt; <br/> &lt;!--Neu seit Windows Version 21H1--&gt; <br/> &lt;virtualization:FileSystemWriteVirtualization&gt; <br/> &lt;virtualization:ExcludedDirectories&gt; <br/> &lt;virtualization:ExcludedDirectory&gt;<br/> $(KnownFolder:LocalAppData)\MSIXMedia<br/> &lt;/virtualization:ExcludedDirectory&gt; <br/> &lt;/virtualization:ExcludedDirectories&gt; <br/> &lt;/virtualization:FileSystemWriteVirtualization&gt; <br/> &lt;/Properties&gt; <br/> &lt;Capabilities&gt; <br/> &lt;rescap:Capability Name="runFullTrust" /&gt; <br/> &lt;!--Seit Windows Version 1903--&gt; <br/> &lt;rescap:Capability<br/> Name="unvirtualizedResources" /&gt; <br/> &lt;/Capabilities&gt;<br/>&lt;/Package&gt;
Es ist möglich, in einem Paket beide Deklarationsvarianten zu verwenden. In einem solchen Fall wird die alte Funktionalität für Versionen vor Windows 10 21H1 genutzt, während die neue Option bei Windows 10 21H1 und später zum Einsatz kommt.
Ressourcen außerhalb des App-Verzeichnisses
Im MSIX-Universum werden üblicherweise alle Ressourcen in einem isolierten Bereich abgelegt, sodass nur die jeweilige Anwendung darauf zugreifen kann. Ausnahmen davon sind durch die Deaktivierung der Virtualisierung für die Nutzerbereiche möglich. Seit Windows 11 besteht zudem die Möglichkeit, das Anwendungsverzeichnis an einem beliebigen Speicherort zu platzieren, sodass der Zugriff auch von anderen Anwendungen möglich ist.Beide Verfahren haben gewisse Unwägbarkeiten. So bleiben bei der ersten Option nach der Deinstallation die nicht virtualisierten Ressourcen auf dem System, während bei der zweiten Variante eine Provisionierung [7] zur systemweiten Bereitstellung des Pakets erforderlich ist. Die Notwendigkeit der zweiten Option ergibt sich daraus, dass der Paketordner %ProgramFiles%\WindowsApps geschützt ist und nur bestimmte Windows-Dienste darauf zugreifen können. Durch die Wahl eines alternativen Speicherorts wird hingegen eine Ordnerstruktur geschaffen, auf die jeder Administrator schreibend zugreifen kann. Da dieser Speicherort logisch mit dem Paket verbunden ist, kann die jeweilige Anwendung diesen wie gewohnt nutzen.Die Deklaration eines solchen alternativen Speicherorts erfolgt über das Element <MutablePackageDirectory/>, das in zwei Namensräumen zu finden ist:- <Desktop6:MutablePackageDirectory>: Das Verzeichnis wird unterhalb von %ProgramFiles%\ModifiableWindowsApps angelegt.
- <Desktop8:MutablePackageDirectory>: Ein beliebiges Verzeichnis außerhalb des WindowsApps-Ordners kann als Ziel bestimmt werden, sofern Windows 11 verwendet wird.
Mehrere Anwendungspakete verknüpfen
Der Shared Package Container erweitert die vorgestellten Möglichkeiten zur gemeinsamen Ressourcennutzung erheblich. Hierbei handelt es sich um einen Laufzeitcontainer, der voneinander unabhängigen MSIX-Anwendungen eine gemeinsame Sicht auf das virtuelle Dateisystem und die virtuelle Systemregistrierung ermöglicht.Beim Beispiel des Media Players sind es die Anwendungspakete MSIXMedia, MSIXCalc und MSIXPackager. Jedes dieser Pakete verfügt über ein virtuelles Dateisystem mit zwei relevanten Ordnern. Ein Ordner ist mit dem Anwendungsnamen bezeichnet und enthält die Datei help.txt. Der andere Ordner ist mit MSIXOffice bezeichnet und enthält zwei Bilddateien mit dem jeweiligen Anwendungssymbol. Eine Bilddatei trägt den Anwendungsnamen, die andere ist mit logo.png bezeichnet.Nach der Installation agiert jedes Anwendungspaket zunächst autark. Das bedeutet, dass jede Anwendung nur den eigenen virtuellen Speicherbereich sehen und auf ihn zugreifen kann. Der Shared Package Container ändert das, wie auch Bild 5 zeigt. Jede Anwendung kann die Inhalte der individuell benannten und somit isolierten Ordner sehen und die help.txt-Dateien aller Anwendungspakete nutzen. Darüber ist der Zugriff auf den Ordner MSIXOffice möglich, der eine verbundene Sicht auf die gemeinsamen Ressourcen bietet.
Gemeinsame Sichtunabhängiger Anwendungen(Bild 5)
Autor
Die Bereitstellung eines Shared Package Containers kann unabhängig vom Softwarebereitstellungsprozess der Anwendung erfolgen. So kann der Container auf dem System bereits vor der Installation der Anwendungen registriert werden. Bei der Anwendungsinstallation erkennt das System den registrierten Container und fügt die Anwendungen hinzu. Der umgekehrte Weg ist ebenfalls möglich: Wird der Container nach den Anwendungen registriert, werden sie diesem automatisch zugewiesen.Die Aktualisierung der Anwendungen kann wie bisher erfolgen und obliegt keinerlei Einschränkungen durch die Containernutzung. Interessant ist auch das Verhalten bei Modifikationspaketen. Hierbei handelt es sich um Ergänzungen, die sich in den Anwendungscontainer des Hauptpakets virtuell einklinken. Für den Einsatz in einem Shared Package Container sind daher keine weiteren Vorkehrungen zu treffen.Sofern das Hauptpaket in den Container aufgenommen wurde, werden die Inhalte der Modifikationspakete ebenfalls zu der verbundenen Sicht hinzugefügt.Die gesamte Nutzung der Container ist sehr einfach gehalten. Dennoch gilt es einige Faktoren zu berücksichtigen:
- Ein Shared Package Container wird in der Regel von IT-Professionals verwendet, da für die Verwaltung administrative Rechte erforderlich sind.
- Die Registrierung erfolgt ausschließlich per PowerShell und setzt mindestens Windows 10 Insider Preview Build 21354 voraus.
- Jedes Anwendungspaket kann nur in einen Shared Package Container aufgenommen werden. Der Versuch, ein bereits registriertes Paket auch in einen anderen Container aufzunehmen, führt zu einem Fehler.
<?xml version="1.0" encoding="utf-8"?>
<AppSharedPackageContainer Name="MSIXOfficeContainer">
<PackageFamily
Name="MSIXMediaPlayerApp_p1z46hfsarpje"/>
<PackageFamily Name="MSIXPackagerApp_p1z46hfsarpje"/>
<PackageFamily Name="MSIXCalulatorApp_p1z46hfsarpje"/>
</AppSharedPackageContainer>
Die eigentliche Bereitstellung des Shared Package Containers erfolgt mit dem Befehl Add-AppSharedPackageContainer in einer administrativen PowerShell-Konsole; ihm ist der Pfad zur XML-Datei anzufügen. Falls bereits ein Container mit identischem Namen auf dem System existiert, wird dieser überschrieben.Darüber hinaus empfiehlt es sich, das Argument -ForceApplicationShutDown zu verwenden. Ohne dieses Argument würde der Befehl zu einem Fehler führen, sofern derzeit eine referenzierte Anwendung verwendet wird.
PS C:\> Add-AppSharedPackageContainer
"C:\MSIXOfficeContainer.xml" -ForceApplicationShutdown
Bei erfolgreicher Ausführung werden die eindeutige ID und der Name des Containers ausgegeben. Der Befehl Get-AppSharedPackageContainer stellt diese Informationen ebenfalls bereit, fügt aber auch die involvierten Pakete der Ausgabe mit an:
PS C:\> Get-AppSharedPackageContainer
Id : 11446959-11db-4394-992b-
53b59039b2e0
Name : MSIXOfficeContainer
PackageFamilyNames : MSIXCalulatorApp_p1z46hfsarpje
MSIXMediaPlayerApp_p1z46hfsarpje
MSIXPackagerApp_p1z46hfsarpje
Id : ad96a240-1251-4d16-b621-
4ca9d6f64802
Name : MSIXOfficeContainer5
PackageFamilyNames : MSIXNotepadApp_p1z46hfsarpje
Alle weiteren PowerShell-Befehle zur Verwaltung der Shared Package Container sind in Tabelle 1 zusammengefasst.
Tabelle 1: Verwaltung von Shared Package Containern
|
Shared Package Container ermöglichen eine gemeinsame Sicht auf das virtuelle Dateisystem und die virtuelle Registrierung aller inkludierten Anwendungspakete. Obwohl die Vorgehensweisen und Darstellungen einleuchtend und intuitiv erscheinen, gilt es noch die anfängliche Frage zu klären, welches Logo eigentlich gewinnt.Jedes der Beispielpakete enthält im virtuellen Dateisystem den Ordner MSIXOffice, in den jedes Paket seine eigene Logodatei unter dem Namen logo.png ablegt. Durch die gemeinsame Sicht der verlinkten Pakete auf diesen Ordner kann aber nur eine Logodatei gewinnen. In diesem Beispiel ist es das Logo der MSIXMedia-App, wie Bild 6 zeigt, da sich die Paketverlinkung an oberster Stelle der Containerdefinition befindet.
Der Ordnerinhalteiner verbundenen Ansicht(Bild 6)
Autor
Fazit
Mit diesem zweiten Artikel zur MSIX-Technologie findet das umfangreiche Thema vorerst seinen Abschluss. Während im Windows-Installer-Umfeld nahezu alle Konfigurationen innerhalb der Installationsphase erfolgten, führen die neuen Richtlinien zur Anwendungskonfiguration zu einer sauberen Trennung zwischen Installation und Konfiguration. Die Nutzeroberfläche für die Installation von MSIX-Paketen wurde dadurch vereinfacht, ist übersichtlicher und auf das Wesentliche beschränkt.Die Konfiguration wird in der Anwendung vorgenommen, wodurch die Fehleranfälligkeit während der Installationsphase deutlich gesenkt wird. Zahlreiche Implementierungen und Möglichkeiten unterstützen bei der effektiven Umsetzung dieses Paradigmas und bieten neue, zukunftsweisende Lösungsansätze bei der Bereitstellung von Anwendungen nicht nur in Migrations- und Transitionsszenarien.Fussnoten
- Andreas Kerl, Komplexe Setups fest im Griff, MSIX-Anwendungseinstellungen – Teil 1, dotnetpro 8/2022, Seite 62 ff., http://www.dotnetpro.de/A2208MSIX
- MSIX Hero, https://msixhero.net
- Reparse Tags, http://www.dotnetpro.de/SL2209MSIX1
- NtObjectManager, http://www.dotnetpro.de/SL2209MSIX2
- Overview of Windows Execution Aliases, http://www.dotnetpro.de/SL2209MSIX3
- Passing installation parameters to your app via App Installer, http://www.dotnetpro.de/SL2209MSIX4
- Andreas Kerl, Unter der Haube von MSIX, MSIX-Pakete verwalten, dotnetpro 7/2020, Seite 26 ff., http://www.dotnetpro.de/A2007MSIX
