Partager via

Architecture et vue d’ensemble du déploiement pour les applications dépendantes de l’infrastructure

  • Article

Cet article explique une architecture de haut niveau de déploiement SDK d'application Windows. Les concepts ci-dessous s’appliquent principalement à SDK d'application Windows applications dépendantes de l’infrastructure. Une application dépendante de l’infrastructure dépend de la présence du runtime SDK d'application Windows sur l’ordinateur cible.

Il existe deux options main pour distribuer une application dépendante de l’infrastructure :

Méthode de déploiement d’application Configuration requise
Empaqueté - Doit déclarer la dépendance vis-à-vis du package Framework dans le manifeste du package.
- L’API de déploiement est requise pour les applications distribuées du Microsoft Store et recommandée pour les applications distribuées hors Store afin de garantir l’installation des dépendances d’exécution.
Packagée avec un emplacement externe ou non packagée - Doit distribuer le runtime à l’aide du programme d’installation ou en installant directement les packages MSIX requis.
- Exigences supplémentaires du runtime : doit initialiser l’accès au runtime SDK d'application Windows via l’API Bootstrap.

Pour plus d’informations sur ces exigences, consultez les articles suivants :

Termes clés

Les sections suivantes définissent des termes clés pour SDK d'application Windows déploiement et des détails supplémentaires sur certains de ces packages.

Terme Définition
runtime SDK d'application Windows Packages MSIX requis par une application pour utiliser le SDK d'application Windows. Ces packages incluent : Framework, Main, Singleton et DDLM. En fonction des fonctionnalités utilisées et de votre méthode de déploiement d’application, vous aurez besoin d’un certain ensemble de ces packages sur l’ordinateur cible.
Package d’infrastructure Contient des fichiers binaires utilisés au moment de l’exécution par les applications (la plupart SDK d'application Windows fonctionnalités). Le framework inclut un composant de programme d’amorçage qui permet aux applications d’installer automatiquement la dernière version du SDK d'application Windows, qui sera mise à jour à une cadence de publication régulière.
Package main Package qui contient des tâches en arrière-plan pour effectuer le suivi des dépendances dynamiques et active les mises à jour automatiques du package Framework à partir du Microsoft Store.
Package Singleton Contient des tâches en arrière-plan, des services, des extensions d’application et d’autres composants non inclus dans le package Framework, tels que les notifications Push. Il s’agit généralement d’un seul processus de longue durée réparti entre les applications.
Package Dynamic Dependency Lifetime Manager (DDLM) Empêche le système d’exploitation d’effectuer des mises à jour de maintenance sur les packages MSIX pendant l’utilisation d’une application empaquetée avec un emplacement externe ou non empaquetée.
Programme d’amorçage Binaire local d’application utilisé par empaqueté avec un emplacement externe et des applications non empaquetées pour localiser et charger la meilleure version SDK d'application Windows correspond à la version de l’application.
Approvisionnement Le processus d’installation et d’inscription des packages (y compris les fichiers et les clés de Registre) à l’échelle du système pour éliminer la nécessité d’une installation répétée par les autres utilisateurs. Elle peut être effectuée dans le cadre du système d’exploitation ou lors de l’installation d’une application.
Programme d’installation Fait référence au programme d’installation .exe qui déploie les packages Framework, Main, Singleton et DDLM.
MSIX Technologie d’installation moderne qui permet aux utilisateurs d’installer en toute sécurité une application par utilisateur, directement à partir du Microsoft Store ou d’un site web. Sur les PC d’entreprise ou partagés, les applications peuvent être installées pour tous les utilisateurs via PowerShell et MDM.

Package d’infrastructure

Lorsque vous générez une application qui utilise le SDK d'application Windows, votre application fait référence à un ensemble de composants d’exécution SDK d'application Windows qui sont distribués aux utilisateurs finaux via un package d’infrastructure. Le package d’infrastructure permet aux applications d’accéder à SDK d'application Windows composants via une source partagée unique sur l’appareil de l’utilisateur, au lieu de les regrouper dans le package d’application. Le package d’infrastructure comporte également ses propres ressources, telles que des DLL et des définitions d’API (inscriptions COM et Windows Runtime). Ces ressources s’exécutent dans le contexte de votre application, de sorte qu’elles héritent des fonctionnalités et des privilèges de votre application, et n’affirment pas leurs propres fonctionnalités ou privilèges. Pour plus d’informations sur les dépendances de package d’infrastructure, consultez Packages d’infrastructure MSIX et dépendances dynamiques.

Le package d’infrastructure SDK d'application Windows est un package MSIX déployé pour les utilisateurs finaux via le Microsoft Store. Il peut être facilement et rapidement mis à jour avec les versions de maintenance, qui peuvent inclure des correctifs de sécurité et de fiabilité. Toutes les applications dépendantes de l’infrastructure qui utilisent le SDK d'application Windows ont une dépendance sur une instance partagée du package d’infrastructure, comme illustré dans le diagramme suivant.

Diagramme montrant comment les applications accèdent au package d’infrastructure SDK d'application Windows

Lorsqu’une nouvelle version du package d’infrastructure SDK d'application Windows est mise en service, toutes les applications dépendantes de l’infrastructure sont mises à jour vers la nouvelle version sans avoir à redistribuer une copie. Windows met à jour la dernière version des frameworks au fur et à mesure de leur publication, et les applications référencent automatiquement la dernière version du package d’infrastructure lors de la relance. Les versions de package d’infrastructure plus anciennes ne seront pas supprimées du système tant qu’elles ne sont plus en cours d’exécution ou utilisées activement par les applications sur le système.

Diagramme montrant comment les applications obtiennent des mises à jour du package d’infrastructure SDK d'application Windows

Étant donné que la compatibilité des applications est importante pour Microsoft et pour les applications qui dépendent de l’SDK d'application Windows, le package d’infrastructure SDK d'application Windows suit les règles de gestion sémantique de version 2.0.0. Cela signifie qu’après la publication de la version 1.0 du SDK d'application Windows, le package d’infrastructure SDK d'application Windows garantit la compatibilité entre les modifications de version mineure et de version corrective, et les modifications cassants se produisent uniquement entre les mises à jour de version majeure.

Package Singleton

Le package singleton garantit qu’un seul processus de longue durée peut gérer les services utilisés dans plusieurs applications, qui peuvent s’exécuter sur différentes versions du SDK d'application Windows.

La SDK d'application Windows singleton est nécessaire pour activer les notifications Push pour les applications non empaquetées et les applications Win32 empaquetées utilisant des versions Windows inférieures à 20H1, qui ne peuvent pas être prises en charge par les classes UWP PushNotificationTrigger et ToastNotificationActionTrigger existantes. Les fonctionnalités futures SDK d'application Windows qui ne peuvent pas être prises en charge par le package Framework seront ajoutées au package Singleton.

Exigences supplémentaires pour les applications non empaquetées

Programme d'amorçage

Le programme d’amorçage est une bibliothèque qui doit être incluse avec votre package avec un emplacement externe ou une application non empaquetée. Il fournit l’API du programme d’amorçage (voir Utiliser le runtime SDK d'application Windows pour les applications empaquetées avec un emplacement externe ou non empaquetées), qui permet aux applications non empaquetées d’effectuer les tâches importantes suivantes :

  • Initialisez le Gestionnaire de durée de vie des dépendances dynamiques (DDLM) pour le package d’infrastructure SDK d'application Windows.
  • Recherchez et chargez le package d’infrastructure SDK d'application Windows dans le graphique de package de l’application.

Pour accomplir ces tâches, le package nuget utilise les initialiseurs de module pour relier le programme d’amorçage à votre place. <WindowsPackageType>None</WindowsPackageType> Définissez simplement dans votre fichier projet. Dans les scénarios avancés, si vous souhaitez contrôler l’initialisation, vous pouvez appeler l’API du programme d’amorçage directement dans le code de démarrage de votre application (voir Tutoriel : Utiliser l’API du programme d’amorçage dans une application empaquetée avec un emplacement externe ou non empaquetée qui utilise le SDK d'application Windows) afin qu’elle puisse initialiser correctement le système pour l’application non empaquetée. Votre application doit utiliser l’API du programme d’amorçage avant de pouvoir utiliser SDK d'application Windows fonctionnalités telles que WinUI, le cycle de vie de l’application, MRT Core et DWriteCore.

La bibliothèque de programme d’amorçage de la version SDK d'application Windows 1.0 comprend :

  • Microsoft.WindowsAppRuntime.Bootstrap.dll (C++ et C#)
  • Microsoft.WindowsAppRuntime.Bootstrap.Net.dll (wrapper C#)

Gestionnaire de durée de vie des dépendances dynamiques (DDLM)

L’objectif du DDLM est d’empêcher la maintenance du package d’infrastructure SDK d'application Windows pendant son utilisation par une application non empaquetée. Il contient un serveur qui doit être initialisé par le programme d’amorçage au début du démarrage d’une application pour fournir cette fonctionnalité.

Il existe un DDLM pour chaque version et architecture du package d’infrastructure SDK d'application Windows. Cela signifie que sur un x64 ordinateur, vous pouvez avoir une x86 version et une x64 version de DDLM pour prendre en charge les applications des deux architectures.

Autres conditions requises