By Andreas Nick on Freitag, 08. Februar 2019
Category: App-V

MSIX Tutorial: Ein umfassender Leitfaden mit 24 Kapiteln

Wir haben von Bogdan Mitrache von Advancedinstaller.com die Erlaubnis bekommen, seinen Artikel zu MSIX auf unserer Webseite in Deutsch zu veröffentlichen. Besonders interessant finde ich es, wie sich MSIX auf Sicht eines Herstellers für Softwarepaketierungsprodukte darstellt.
Hier der Original Artikel von Bogdan:
https://www.advancedinstaller.com/msix-introduction.html

Ich selber lese gerade zu neuen technischen Themen gerne etwas in meiner Muttersprache. Daher möchte ich Bogdan sehr dafür danken, diese Übersetzung zu ermöglichen.

MSIX Tutorial: Ein umfassender Leitfaden mit 24 Kapiteln

Von Bogdan Mitrache (Übersetzung und Kommentare von Andreas Nick)

Bogdan ist der Produktmanager für Advanced Installer. Er verfügt über mehr als ein Jahrzehnt Erfahrung in der Anwendungspaketierung und -bereitstellung, er spricht oft auf Konferenzen und trägt zu branchenspezifischen Themen bei. Entdecken Sie das neue MSIX-Paketformat und den neuen Container. Erhalten Sie eine schnelle Einführung in 5.000 Wörter, die Sie mit der neuesten Paketierungs- und Bereitstellungstechnologie von Windows 10 auf den neuesten Stand bringt. Abonnieren Sie, um zukünftige Updates mit einer erweiterten Version für alle folgenden Kapitel zu erhalten.

MSIX Tutorial - von Advanced Installer

1. Was ist MSIX?

MSIX wurde 2018 auf den Windows Developers Days angekündigt und ist ein neues universelles Paketformat für Windows 10-Anwendungen. Desktop-, Mobil- und alle anderen Windows 10-Geräte werden unterstützt.
Microsoft präsentierte uns MSIX als eine verbesserte Version des AppX-Pakets (ursprünglich nur für UWP-Anwendungen verwendet), um traditionelle Desktop-Anwendungen unter Windows 10 besser zu unterstützen, indem sie das Wissen, das sie von MSI- und App-V-Paketen und dem Desktop Bridge-Programm haben, mitbringt.
Ein MSIX-Paket ist sehr ähnlich wie ein AppX- oder App-V-Paket, strukturell gesehen. Es ist im Grunde genommen ein Zip-Paket, das Anwendungsdateien und einige XML-Konfigurationsdateien enthält. In diesem Blogbeitrag spricht Microsoft über die frühen Anfänge dieses Paketformats, d.h. den AppX, seinen Vorfahren.
Der Hauptunterschied, den MSIX brachte, ist die erweiterte Unterstützung für Win32-Anwendungen, d.h. die Standard-Desktop-Anwendungen, die wir seit all diesen Jahren verwenden. So können Sie Ihre normale Desktop-Anwendung verpacken und im Microsoft Store veröffentlichen oder sie einfach zum Download von Ihrer Website anbieten und dabei alle neuen Vorteile der modernen Windows-APIs nutzen.
Eine Desktop-Anwendung als MSIX-Paket hat einige Einschränkungen, die von Microsoft hinzugefügt werden, um die Sicherheit zu gewährleisten, die das neue Modell uns verspricht. Überprüfen Sie den oben verlinkten, um sicherzustellen, dass Ihre Anwendung für die Migration auf MSIX geeignet ist.

2. MSIX Container

Der MSIX-Container vereint die Unterstützung von Desktop Bridge-Anwendungen mit den einen UWP-Anwendungen, wie unten dargestellt.


Natürlich laufen klassische Win32-Anwendungen, die als MSIX verpackt sind, immer noch nur auf Desktop-Geräten, daher werden diese Anwendungen nicht "universell", nur weil wir sie jetzt in ein neues Format packen.
Alle diese konvertierten Apps sind immer noch x86 und x64 Bit Apps, so dass sie nicht auf Tablets/Handys oder anderen Geräten ausgeführt werden können. Es gibt eine Ausnahme, die Always-Connected-PC-Geräte, die Windows 10 im S-Modus ausführen, wo Win32-Anwendungen auf ARM-Geräten mit einer im Betriebssystem enthaltenen Emulationsunterstützung und spezifischen ARM-CPUs ausgeführt werden.

Genauso wie vollständige UWP-Anwendungen können die von Win32 konvertierten Anwendungen (und als MSIX verpackt) auf die UWP-APIs zugreifen. Von einer Win32-Anwendung aus können Sie jedoch nur auf die Desktop-APIs zugreifen, während Sie von einer vollständigen UWP-Anwendung aus die Möglichkeit haben, je nach Zielvorrichtung auf verschiedene APIs (Mobile, Xbox, HoloLens, etc....) zuzugreifen.
Das bedeutet, dass Sie mit der Modernisierung Ihrer Win32-Anwendung mit den neuen Windows 10-APIs beginnen können und sogar die gesamte Anwendung in den UWP migrieren können. In diesem Fall können Sie alle Vorteile eines vollen UWP-Containers nutzen.
Das Veröffentlichen von Win32-konvertierten Anwendungen im Microsoft Store ist möglich, jedoch nur für die Ausrichtung auf die oben genannten Geräte.

3. Systemressourcen & mehr

Der MSIX-Container wird den Zugriff auf die neuen Windows 10-Funktionen wie verbesserte Sicherheit und Zugriff auf neue UWP-APIs ermöglichen, aber gleichzeitig auch einige Einschränkungen mit sich bringen.
Eine vollständige Liste der Empfehlungen und Einschränkungen von Microsoft finden Sie im folgenden Artikel, um eine App (Desktop Bridge) zu verpacken.
Nachfolgend finden Sie ein Diagramm mit den unterstützten Betriebssystem-Ressourcen (einer Win32-Anwendung), die ein MSIX-Paket installieren kann. Darüber hinaus können Sie Ihre Anwendung natürlich auch migrieren und erweitern, um die neuen UWP-Komponenten (App-Services, Hintergrundaufgabe, etc....) zu nutzen, um sie besser in das Betriebssystem oder andere Anwendungen zu integrieren.

Wenn Sie nach Treibern suchen, werden diese in MSIX-Paketen nicht unterstützt. Microsoft empfiehlt, dass alle Treiber von den Hardwareanbietern in den Microsoft Store hochgeladen werden, damit das Betriebssystem ihre Installation automatisch für den Endbenutzer verwaltet. Da sich MSIX noch in der Entwicklung befindet, können wir mit Änderungen rechnen, aber bis dahin können Sie immer noch die Hybrid-Lösung von App-V nutzen, bei der die Treiber oft als MSI-Paket integriert wurden.

4. Erstellung von MSIX-Paketen

Es gibt mehrere Tools, die Ihnen bei der Erstellung und Wartung Ihrer MSIX-Pakete helfen können. Eine vollständige Liste der Tools finden Sie in der Microsoft-Dokumentation.
Natürlich kann Advanced InstallerInstaller MSIX-Pakete erstellen, von Grund auf oder durch Konvertierung Ihres alten Installers in ein neues Projekt, das Sie pflegen können. Sehen Sie sich das Video unten an, um zu sehen, wie einfach Sie MSIX- und MSI-Pakete aus einem einzigen Projekt erstellen können, die sowohl alte Windows 7-Benutzer als auch die aktuellen Windows 10-Benutzer problemlos bedienen.

Microsoft stellt ein eigenes Tool zur Verfügung, um alte Installer, das MSIX Packaging Tool, zu konvertieren, ohne ein Projekt zu generieren. Visual Studio erstellt derzeit AppX-Pakete, so dass wir höchstwahrscheinlich in einem zukünftigen Update auch die Unterstützung für MSIX-Pakete sehen werden.
Das manuelle Erstellen des Pakets ist auch mit dem Befehlszeilenprogramm MakeAppx.exe möglich.

5. Migrieren und Erweitern

Die Umstellung Ihres Installationsprogramms ist nur die erste Phase (wenn Ihre Software noch gepflegt/aktualisiert wird). Jetzt können Sie mit der Erweiterung Ihrer App um die neuen UWP-APIs beginnen und sie Schritt für Schritt migrieren.

Das AppConsult Team von Microsoft hat einige ausgezeichnete Tutorials geschrieben, die zeigen, wie Sie die neuen APIs nutzen und mit der Modernisierung Ihrer Anwendung beginnen können.

Wir alle wissen, dass es immer noch viele Clients gibt, die unter Windows 7 laufen (auch wenn diese Zahl jeden Tag sinkt), deshalb zeigt das letzte oben verlinkte Tutorial, wie Sie erkennen können, ob Ihre Anwendung im alten Desktop-App-Modus oder im neuen modernen App-Container läuft. Auf diese Weise können Sie Ihre App immer noch modernisieren und gleichzeitig Ihre Windows 7-Clients unterstützen.

Neben der Konvertierung alter EXE/MSI-Installer nach MSIX können Sie auch AppX- und App-V-Pakete in das MSIX-Format konvertieren. Dies kann mit dem Advanced Installer oder mit dem MSIX Packaging Tool erfolgen. Die Konvertierung solcher Pakete kann automatisiert werden, da diese Pakete im Gegensatz zu den MSI/EXE-Installateuren keinen benutzerdefinierten Code enthalten, der während der Installation/Publikation ausgeführt werden kann (die App-V-Deployment-Konfiguration ist Gegenstand eines weiteren Vortrags), so dass der gesamte Konvertierungsprozess praktisch in zwei einfache Schritte unterteilt ist:

  1. Extrahieren von App-V- oder AppX-Paketinhalten
  2. Verpacken Sie das Neue MSIX unter Verwendung des extrahierten (und "übersetzten") Inhalts aus dem Originalpaket.

Die Übersetzungsphase ist der Teil, in dem das neue Paketmanifest aus den alten Manifesten in App-V- und AppX-Paketen generiert/übersetzt wird.

6. Installationsort

Alle MSIX-Pakete werden vom Betriebssystem im folgenden Ordner installiert bzw. extrahiert:

%ProgramFiles%\WindowsApps

Dies ist ein Systemordner, der standardmäßig nicht über den Windows Explorer zugänglich ist. Es gibt Methoden, um diesen zu machen, aber das ist nicht das Thema dieses Artikels.
In diesem Ordner finden Sie Unterordner für jede auf dem Computer installierte Anwendung, einschließlich der im Betriebssystem integrierten Anwendungen. Alle Ordner haben ihren Namen nach diesem Muster:

PublisherName.AppName_AppVersion_architecture_hash

Hier ist ein Beispiel für einen Ordnernamen:

Microsoft.WindowsCalculator_10.1806.1821.0_x64_8wekyb3d8bbwe

Im Ordner befindet sich das extrahierte MSIX-Paket, so wie Sie es sehen würden, wenn Sie die Datei mit 7-Zip oder anderen ähnlichen Tools extrahieren würden.
Nur das Betriebssystem kann bei der Installation Ihrer App an diesem Ort schreiben. Wenn Ihre Anwendung Protokolldateien oder andere Daten in den Installationsordner schreibt, stürzt sie ab.
Sie müssen entweder Ihren Code aktualisieren, um in %AppData% zu schreiben. Wenn Sie keinen Zugriff auf den Code haben, kann das Problem das Package Support Framework  von Microsoft beheben.
7. Deinstallation
Wenn Sie ein MSI-Paket deinstallieren bleiben meistens die Anwendungsdateien unter AppData und die Registrierungseinträge, die die App während ihrer Lebensdauer erstellt hat, auf dem Computer und belasten das System mit "Müll".
MSIX-Pakete hingegen vereinfachen den Installations- und Deinstallationsprozess, indem sie die Unordnung der Maschine reduzieren.

Aufgrund des containerisierten Modells entfernt die Deinstallation eines MSIX-Pakets auch alle Dateien, die die App während der Ausführung (im Ordner AppData) erstellt hat, einschließlich aller unter %ProgramFiles%WindowsApps installierten App-Dateien, aus dem System.
Das Gleiche geschieht mit den von der App erstellten Registrierungen. Dies hilft, einen sauberen Maschinenzustand viel einfacher zu halten und somit die bekannte Windows Rot (alias Registry Rot) zu vermeiden.
Beachten Sie, dass, wenn die App auch Dateien an einem anderen, nicht standardisierten (nicht empfohlenen) Speicherort auf dem Computer erstellt, diese Dateien bei der Deinstallation nicht gelöscht werden.

8. Dateiumleitungen

Apps, die über MSIX-Pakete installiert wurden, laufen in einer Sandbox-Umgebung (d.h. dem Container), was bedeutet, dass das Betriebssystem die meisten Dateien und Registrierungsvorgänge umleitet.
Wenn es um den Dateizugriff geht, beginnt die Umleitung automatisch, wenn Sie versuchen, auf Dateien aus den Ordnern VFS (Virtual File System) und AppData Ihres Pakets zuzugreifen.
Der Zugriff auf Ressourcen aus Ihrem VFS-Ordner kann für viele Anwendungen Probleme verursachen, ist aber mit Hilfe der Reflection-APIs , wie im verlinkten Beispiel, sehr einfach zu beheben.
Im gleichen Artikel wird auch erklärt, wie Sie auf den AppData-Ordner der App zugreifen können. Windows ordnet den bekannten Pfad C:\Users\<username>\AppData\Roaming\ automatisch in einen Pfad um, der so aussieht:

AppData\Local\Packages\<AppName>.AppData_<GUID>\LocalCache\Roaming\

Die Handhabung des AppData Ordners aus dem alten Code funktioniert standardmäßig (auch unter Windows 7), die Ordnerumstrukturierung ist transparent, solange Sie die empfohlenen Windows-APIs verwenden, um den Ordnerpfad AppData abzurufen. (hartkodierte Pfade sind schlecht und werden Ihre App zum Absturz bringen).
Der obige Ordner, in dem das Betriebssystem Ihre Anwendung umleitet, ist vor allem zu Debugging-Zwecken gut zu kennen.
Empfohlene API-Aufrufe zum Abrufen der Ordnerpfade von AppData:


//local app data
string localPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);

//roaming app data
string roamingPath = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

9. Umleitungen der Registry

Alle Registrierungsvorgänge werden in spezielle Registrierungs-Hives pro App umgeleitet. Ihr Paket kann die folgenden Hives enthalten, die in separaten Dateien sichtbar sind, wenn Sie den Inhalt extrahieren:

Alle HKLM-Einträge werden unter Registry.dat gespeichert, während die Registrierungseinträge pro Benutzer in die entsprechenden Hives gehen.
Alle diese Hives werden zur Laufzeit praktisch mit der Registrierung auf dem Betriebssystem zusammengeführt, so dass die App die gesamte Registrierung als eine einzige Einheit "sehen" kann.
Die HKLM-Registrierung ist in den meisten Fällen schreibgeschützt, während Schreiboperationen auf die Benutzer-Hives an einen Ort pro Anwendung umgeleitet werden, genau wie bei AppData-Dateien.
Dies ermöglicht es dem System, alle von der App während ihrer Lebensdauer verwendeten/erstellten Registrierungsdaten einfach zu löschen, nach der Deinstallation, und die bekannte Registry-Vermüllung zu vermeiden, die Windows-Maschinen jahrzehntelang verlangsamt.

10. Digitale Signatur

Alle MSIX-Pakete müssen digital signiert sein, keine Ausnahme. Sicherheitsverletzungen betreffen ganze Unternehmen, und Microsoft hat beschlossen, bei der Bekämpfung dieser Angriffe zu helfen, indem es die digitale Signatur für alle MSIX-Pakete durchsetzt, unabhängig davon, ob die Pakete aus dem Microsoft Store installiert werden oder intern in Ihrem Unternehmen bereitgestellt werden.
Es gibt zwei Möglichkeiten, ein Paket zu signieren:

Für firmeninterne Anwendungen können Sie sogar ein selbst generiertes Zertifikat verwenden, aber stellen Sie sicher, dass das Zertifikat auch auf den Rechnern installiert ist, auf denen Sie Ihren MSIX einsetzen möchten, da diese sonst das Zertifikat nicht erkennen. Das Zertifikat finden Sie im Zertifikatsspeicher "Local Machine -> Trusted Root Certification Authorities".
Um ein Paket zu signieren, benötigen Sie das Windows SDK. Im SDK befindet sich SignTool.exe, das Befehlszeilenprogramm, das Microsoft für die digitale Signatur empfiehlt.
Die meisten Paketierungstools integrieren SignTool automatisch, so dass die Aktivierung der digitalen Signatur nur eine einfache Einstellung in der GUI ist.
Wichtig: Der SHA256-Hash-Algorithmus ist zwingend erforderlich, um MSIX-Pakete digital zu signieren, SHA1 wird vom Betriebssystem nicht als gültig angesehen.

11. Layout des Paketinhalts

 Das obige Bild zeigt das gängigste und minimalste MSIX-Paketlayout  . Sie können diese Ressourcen sehen, wenn Sie das Paket mit makeappx.exe oder Tools wie 7-zip entpacken.

12. AppxManifest.xml

Diese XML-Datei ist das Paketmanifest, das in jedem Paket vorhanden sein muss. Sie enthält die Informationen, die die Anwendung und ihre Funktionen definieren. Alle diese Informationen werden vom System verwendet, um das Verhalten der App während ihrer Lebensdauer zu installieren/deinstallieren, zu aktualisieren und zu kontrollieren.
Diese Datei wird normalerweise automatisch vom Tool generiert, das das MSIX-Paket erstellt, sei es Visual Studio, Advanced Installer oder andere Tools. Sie können es auch manuell erstellen, aber es wird nicht empfohlen. Diese Datei befindet sich im Installationsordner Ihrer App und ist schreibgeschützt.
Der Inhalt der Datei muss den vom Betriebssystem vorgegebenen Schemata entsprechen, wie im obigen Link dokumentiert. Die Schemata können zwischen den verschiedenen großen Windows 10-Updates variieren, daher ist es sehr wichtig zu wissen, welche Betriebssystemversionen Sie mit Ihrer App anstreben, da Sie sonst möglicherweise Funktionen verwenden, die nicht für alle Ihre Benutzer verfügbar sind.

13. Package Support Framework (auch bekannt als PSF)

Das Package Support Framework (PSF) ist die Lösung von Microsoft für Kunden, die Kompatibilitätsprobleme für alte Desktop-Anwendungen lösen müssen und keinen Zugriff auf den Quellcode der Anwendung haben.
Das PSF bietet Unterstützung für API-Umleitung und Hooking. So können Sie eine Anwendung reparieren, die beispielsweise eine Datei in den Installationsordner schreibt (dies ist nicht mehr erlaubt) und sie an einen empfohlenen Speicherort umzuleiten, oder vielleicht einfach das Arbeitsverzeichnis der Anwendung aktualisieren.
Die Funktionsweise ist ziemlich einfach. Microsoft bietet einen App Launcher, eine Runtime Manager DLL, einige Laufzeitkorrekturen und eine config.json Datei. Du kannst auch deine eigenen Fixes nach deren Dokumentation  erstellen.
Der Launcher (ausführbar) wird zur Hauptanwendung in Ihrem Paket und lädt die Runtime Manager DLL und die Fixes. Beim Start startet diese ausführbare Datei automatisch Ihre App, lädt aber auch die Laufzeit-DLL und die Fixes in Ihre App, die in der Datei config.json angegeben wurden.
Wenn die App versucht, auf eine Ressource zuzugreifen die nicht mehr verfügbar ist, z.B. in ihren Installationsordner zu schreiben, treten die Laufzeitkorrekturen ein und leiten den Aufruf an einen neuen Ort z.B. unter AppData um.

14. Änderungspakete

In der Praxis ist dieser Pakettyp das Äquivalent zu einer MS -Datei (MSI-Transformationen) einer klassischen Installation. Ein Modifikationspaket ist jedoch nicht direkt an eine bestimmte Version Ihrer Hauptanwendung gebunden, d.h. Sie können die Hauptanwendung aktualisieren und trotzdem das alte Modifikationspaket verwenden.
Es wird IT-Experten in den Unternehmen ermöglichen, die MSIX-Pakete, die sie von ISVs erhalten oder die sie von älteren Installern generiert wurden anzupassen und für die Massenbereitstellung vorzubereiten. All dies mit Tools wie Advanced Installer oder MSIX Packaging Tool.
Ein Modifikationspaket hat die gleiche Dateiendung wie ein MSIX-Paket, aber mit leicht unterschiedlichem Inhalt, wobei die wesentlichen Unterschiede in der Datei AppXManifest.xml zu finden sind. Außerdem muss es die gleiche Signatur (CN) wie das Zielpaket haben, sonst kann es nicht installiert werden.
Ein Änderungspaket kann keine App-Einträge in seinem Manifest definieren, es kann nur neue Binärdateien zum Haupt-/Zielpaket hinzufügen, sowie neue Registrierungseinträge.
Modifikationspakete sind nicht direkt in "Apps und Features" aufgeführt, aberman kann die Einstellungen finden, wenn man auf den Link "Erweiterte Optionen" für die Zielanwendung klicken.

15. Store Publishing

Um eine App im Microsoft Store zu veröffentlichenzu veröffentlichen, müssen Sie sich für ein Entwicklerkonto bei Microsoft, als Einzelperson oder als Firmenkonto registrieren.
Der nächste Schritt ist die Reservierung Ihres App-Namens. Zu diesem Zeitpunkt wird Microsoft prüfen, ob der von Ihnen gewünschte Name verfügbar ist, andernfalls werden Sie aufgefordert, einen anderen Namen anzugeben.
Sobald Ihre App fertig ist, können Sie diese an den Shop senden. Bevor Sie eine App einreichen, empfehlen wir Ihnen, das Windows App Compatibility Kit (WACK)  zu verwenden, um sicherzustellen, dass Ihre Anwendung den Anforderungen von Microsoft entspricht. Wenn Ihre App alle Prüfungen besteht, ist sie bereit für den Shop.
Wenn Sie den Advanced Installer verwenden, ist diese Validierung mit einem Klick erledigt, gehen Sie einfach zu File -> Settings -> Package Validation" und aktivieren Sie WACK-Validierungen.


16. Sideloading

MSIX-Pakete können aus dem Microsoft Store oder durch direktes Starten des Pakets (Sideloading, d.h. manuelle oder skriptbasierte Installation), d.h. manuelle oder skriptbasierte Installation) auf dem Computer installiert werden.
Es gibt zwei wesentliche Bedingungen, die erfüllt sein müssen, damit ein Paket erfolgreich „seitwärts“ geladen werden kann:

  1. Sideloading muss auf der Maschine, über eine Unternehmensrichtlinie oder über die Anwendung Einstellungen aktiviert werden.
  2. Das MSIX-Paket muss mit einem von der Maschine anerkannten Zertifikat digital signiert sein. Wie im Abschnitt Digitale Signaturen erwähnt, kann das Code-Signing-Zertifikat selbst erstellt oder von einem autorisierten Emittenten erworben werden.

Sobald diese Bedingungen erfüllt sind, können Sie das MSIX-Paket installieren. Sie können dies entweder durch Doppelklicken auf die MSIX-Datei oder mit dem PowerShell-Cmdlet Add-AppxPackage tun.
Diese Funktion bedeutet, dass Softwareanbieter nicht gezwungen sind, ihre Anwendungen über den Microsoft Store zu verteilen. Wenn sie es wünschen, können sie das MSIX-Paket direkt zum Download auf ihrer Website veröffentlichen und die Benutzer können es manuell herunterladen und installieren, wie oben erläutert.
Die Unterstützung für automatische Updates durch das System für moderne Apps funktioniert auch bei sideloaded Apps, wenn die Softwareanbieter ein Update-Paket auf ihren Servern veröffentlichen. Lesen Sie den Abschnitt Auto-Updates für weitere Details.

17. Automatische Updates

Die Bereitstellung von Updates ist eine gewaltige und zeitaufwändige Aufgabe, die von den meisten Entwicklern nicht geliebt, aber notwendig ist.
Mit MSIX-Paketen wird diese Aufgabe drastisch vereinfacht. Wenn Sie sich dafür entscheiden, Ihre App im Shop zu veröffentlichen, können Sie einfach aufhören, sich um Updates von Anwendungen zu sorgen, da sich das Betriebssystem darum kümmert.
Bei Sideloaded Allications können Sie das aktualisierte Paket zusammen mit einer AppInstaller-Datei  auf Ihrer Website veröffentlichen. (unten finden Sie den Inhalt einer Beispiel-Applikationsdatei).

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://uwpupdate.azurewebsites.net/DesktopBridge.Package.appinstaller" Version="1.0.0.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2">
    <MainBundle Name="c6c08364-cbe5-4267-ae81-ce9be33ff652" Version="1.0.0.0" Publisher="CN=mpagani" Uri="https://uwpupdate.azurewebsites.net/DesktopBridge.Package_1.0.0.0_Test/DesktopBridge.Package_1.0.0.0_x86_x64.appxbundle" />
    <UpdateSettings>
       <OnLaunch HoursBetweenUpdateChecks="0" />
    </UpdateSettings>
</AppInstaller>

 In Ihrer Hauptanwendung müssen Sie lediglich die URL oder den UNC-Pfad der Dateifreigabe angeben, auf der Sie Ihre. Appinstaller-Datei und Ihr Paket bereitstellen möchten. Dies kann in der Regel in der GUI der Anwendung angegeben werden, mit der Sie das MSIX-Paket erstellen. Das können Sie es mit Advanced Installer oder dem Visual Studio .

Wenn Sie noch komplexere Szenarien für die Überprüfung und das Herunterladen von Anwendungsaktualisierungen haben, müssen Sie möglicherweise ein Auto-Update-Tool https://www.advancedinstaller.com/auto-updater.html neben Ihrer App einbinden.

18. App Installer (GUI)

Das AppX-Paket, der Vorgänger von MSIX, konnte das Paket nicht immer mit einem einfachen Doppelklick installieren. Die einzige Möglichkeit, eine App manuell auf dem Computer zu installieren/sideload zu laden, war mit Hilfe des PowerShell-Cmdlets Add-AppXPackage (Link).
Wie Sie im folgenden Microsoft-Artikel sehen können, wurde eine einfache GUI eingeführt, um die Installation von MSIX-Paketen zu vereinfachen.
Im Gegensatz zu den alten MSI-Paketen ist diese GUI nicht direkt im Paket anpassbar, d.h. Sie können Ihren Kunden keinen benutzerdefinierten Installationsdialog anzeigen oder während der Installation Benutzereingaben anfordern. Microsoft empfiehlt, dass die App-Konfiguration beim ersten Start durch die Benutzer erfolgt, wie in unserem nächsten Kapitel, First Launch Configurations, beschrieben.

19. Konfigurationen für den ersten Start

Mit der Einführung von AppX-Paketen in Windows 8, hat Microsoft neue Richtlinien für die Anwendungskonfiguration veröffentlicht. Für alle Apps, die über ein AppX/MSIX-Paket installiert werden findet die Benutzerkonfigurationen beim ersten Start der App durch den Benutzer statt. Dies bedeutet, dass die Installationsoberfläche nicht mehr angepasst werden kann, um Benutzereingaben zu sammeln und eigenen Code auszuführen, um die App vor dem ersten Start vorzubereiten.

Microsoft empfiehlt, dies alles aus Ihrer App heraus zu tun und die Installationsphase von der anfänglichen Konfiguration der App zu entkoppeln.
Für die Unternehmensbereitstellung, bei der die Endbenutzer in der Regel erwarteten, dass ihre Apps vorkonfiguriert und einsatzbereit sind, können die IT-Abteilungen mit Hilfe von Änderungspaketen neben der App die erforderlichen zusätzlichen Konfigurationen (z.B. eine Lizenzdatei, etc.) einbinden.
20. Lokalisierung
Das Ressourcenmanagementsystem ein System, welches dem Benutzer beim Aufbau des Package Resource Index (PRI-Dateien) hilft. Die PRI-Datei ist nur eine Tabelle mit benannten Ressourcen und Verweisen auf die Ressourcendatei innerhalb des App-Pakets und es gibt eine PRI-Datei pro Sprache, die in jedem MSIX-Paket enthalten ist.
Advanced Installer oder Visual Studio, je nachdem, was Sie verwenden, erstellt diese Datei automatisch, basierend auf Ihrer Projektkonfiguration.
Sie können die PRI-Dateien auch manuell  erstellen, in diesem Fall müssen Sie auch mehr über die Namenskonventionen von Microsoft für Ressourcen lesen .
Bei der Installation lädt das System automatisch nur die Ressourcen herunter, die es je nach Gebietsschema des Benutzers benötigt, und nicht das gesamte MSIX-Paket (das auch die Ressourcen für alle anderen unterstützten Sprachen enthält).
Für einen detaillierteren Überblick über die lokalisierten Ressourcen in einem Paket lesen Sie diesen MSDN-Artikel.


Bildquelle: MSDN Blogs 

21. App Capabilities App

Mit modernen Apps müssen für alle Betriebssystem-Ressourcen (Benutzerbilder, Internetverbindung oder Geräte wie Kamera oder Mikrofon), auf die Sie zugreifen möchten, Berechtigungen aus dem Paketmanifest angefordert werden. Das sind die so genannten App Capabilities.
Wenn Sie diese nicht in Ihrem Paket deklarieren, werden die entsprechenden System-APIs nicht geladen und Ihre App funktioniert nicht wie erwartet.
Sie können die Funktionen Ihrer App ganz einfach in der GUI des Advanced Installers definieren, indem Sie sie aus der vordefinierten Liste oder dem entsprechenden Element in Ihrem Visual Studio-Projekt auswählen.
Die Definition von Anwendungsfunktionen ist nur für vollständige UWP-Anwendungen oder UWP-Komponenten aus Ihrer Anwendung erforderlich, z.B. eine Hintergrundaufgabe oder ein App-Service. Jeder alte (Win32-)Code läuft auch ohne die im Paket deklarierten Funktionen weiterhin korrekt, da er keine modernen APIs für den Zugriff auf diese Ressourcen verwendet wird.

22. Debuggen innerhalb des MSIX-Containers

Das Debuggen Ihres Codes in einem MSIX-Container unterscheidet sich geringfügig von dem Standard-Debugging in Visual Studio.
Wenn Sie Ihre Desktop-Anwendung normalerweise in Visual Studio debuggen, läuft die Anwendung nicht in einem Container, sondern startet Visual Studio einfach die Hauptausführdatei Ihrer Anwendung als einfache Datei von der Festplatte, ohne sich der Einschränkungen eines MSIX-Containers bewusst zu sein oder auf die neuen modernen APIs zugreifen zu können, die über den MSIX-Container zugänglich sind.
Dieser gesamte Zugriff ist praktisch abhängig von der Datei AppXManifest.xml und der Vervielfältigung des VFS-Ordners. Beim Debuggen einer MSIX-kompatiblen Anwendung mit Visual Studio wird das MSIX-Paket von Visual Studio entweder mit der „Advanced Installer Extension“ oder mit der integrierten Unterstützung (build in Support)  die Anwendung auf dem Computer installiert. Dazu wird das Paket einem temporären Speicherort extrahiert. Sobald die App vom Debugger gestartet wird, hängt sich Visual Studio an den Prozess an und Sie können die App untersuchen. So erfolgt das debuggen, genau wie in der Vergangenheit.

23. Pro Benutzerverteilung

Standardmäßig werden auf dem Computer installierte Anwendungen pro Benutzer registriert  , auch wenn sie alle Apps im Ordner %ProgramFiles%\WindowsApps installiert sind. Das kann dazu führen, dass Sie vielleicht fälschlicherweise denken, dass die Anwendung für alle Benutzer auf dem Computer sichtbar ist, wie dies bei Win32-Anwendungen der Fall war.
Jeder Benutzer sieht unter seinem Konto nur die Anwendungen, die auf seine Anmeldeinformationen registriert sind. Wenn also ein anderer Benutzer eine neue Anwendung auf dem Computer installiert hat, wird diese Anwendung für alle anderen Benutzer ausgeblendet.

Wenn zwei oder mehr Benutzer die gleiche App-Version auf dem Computer installieren, wird die Anwendung nicht zweimal heruntergeladen oder installiert. Stattdessen wird dieselbe Quelle verwendet, um die App beiden Benutzern zur Verfügung zu stellen, indem die App mit ihren jeweiligen Konten registriert wird. Auf diese Weise reduziert das Betriebssystem den Festplattennutzung und die Bandbreitenauslastung bei der Aktualisierung der App.
Die Bereitstellung pro Computer kann durch die Bereitstellung Ihres Pakets vor der Erstellung der Benutzerkonten, auf einem Betriebssystem von einem lokalen Computer oder auf einem gemounteten Windows Image erfolgen. Dies kann mit dem Cmdlet Add-AppxProvisionedPackage für .appx- und.msix-Pakete durchgeführt werden. Erfahren Sie mehr über die Bereitstellung pro Computer.

24. Windows 10 S-Mode

Im Windows 10 S-Modus  funktioniert das Betriebssystem ausschließlich mit Anwendungen aus dem Microsoft Store.
Das im S-Modus ausgelieferte System kann gegen eine einmalige Gebühr von 49 US-Dollar auf die Professional Edition aufgerüstet werden und somit für die Installation von Anwendungen aus allen Quellen, einschließlich der Verwendung der alten Installer (EXE, MSI, etc....), freigeschaltet werden. Dies ist eine „One-way“ Funktion. Der Wechsel zurück in den S-Modus ist nach dem Upgrade nicht mehr möglich.
Geräte, die mit dem Windows 10 S-Modus ausgeliefert werden, scheinen Microsofts Antwort auf Googles Chromebook zu sein, das im Education Umfeld sehr beliebt ist. Also erschwingliche Maschinen, die am Ende eine vollwertige Version von Windows 10 ausführen können. Also Systeme mit einigen Verbesserungen (um diese besser auf niedrigen Spezifikationen laufen zu lassen) und den entsprechenden Einschränkungen, die diese Verbesserungen nach einem Upgrade beseitigen.
MSIX-Pakete, die mit Visual Studio, dem MSIX Packaging Tool oder dem Advanced Installer erstellt wurden, können problemlos auf diesen Maschinen installiert werden, sofern Sie sie im Microsoft Store veröffentlichen.
Dies ist nicht dasselbe wie die Windows RT-Version, die Microsoft mit Windows 8 gestartet hat. Diese Geräte verwendeten ARM-Prozessoren und waren daher nicht in der Lage, x86 kompilierte Anwendungen auszuführen. Aktuelle Geräte, die mit dem Windows 10 S-Modus ausgeliefert werden, verfügen über x86-basierte CPUs.
Es gibt eine Ausnahme, die neue Reihe von Geräten Always-Connected-PC, die weiterhin auf ARM laufen werden. Diese neue Generation von ARM kann jedoch die x86-Befehle emulieren, so dass Ihre Desktop-Anwendungen weiterhin mit einigen Einschränkungen laufen.

Related Posts

Leave Comments