Vue d’ensemble de l’emballage

L’empaquetage définit la façon dont votre application est installée, mise à jour et intégrée à Windows. Les applications WinUI 3 sont empaquetées par défaut, tandis que de nombreuses applications de bureau, telles que les applications Win32 traditionnelles, s’exécutent non empaquetées. Le choix entre une application empaquetée ou non empaquetée affecte les fonctionnalités que vous pouvez utiliser, le modèle de déploiement sur lequel vous vous appuyez et l’expérience globale que vos clients obtiennent.

Note

Création d’une nouvelle application WinUI 3 ? Vous êtes déjà empaqueté par défaut. Les conseils ci-dessous sont les plus pertinents pour les développeurs qui doivent faire un choix explicite , généralement lors du portage d'une application existante, du déploiement sur des machines d'entreprise ou de l'ajout de fonctionnalités Windows à une application qui n'a pas été empaquetée à l'origine.

Pourquoi l’empaquetage des applications est important

Les applications empaquetées bénéficient d’un modèle d’installation propre, de mises à jour automatiques et d’accès aux fonctionnalités Windows qui nécessitent une identité de package, notamment les tâches en arrière-plan, les notifications, les extensions de menu contextuel, les cibles de partage et d’autres points d’extensibilité. L’empaquetage permet également de garantir des déploiements plus propres, des mises à jour fiables et une distribution simplifiée par le biais de canaux tels que les outils de déploiement Microsoft Store et d’entreprise.

Fonctionnalités nécessitant l’identité du package

Ces fonctionnalités Windows fonctionnent uniquement dans les applications qui ont une identité de paquet, via l’empaquetage MSIX complet ou empaquetage avec emplacement externe (empaquetage clairsemé).

Fonctionnalité Description
Tâches en arrière-plan Exécutez du code lorsque votre application n’est pas au premier plan, par exemple pour synchroniser des données, traiter les téléchargements ou répondre aux événements système.
API Windows AI (Phi Silica, OCR, etc.) Accédez aux fonctionnalités IA sur appareil, telles que les modèles linguistiques locaux, la reconnaissance de texte et l’analyse d’images.
Notifications Push (WNS) Recevez des notifications en temps réel de votre service cloud via le service de notification Windows.
Cible de partage Permettre aux utilisateurs de partager du contenu à partir d’autres applications directement dans le vôtre via la feuille Partage système.
Extensions de menu contextuel personnalisées Ajoutez les actions de votre application au menu contextuel dans l’Explorateur de fichiers et d’autres surfaces d’interpréteur de commandes.
Associations de type de fichier et de protocole Inscrivez votre application en tant que gestionnaire pour des types de fichiers ou des protocoles URI spécifiques (par exemple yourapp://).
Tâches de démarrage Lancez votre application automatiquement lorsque l’utilisateur se connecte à Windows.
Services d’application Exposez les services en arrière-plan auxquels d’autres applications peuvent appeler, ce qui permet la communication entre applications.

Conseil / Astuce

Si votre application n'est pas empaquetée et que vous obtenez des erreurs E_ILLEGAL_METHOD_CALL ou APPMODEL_ERROR_NO_PACKAGE lors de l'appel des API Windows, cela est dû à l'exigence d'identité de package. Consultez Empaquetage avec emplacement externe (empaquetage épars) comme solution la plus simple.

Pour détecter au moment de l’exécution si votre processus a une identité de package, utilisez GetCurrentPackageFullName - consultez Ce processus empaqueté ? dans le blog Inside MSIX pour obtenir des exemples C++ et C# canoniques.

Pour plus d’informations, consultez Fonctionnalités qui nécessitent une identité de package.

Empaquetage des modèles en un clin d’œil

Modèle Identité du package Installateur Magasin admissible Idéal pour
Empaqueté (MSIX) ✅ Oui MSIX remplace le programme d’installation ✅ Oui (soumission MSIX) Nouvelles applications, publication du Windows Store, gestion des appareils mobiles d’entreprise
Emballage avec emplacement externe ✅ Oui Votre programme d’installation existant ✅ Oui (soumission MSI/EXE) Applications existantes avec propre programme d’installation, éditeurs de logiciels indépendants
Non empaqueté ❌ Non Programme d’installation MSI ou EXE (également : XCopy ou script pour la distribution non-Store) ✅ Oui (soumission MSI/EXE : nécessite un programme d’installation MSI ou EXE avec prise en charge de l’installation silencieuse) Distribution étendue de Win32, outils internes

Applications empaquetées (MSIX)

Les applications empaquetées utilisent MSIX et ont package identity, ce qui est nécessaire pour de nombreux points d’extensibilité Windows. L’identité de package permet Windows d’identifier de manière fiable l’appelant des API de plateforme, c’est pourquoi ces fonctionnalités dépendent de celle-ci.

Empaquetage avec emplacement externe (empaquetage épars)

L'empaquetage avec emplacement externe (également appelé packages épars) vous permet d'enregistrer un petit package d'identité aux côtés de votre application existante, sans modifier votre programme d'installation, l'emplacement des fichiers binaires ni le processus de mise à jour. Il a été introduit dans Windows 10 version 2004 (build 19041).

C'est l'endroit idéal pour les applications Win32/WPF/WinForms existantes qui sont fournies via leur propre programme d'installation (NSIS, WiX, InstallShield, etc.) et ne veulent pas la remplacer par MSIX. Vous inscrivez un package d’identité léger, vos fichiers binaires restent là où ils se trouvent et vous déverrouillez l’ensemble complet de fonctionnalités de Windows liées à l’identité de package.

Capacité MSIX Emplacement externe
Remplace votre programme d’installation Oui Non
Fichiers binaires à l’intérieur du package Oui Non (externe)
Magasin admissible Oui (soumission MSIX) Oui (soumission MSI/EXE)
Identité du package Oui Oui
Mécanisme de mise à jour Mise à jour MSIX Votre mécanisme existant

→ Procédure complète : accorder une identité de package avec un empaquetage à emplacement externe

Applications non empaquetées

Les applications non empaquetées n’utilisent pas MSIX et n’ont pas d’identité de package, ce qui signifie qu’elles ne peuvent pas accéder aux fonctionnalités répertoriées ci-dessus.

  • Ils restent entièrement illimités en termes de surface d'API, d'accès au système de fichiers, d'accès au Registre, d'élévation de privilèges et de modèle de processus.
  • L’installation et les mises à jour s’appuient sur .exe, .msi, les programmes d’installation personnalisés, ClickOnce ou le déploiement de xcopy.

Avant de vous engager à utiliser une version non emballée, vérifiez le tableau des fonctionnalités ci-dessus par rapport à votre feuille de route. Si vous envisagez d'utiliser des notifications, des tâches en arrière-plan ou les API Windows AI, pensez à démarrer directement avec une application empaquetée.

Choisir par scénario

Scénario Modèle recommandé Détails
Publication du développeur indépendant sur le Microsoft Store Emballé (MSIX) recommandé MSIX est le chemin recommandé : il active les mises à jour gérées par le Windows Store, les téléchargements différentiels et la désinstallation propre. Les applications WinUI 3 sont empaquetées par défaut. La signature de code est gérée gratuitement par le Windows Store. → Distribuer votre application empaquetée

Les applications Win32 avec un programme d’installation MSI ou EXE existant peuvent également être publiées sur le Store via le chemin d’envoi MSI/EXE, mais le Store ne transmet pas les mises à jour aux utilisateurs existants . Les mises à jour doivent être gérées par l’application ou le programme d’installation.
application d'entreprise déployée via Intune ou Configuration Manager Empaqueté ou emplacement externe pour les installateurs existants Les nouvelles applications doivent utiliser MSIX. Les applications existantes disposant de leur propre programme d'installation peuvent utiliser un empaquetage à emplacement externe. Signature de code : utilisez un certificat auto-signé (approuvé via Intune, la stratégie de groupe ou Configuration Manager) ou Azure Artifact Signing (anciennement Trusted Signing). → Déployer des applications empaquetées
Un éditeur de logiciels indépendant livre un téléchargement direct avec son propre programme d’installation Empaquetage avec emplacement externe Inscrivez un paquet d'identité léger en même temps que votre programme d’installation existant. Signature de code : un certificat approuvé par l’autorité de certification est requis pour la distribution non-Store. Azure Signature d’artefact (anciennement Signature approuvée) est l’option recommandée à moindre coût. → Accorder une identité de package

Vous pouvez également soumettre votre programme d’installation existant au Windows Store via le chemin d’envoi MSI/EXE.
Outil interne ou utilitaire de développement Non empaqueté Le plus simple à construire et déployer. Le SDK d'application Windows fonctionne via NuGet, mais certaines fonctionnalités ne seront pas disponibles.

Conseil / Astuce

Vous n’êtes pas sûr des coûts de signature de code ? La publication d'un package MSIX par le Microsoft Store signifie que vous n'avez pas besoin d'obtenir ou de gérer séparément un certificat pour la confiance de l'utilisateur final — Microsoft re-signe le package. La publication d’un programme d’installation Win32 MSI/EXE via le Store nécessite un chaînage de certificats à une autorité de certification dans le programme racine approuvé Microsoft ; un certificat auto-signé n'est pas accepté. Pour d’autres chemins de distribution, votre approche de signature dépend du contexte de déploiement : les environnements d’entreprise peuvent approuver un certificat auto-signé par le biais de la gestion des appareils, tandis que la distribution non-Store plus large nécessite généralement une solution de signature de code approuvée par l’autorité de certification. Azure Artifact Signing (anciennement Trusted Signing) est l'option recommandée par Microsoft (voir la tarification) et ne nécessite aucun jeton matériel.

Déploiement dépendant de l’infrastructure et autonome

Séparément du modèle d’empaquetage, les applications utilisant le SDK d'application Windows choisissez comment gérer leurs dépendances d’exécution :

  • Dépendant du Framework : l'environnement d'exécution SDK d'application Windows doit être installé sur l'ordinateur de l'utilisateur. Empreinte d’application plus petite ; s’appuie sur le runtime présent ou installé automatiquement.
  • autonome : tous les fichiers binaires SDK d'application Windows sont expédiés avec votre application. Encombrement plus important ; aucune nécessité d’exécution externe. Convient pour les environnements d’entreprise verrouillés.

→ Déployer des applications autonomes

Commencer avec MSIX

Si vous créez une application de bureau Win32 (parfois appelée application de bureau classique) ou une application de .NET , y compris Windows Presentation Foundation (WPF) et Windows Forms (WinForms), vous pouvez empaqueter et déployer votre application à l’aide de MSIX.

Migration vers MSIX à partir de programmes d’installation hérités

Si votre application utilise actuellement un programme d’installation hérité, vous pouvez migrer vers MSIX pour obtenir une nouvelle installation/désinstallation, des mises à jour automatiques, la distribution du Windows Store et l’identité du package. Le chemin de migration dépend de votre technologie d’installation actuelle et de l’accès au code source.

Installateur actuel Chemin de migration recommandé Code source requis ?
MSI (programme d’installation Windows) Utilisez l’outil d’empaquetage MSIX pour convertir le MSI directement en MSIX. Gère la plupart des modèles MSI, y compris les actions personnalisées. Non
ClickOnce (.NET) Recompiler à partir du code source à l’aide du projet de packaging MSIX de Visual Studio. La mise à jour automatique ClickOnce peut être remplacée par les mises à jour du Windows Store ou le programme d’installation d’application. Oui
InstallShield / Advanced Installer Utilisez MSIX Packaging Tool pour capturer une installation sur une machine virtuelle propre. Des actions personnalisées complexes peuvent nécessiter une correction manuelle dans l’Éditeur de package. Non
Inno Setup / NSIS Utilisez le flux de travail de capture basé sur les machines virtuelles de l’outil MSIX Packaging Tool. Exécutez le programme d’installation EXE dans l’environnement propre de l’outil. Non
App-V (packages virtuels) Convertissez directement avec l’outil de création de package MSIX — il prend en charge les packages App-V 5.x en entrée. Non
MSIX avec des modifications nécessaires Utilisez l’infrastructure de prise en charge du package pour appliquer des correctifs d’exécution (redirection de fichier/registre) sans modifier votre code d’application. Non

Conseil / Astuce

Pour les applications qui ont des programmes d’installation complexes avec des pilotes de noyau, des services s’exécutant sous SYSTEM ou des enregistrements COM à l’échelle de la machine que MSIX ne prend pas en charge, envisagez MSIX avec emplacement externe (empaqueté avec emplacement externe). Cela vous donne une identité de package pour les fonctionnalités de Windows lors de l’utilisation d’un programme d’installation traditionnel pour les composants qui nécessitent un accès élevé. Consultez Donner une identité au paquet en l'empaquetant avec un emplacement externe.

Considérations importantes

  • Test sur une machine virtuelle propre : MSIX Packaging Tool capture toutes les modifications lors de l’installation. Exécutez-la sur une image de Windows propre pour éviter de capturer les modifications système non liées.
  • Infrastructure de prise en charge des packages : si votre application convertie rencontre des problèmes d’exécution (hypothèses de chemin de fichier, écritures de Registre dans HKLM), le Framework de support de package peut résoudre ces problèmes sans modifier votre source.
  • Côte à côte avec le programme d’installation hérité : vous pouvez déployer la version MSIX en même temps que le programme d’installation hérité pendant la transition. Planifiez une migration explicite des paramètres/données (par exemple, importer lors de la première exécution), car l’identité du package et les emplacements de stockage diffèrent entre les installations MSIX et MSI/EXE.

Autres technologies d’installation

Contenu connexe

  • Last updated on