MSIX-Frameworkpakete und dynamische Abhängigkeiten

  • Artikel

In diesem Artikel werden wichtige Konzepte im Zusammenhang mit MSIX-Frameworkpaketen beschrieben. Die Informationen in diesem Artikel bieten einen nützlichen Kontext, der Ihnen hilft, Design und Zweck des Features der dynamischen Abhängigkeiten im Windows-App SDK und im Windows 11 Betriebssystem besser zu verstehen. Mit diesem Feature können Ihre Apps zur Laufzeit auf MSIX-Frameworkpakete verweisen und diese verwenden.

Frameworkpakete und das Paketdiagramm

MSIX ist ein Paketformat, das eine moderne Paket- und Bereitstellungserfahrung bietet. Außerdem stellt es eine saubere und vertrauenswürdige Möglichkeit bereit, verteilbare Bibliotheken, Inhalte und Komponenten über MSIX-Frameworkpakete zu packen. Ein MSIX-Frameworkpaket ermöglicht es gepackten Apps, über eine einzelne freigegebene Quelle auf dem Gerät der Benutzer*innen auf Komponenten zuzugreifen, anstatt sie in das App-Paket zu bündeln. Zu den gängigen Frameworkpaketen gehören das Windows App SDK (einschließlich WinUI3), WinUI2, VCLibs und die DirectX-Runtime.

Von Windows 8 bis Windows 10 und Windows 11 verfügt jeder Prozess über ein Paketdiagramm, das eine Liste aller für die App verfügbaren Pakete enthält, darunter Framework-, Ressourcen-, optionale und Hauptpakete. Dieses Diagramm ermöglicht der App das Laden von DLLs, Inhalten und Laufzeitklassendeklarationen, die von einem Paket bereitgestellt werden, auf das verwiesen wird. In der Vergangenheit wurde dieses Diagramm zum Zeitpunkt der Prozesserstellung festgeschrieben, und es gab keine Möglichkeit, es zur Laufzeit zu ändern:

  • Für gepackte Apps wurde das Diagramm basierend auf den im PackageDependency-Element im Paketmanifest der App deklarierten Paketabhängigkeiten initialisiert. Beim Erstellen einer gepackten App wurde dies in der Regel während des Buildprozesses basierend auf Ihren Projektverweisen und -abhängigkeiten für Sie durchgeführt.
  • Für nicht gepackte Apps war das Diagramm leer und konnte nicht geändert werden. Daher waren nicht gepackte Apps auf die Standard-DLL-Suchreihenfolge beschränkt und konnten nicht auf Frameworkpakete zugreifen.

Diese Einschränkung durch das statische Paketdiagramm wird durch die Einführung der Unterstützung dynamischer Abhängigkeiten sowohl im Windows-App SDK als auch in Windows 11 aufgehoben. Entwickler können dynamische Abhängigkeiten verwenden, um aus ihren Apps zur Laufzeit auf MSIX-Frameworkpakete zu verweisen und diese zu verwenden. Dynamische Abhängigkeiten heben die Einschränkung des statischen Paketdiagramms für Apps auf, und Entwickler können entscheiden, wie sie Frameworkpakete nutzen möchten.

Primäre Szenarien für dynamische Abhängigkeiten

Durch dynamische Abhängigkeiten kann zwar jede App eine Paketframeworkabhängigkeit zur Laufzeit hinzufügen, dieses Feature ist aber in erster Linie für die Verwendung durch gepackte Apps mit externem Speicherort oder nicht gepackte Apps vorgesehen. Gepackte Apps können in ihrem Paketmanifest über das PackageDependency-Element weiterhin statische Abhängigkeiten hinzufügen.

Wartungsmodell für Frameworkpakete

Das Feature der dynamischen Abhängigkeiten behält die Integrität der Wartungspipeline für das Frameworkpaket bei, das zur Laufzeit referenziert und dynamisch verwendet wird.

MSIX-Frameworkpakete unterstützen die Wartung in einem parallelen Modell, d. h., jede Version wird in einem eigenen separaten Ordner mit Versionsunterstützung installiert. Dadurch können Anwendungen, die verwendet werden, auch dann in Betrieb bleiben, wenn eine neuere App eine neuere Version des Frameworkpakets installiert. Das Betriebssystem verfügt über eine Deinstallationslogik, um zu bestimmen, wann ältere Versionen eines bestimmten Frameworkpakets gelöscht werden sollen, je nachdem, ob Verweise zur Installationszeit und Verweise zur Laufzeit für das Paket vorliegen.

  • Wenn eine App installiert wird, kann sie einen Installationszeitverweis auf ein Frameworkpaket erstellen. Dieser Verweis informiert das Betriebssystem darüber, dass die App von dem angegebenen Frameworkpaket abhängig ist, sodass das Betriebssystem das Frameworkpaket nicht deinstalliert, solange die App installiert ist.
  • Wenn eine App APIs oder Inhalte in einem Frameworkpaket verwenden muss, kann sie dem Frameworkpaket einen Laufzeitverweis hinzufügen. Dieser Verweis informiert das Betriebssystem darüber, dass das Frameworkpaket aktiv verwendet wird und alle Versionsupdates parallel verarbeitet werden sollen. Wenn eine neue Version des Frameworkpakets installiert wird, eine ausgeführte App aber eine ältere Version verwendet, kann das Betriebssystem die ältere Version erst entfernen, wenn alle Laufzeitverweise auf die ältere Version entfernt wurden.

Angenommen, folgendes Szenario liegt vor:

  • App A wird ausgeführt und verwendet Version 1.0.0.0 eines bestimmten Frameworkpakets.
  • App B wird installiert und ist von Version 1.0.0.1 desselben Frameworkpakets abhängig.

In diesem Szenario werden beide Versionen des Frameworkpakets installiert und von App A und App B verwendet. Wenn App A jedoch vom Benutzer geschlossen und anschließend neu gestartet wird, wird die neuere Version 1.0.0.1 des Frameworkpakets verwendet. Zu diesem Zeitpunkt ist die Laufzeitverweis-Anforderung zur Verwendung von Version 1.0.0.0 des Frameworkpakets nicht mehr gültig, und das Betriebssystem kann Version 1.0.0.0 problemlos entfernen. Wenn App A und App B später vom Benutzer deinstalliert werden, ist die Installationszeitverweis-Anforderung nicht mehr gültig, und das Betriebssystem kann das Frameworkpaket problemlos vollständig entfernen.

Für gepackte Apps, die das PackageDependency-Element verwenden, um statische Verweise auf Frameworkpakete festzulegen, werden die Installationszeitverweise für Frameworkpakete vom Betriebssystem nachverfolgt, wenn die App installiert oder deinstalliert wird. Bei Laufzeitverweisen, die mithilfe des Features der dynamischen Abhängigkeiten verwaltet werden, erkennt das Betriebssystem, wann eine gepackte App ausgeführt wird, und entfernt in Betrieb befindliche Frameworkpakete nicht, wenn neuere verfügbar sind.