Applications Windows : packaging, déploiement et processus

Remarque

Certaines informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Cette rubrique traite de vos options concernant :

• Si votre application sera ou non packagée.
• Comment vous allez déployer/distribuer votre application et comment elle sera installée.
• Le processus d'exécution de votre application—son degré d'isolement ; et quelles API seront disponibles.

Vous pouvez prendre ces décisions pour les applications nouvelles et existantes. Mais si vous êtes encore au stade de la planification d'une nouvelle application, avant de commencer à réfléchir aux considérations ci-dessus, décidez d'abord quelle plate-forme de développement et quel cadre d'interface utilisateur (UI) vous utiliserez pour votre application. Et pour cette décision, consultez Un aperçu des options de développement Windows.

Emballé ou non emballé

La décision de rendre votre application packagée ou non est d'abord déterminée par un concept appelé identité de package, que nous décrirons dans cette section. Si vous n'en avez pas besoin, la décision dépend de l'expérience d'installation souhaitée pour vous-même et pour vos utilisateurs. Examinons les détails de ces choses.

De nombreuses fonctionnalités d'extensibilité de Windows—notamment les tâches en arrière-plan, les notifications, les mosaïques dynamiques, les extensions de menu contextuel personnalisées et les cibles de partage—peuvent être utilisées par une application uniquement si cette application possède une identité de package au moment de l'exécution. Ceci est dû au fait que le système d’exploitation doit être en mesure d’identifier l’appelant de l’API correspondante. Consultez Fonctionnalités nécessitant une identité de package.

• Si vous devez utiliser l’une de ces fonctionnalités, votre application a besoin d’une identité de package. Et par conséquent, il doit s’agir d’une application packagée (les applications packagées sont les seules à avoir une identité de package). Une application packagée est packagée à l’aide de la technologie MSIX (voir Qu’est-ce que MSIX ?).
  • Pour une nouvelle application, le processus de packaging est simple (et à la fin de cette section vous trouverez des informations sur la façon de le faire).
  • Pour certaines applications existantes, vous pouvez suivre le même processus de packaging que pour une nouvelle application. Mais comme certaines applications existantes ne sont pas encore prêtes à ce que tout leur contenu soit présent dans un package MSIX, il existe une option pour que votre application soit empaquetée avec un emplacement externe. Cela permet à votre application d'avoir une identité de package ; pouvant ainsi utiliser les fonctionnalités qui le nécessitent. Pour plus d’informations, consultez Accorder l’identité du package en empaquetant avec un emplacement externe.
• Même si vous n'avez besoin d'utiliser aucune de ces fonctionnalités, la création d'une application packagée reste une bonne idée. Il offre à vos utilisateurs le moyen le plus simple d'installer, de désinstaller et de mettre à jour votre application. Pour plus d’informations, consultez Déploiement/distribution/installation dans cette rubrique.
• Mais créer une application non packagée est une option.

Ce qu'il faut retenir, c'est que les applications packagées sont les seules à avoir une identité de package (et elles offrent la meilleure expérience d'installation). Une application non packagée n’a pas d’identité de package ; il ne peut donc pas utiliser les API/fonctionnalités mentionnées ci-dessus.

Pour plus de détails sur les versions packagées et non packagées, voir Présentation du déploiement ; en particulier, la section Avantages et inconvénients de l'empaquetage de votre application dans cette rubrique. Ce sujet mentionne également l'option packagée avec emplacement externe.

Pour plus d'informations sur la façon de configurer votre application comme étant packagée ou non :

• Applications WinUI 3 (SDK d'application Windows). Voir la propriété du projet Visual Studio AppxPackage dans Propriétés du projet ; et consultez Créer votre premier projet WinUI 3 (Windows App SDK).
• Applications de bureau. Voir Configurer votre application de bureau pour le packaging MSIX.
• Applications de la plateforme Windows universelle (UWP). Les applications UWP sont déjà configurées comme packagées ; et cette configuration ne peut pas être modifiée.

Consultez également la section Gestionnaire de package Windows et le client WinGet de cette rubrique.

Déploiement/distribution/installation

• Une application packagée est packagée à l’aide de la technologie MSIX.
  • Une application packagée est également installée à l’aide de MSIX. Mais si vous choisissez de packager avec un emplacement externe, vous pouvez alors considérer cela comme un modèle « apportez votre propre installateur ». Vous aurez donc du travail d'installation à faire avec cette option. Pour plus d’informations, consultez Accorder l’identité du package en empaquetant avec un emplacement externe.
• Une application non packagée n'implique pas du tout MSIX.

Alors, pourquoi est-il important que votre application soit packagée ou non ?

• Eh bien, MSIX offre à vos utilisateurs un moyen simple d'installer, de désinstaller et de mettre à jour votre application. La désinstallation est propre—lorsque votre application est désinstallée, le système est restauré dans le même état qu'il était avant l'installation ; aucun artefact n’est laissé derrière.
• Ce type d’application prend également en charge les mises à jour incrémentielles et automatiques.
• Le Microsoft Store optimise les applications de ce type (bien qu'elles puissent être utilisées dans ou hors du Store).
• Il s'agit d'un chemin simple à utiliser via l'attachement d'application MSIX (pour les machines virtuelles Azure Virtual Desktop). Pour plus d’informations, consultez Qu’est-ce que l’attachement d’application MSIX ?.
• Un package signé bénéficie d’une forte anti-falsification. Cet avantage est encore plus important que pour une application non packagée installée sous Fichiers de programme.

Consultez également la section Gestionnaire de package Windows et le client WinGet de cette rubrique.

AppContainer ou Medium IL

La possibilité d'exécuter ou non votre application dans un AppContainer est une question de sécurité. Le processus d’une application AppContainer et ses processus enfants s’exécutent à l’intérieur d’un conteneur d’application léger, où ils peuvent accéder uniquement aux ressources auxquelles l’accès leur est spécifiquement accordé. En outre, ils sont isolés par le biais de la virtualisation du système de fichiers et du Registre. Ainsi, les applications implémentées dans un environnement AppContainer ne peuvent pas être piratées pour autoriser des actions malveillantes au-delà des ressources affectées limitées.

Les applications packagées ou non peuvent être configurées pour s'exécuter dans un AppContainer. Mais le processus est plus simple pour les applications packagées. Si une application n'est pas une application AppContainer, il s'agit alors d'une application Medium IL.

Pour plus d'informations, consultez AppContainer pour les applications héritées et Applications MSIX AppContainer.

Pour plus d'informations sur la configuration de votre application pour qu'elle s'exécute dans un AppContainer ou Medium IL :

• Applications WinUI 3 (SDK d'application Windows). Consultez l’attribut uap10:TrustLevel manifeste du package d’application dans Configurer un projet WinUI 3 pour AppContainer.
• Applications de bureau. Consultez la propriété du projet Visual Studio TrustLevel dans les applications MSIX AppContainer (dans la section appropriée à votre type d'application).
• Applications de la plateforme Windows universelle (UWP). Les applications UWP sont déjà configurées pour s'exécuter dans un AppContainer ; et cette configuration ne peut pas être modifiée.

N'oubliez pas que les applications non packagées n'ont pas de manifeste de package d'application. Ainsi, pour les applications non packagées, vous déclarez votre décision AppContainer-or-Medium-IL dans votre fichier de projet plutôt que dans un manifeste de package d'application.

Isolement des applications Win32

Important

La fonctionnalité décrite dans cette section est disponible dans les versions préliminaires de Windows Insider Preview.

L'isolation des applications Win32 est une fonctionnalité de sécurité à venir dans Windows qui, en cas de compromission d'une application, aide à contenir les dommages et à protéger les choix de confidentialité des utilisateurs. Cette fonctionnalité repose sur AppContainers et des composants qui virtualisent les ressources et fournissent un accès négocié à d'autres ressources. Pour obtenir de la documentation et des outils pour vous aider à isoler vos applications, consultez Bienvenue dans le dépôt d'isolation d'application Win32.

Fonctionnalités de l’application

Les fonctionnalités des applications (par exemple, internetClient, emplacement, microphone et Bluetooth) concernent principalement les applications packagées qui s'exécutent dans un AppContainer. Cela inclut donc toutes les applications de la plateforme Windows universelle (UWP) et certaines applications de bureau.

Mais il existe certains scénarios dans lesquels même une application Medium IL (c'est-à-dire pas une application AppContainer) devrait déclarer une fonctionnalité. Un exemple est la capacité restreinte runFullTrust.

Pour plus de détails sur les fonctionnalités des applications, les types d'applications auxquels elles s'appliquent et comment les configurer, consultez Déclarations de fonctionnalités des applications. Vous configurez les fonctionnalités dans le manifeste de votre package d’application ; et c'est pourquoi ils s'appliquent uniquement aux applications packagées.

Types d'applications

Les applications de bureau et les applications de plateforme Windows universelle (UWP) sont les deux principaux types d'applications—bien qu'il existe plusieurs types d'applications dans la famille des applications de bureau. Le choix d'un framework d'interface utilisateur—WinForms, WPF, Win32, Direct 2D/3D, UWP ou WinUI 3—est une option qui est dans une certaine mesure indépendante des configurations décrites dans cette rubrique.

Mais examinons en quoi ces types d'applications peuvent différer les uns des autres en termes de packaging, de déploiement et de processus.

Tout d’abord, toutes les applications UWP sont packagées et exécutées dans un AppContainer. Mais pour les applications de bureau, les choses sont plus flexibles. Vous pouvez choisir de packager ou non votre application de bureau. Et, indépendamment de cette décision, vous pouvez choisir de configurer votre application de bureau en tant qu'application AppContainer ou Medium IL.

	Empaqueté	Non empaqueté
AppContainer	Applications de bureau Applications UWP	Applications de bureau
IL moyen	Applications de bureau	Applications de bureau

Pour les applications packagées, pour configurer le type d’application souhaité, vous utilisez l’attribut uap10:RuntimeBehavior dans le manifeste de votre package d’application (voir Application (Windows 10)).

• Les applications de bureau sont .exe des Windows, généralement dotées d'une fonction de point d'entrée principale ou WinMain. Pour configurer votre application en tant qu'application de bureau, définissez uap10:RuntimeBehavior sur « packagedClassicApp » ou « win32App ».
  • La valeur « packagedClassicApp » indique soit une application WinUI 3 (Windows App SDK), soit une application Desktop Bridge (Centennial). La différence est qu'une application Centennial s'exécute dans un AppContainer.
  • Et "win32App" indique tout autre type d'application Win32 (y compris une application fournie avec un emplacement externe).
• Enfin, le réglage uap10:RuntimeBehavior sur « windowsApp » vous donne une application UWP.

Pour connaître toutes les options relatives aux types d'applications que vous pouvez développer, consultez Développement d'applications Windows : options et fonctionnalités.

SDK d'application Windows—dépendant du framework ou autonome

Si vous développez ou gérez une application qui utilise le SDK d'application Windows, vous avez une autre décision à prendre. Parce qu’il existe les deux manières suivantes pour déployer le SDK d’application Windows dont dépend votre application :

• Dépend du framework (valeur par défaut). Votre application a besoin que le runtime du SDK d’application Windows et/ou le package Framework soient présents sur la machine cible.
• Autonome. Votre application emporte avec elle ses dépendances du SDK d’application Windows.

Pour plus d’informations, consultez Présentation du déploiement du SDK d’application Windows.

Gestionnaire de package Windows et le client WinGet

Un gestionnaire de package peut aider vos utilisateurs à installer/mettre à niveau/configurer votre logiciel en automatisant le flux de travail. Les gestionnaires de packages peuvent permettre d’installer n’importe quel logiciel, mais ils ont tendance à être utilisés principalement pour installer des outils de développement. Par conséquent, si vous générez un outil de développement, vous serez peut-être particulièrement intéressé dans cette option. Mais son mode de fonctionnement est le suivant :

• Vous, en tant que développeur de logiciels, définissez au gestionnaire de package (sous forme d’instructions déclaratives) tous les éléments nécessaires pour une installation réussie de votre produit.
• Ensuite, lorsqu’un utilisateur installe votre logiciel, le gestionnaire de package suit vos instructions déclaratives pour automatiser le flux de travail d’installation et de configuration.

Le résultat est une réduction du temps passé à préparer l’environnement d’un utilisateur et obtenir une meilleure compatibilité entre les composants installés. Vous pouvez également utiliser Gestionnaire de package Windows pour distribuer vos applications empaquetées ou non empaquetées dans des formats tels que .msix, .msi et .exe.

Si vous souhaitez obtenir plus d’informations, consultez Gestionnaire de package Windows.