Choisir une méthode de distribution d'application Windows - MSI/MSIX/ClickOnce/xcopy/Updater personnalisé

Télécharger la feuille de calcul Excel d’aide à la décision (avec feuilles en japonais et en anglais)

Au moment de décider comment distribuer une application Windows, on a tendance à commencer la discussion par « quel est le plus récent » ou « lequel est le plus simple ». Mais ce qui compte vraiment en pratique se joue sur d’autres axes.

• Veut-on installer par utilisateur, ou à l’échelle de la machine ?
• Veut-on déléguer les mises à jour à une plateforme de distribution, ou les porter soi-même ?
• Y a-t-il une intégration à l’OS telle que services / pilotes / shell extensions / enregistrement COM ?
• Faut-il pouvoir tenir en environnement isolé (air-gapped), hors ligne, ou en distribution USB ?
• A-t-on besoin de package identity, ou veut-on tourner en Win32 simple, non restreint ?

Choisir une méthode de distribution n’est pas une question de préférence de format d’installateur — c’est un choix portant sur le degré d’intégration à l’OS et sur qui porte la responsabilité des mises à jour.

1. La conclusion d’abord

Dit de façon assez brute, mais utile en pratique :

• Si l’on installe à l’échelle de la machine, enregistre des services ou du COM, ou doit installer des prérequis, on part de MSI
• Si l’on suppose Windows 10/11 et veut une installation / désinstallation propre, des mises à jour fréquentes et la package identity, MSIX est un candidat solide
• Si l’on veut distribuer une application .NET de bureau interne par utilisateur, facilement, avec mise à jour automatique, ClickOnce reste remarquablement fort
• Si l’on privilégie les outils à déposer tels quels, les réseaux isolés, la distribution USB, et l’absence de droits administrateur, xcopy est le plus direct
• Si l’on veut porter soi-même l’UX de mise à jour, les canaux, le déploiement progressif, la télémétrie et la stratégie de récupération, c’est un updater personnalisé
• Si l’on a besoin d’un pilote, il est plus sûr de ne pas centrer sa réflexion sur MSIX dès le départ
• Si l’on a besoin d’une shell extension in-process pour l’Explorateur, il faut d’abord vérifier ce que MSIX peut couvrir et les conditions de version d’OS

Résumé sans détour :

1. Enregistrement OS important → plutôt MSI
2. On veut la package identity et le modern packaging → MSIX
3. On veut une distribution par utilisateur facile et des mises à jour intégrées → ClickOnce
4. La distribution « déposer et exécuter » est la priorité absolue → xcopy
5. On est prêt à concevoir et exploiter sa propre infrastructure de mise à jour → updater personnalisé

2. Les cinq ne jouent pas sur le même terrain

Ce point compte vraiment.

MSI / MSIX / ClickOnce / xcopy concernent surtout comment installer. Un updater personnalisé, à l’inverse, concerne surtout comment porter la responsabilité des mises à jour.

Donc en pratique, il est plus simple de raisonner en deux couches.

Il est donc plus stable de considérer qu’un updater personnalisé n’est pas ce que l’on choisit en premier, mais quelque chose que l’on ajoute lorsqu’une méthode de distribution existante ne couvre pas les exigences de mise à jour.

3. Le tableau de décision sur une page

Voici d’abord le tableau de décision le plus directement utilisable.

Le point le plus important de ce tableau est de ne pas sauter directement vers un updater personnalisé simplement parce qu’« il y a des mises à jour ».

4. Comparaison par critère

Ce qu’il faut chercher dans ce tableau, ce n’est pas ce qui est le plus fort, mais ce qui génère le moins de friction.

5. À quel type de projet chacun convient

5.1 MSI

MSI est le point de référence quand on veut installer / désinstaller / réparer proprement une application de bureau Windows traditionnelle.

Il convient particulièrement à des projets comme ceux-ci.

• Applications métier pour tous les utilisateurs
• Applications incluant un service Windows
• Applications impliquant un enregistrement COM, des associations de fichiers, ou des réglages à l’échelle de la machine
• Produits disposant déjà d’une exploitation d’installateur existante

La force de MSI est de permettre d’exprimer « comment l’application a été installée dans l’OS » selon les usages propres à Windows.

En contrepartie, ses faiblesses sont tout aussi claires.

• L’authoring est discrètement difficile
• Une conception négligée des upgrades / patches fait mal plus tard
• Plus on ajoute de custom actions, plus le tout devient fragile
• Pour les produits mis à jour fréquemment, l’UX de mise à jour tend à devenir lourde

5.2 MSIX

MSIX est le choix quand on veut du modern packaging et une mise à jour / désinstallation propre. Il prend aussi beaucoup de sens quand on veut utiliser des fonctionnalités Windows qui nécessitent la package identity.

Il convient à des cas comme ceux-ci.

• Applications de bureau pouvant supposer Windows 10/11
• Applications métier avec une cadence de mise à jour élevée
• Applications voulant des fonctionnalités Windows où la package identity compte
• Projets s’appuyant sur Intune ou App Installer

La force de MSIX est la propreté des mises à jour et de la désinstallation.

Mais tout ne convient pas. Ces quatre points en particulier sont plus sûrs à vérifier d’abord.

• Shell extension in-process (sur Windows 11 21H2 et au-delà, MSIX peut enregistrer des legacy context menu handlers et similaires, mais les déclarations du manifeste et l’OS ciblé doivent être vérifiés)
• Pilote
• Anciennes hypothèses Win32 non restreintes
• Configurations où l’on ne veut pas de package identity

5.3 ClickOnce

ClickOnce reste remarquablement fort quand on veut faire tourner une application .NET de bureau interne par utilisateur, rapidement, mises à jour comprises.

Il convient à des scénarios comme ceux-ci.

• Applications métier internes
• On veut une installation en utilisateur standard
• La distribution par utilisateur suffit
• On ne veut pas investir lourdement dans l’UX de mise à jour

À l’inverse, il est plus sûr de ne pas en attendre qu’il gère des produits qui touchent profondément l’OS, ni qu’il joue le rôle proche d’un installateur qui regroupe plusieurs prérequis.

5.4 xcopy

xcopy, c’est du déploiement, pas de l’installation. Il n’y a ni enregistrement de registre, ni fonction de réparation, ni package identity. En contrepartie, si déposer les fichiers suffit, c’est à peu près ce qu’il y a de plus simple.

Il excelle pour des outils comme ceux-ci.

• Outils de diagnostic
• Outils de configuration d’équipement
• Outils de collecte de logs
• Utilitaires remis sur site via une clé USB
• Cas où l’on veut faire coexister plusieurs versions côte à côte

La force de xcopy est que ses modes d’échec sont faciles à comprendre. On remplace le dossier entier ; si l’on veut revenir en arrière, on revient à la version précédente — ce type d’exploitation est simple.

Mais il a bien sûr des points faibles.

• Menu Démarrer / ARP / réparation
• Associations de fichiers / services / shell extensions / pilotes
• Mises à jour intégrées

5.5 Updater personnalisé

Un updater personnalisé est moins un choix de liberté qu’un choix de responsabilité.

Il devient pertinent d’y réfléchir quand on a des exigences comme celles-ci.

• Fréquence de mise à jour élevée
• On veut des canaux tels que stable / beta / preview
• On veut contrôler la diffusion progressive et les pourcentages de déploiement
• On veut un contrôle fin des téléchargements en arrière-plan, des notifications et des fenêtres de maintenance
• On veut sa propre télémétrie de mise à jour et sa propre récupération après crash

Les forces sont grandes, mais ce que l’on paie l’est tout autant.

• Vérification de signature
• Un manifeste de diffusion
• Tentatives / reprises
• Prise en charge des proxys / pare-feux / environnements isolés
• Rollback
• Récupération après une mise à jour cassée
• Mise à jour de l’updater lui-même

Autrement dit, ce qui augmente, ce n’est pas la liberté, mais la responsabilité.

6. Les points sur lesquels on hésite souvent

6.1 A-t-on besoin de la package identity ?

Si ce que l’on veut est une fonctionnalité Windows qui présuppose la package identity, la valeur de MSIX grimpe d’un coup.

À l’inverse, si l’on veut

• un accès non restreint au système de fichiers
• un accès non restreint au registre
• de la liberté sur le modèle d’élévation / de processus
• conserver telles quelles d’anciennes hypothèses Win32

alors les méthodes plutôt « unpackaged » sont plus naturelles.

6.2 Y a-t-il des services / pilotes / shell extensions ?

Ces trois éléments alourdissent d’un coup la méthode de distribution.

• Pilote : mal adapté à MSIX
• Shell extension in-process : mal adaptée à MSIX
• Service Windows : naturel avec MSI ; comparable sous conditions avec MSIX

Plus les éléments couplés profondément à l’OS sont nombreux, plus le sujet principal passe d’une distribution qui a l’air simple à la question de savoir si l’on peut installer, mettre à jour et désinstaller correctement.

6.3 Par utilisateur ou à l’échelle de la machine ?

Avancer en laissant ce point flou finit toujours par créer des frictions plus tard.

• Pencher vers l’utilisateur
  • ClickOnce
  • xcopy
  • Une partie de MSIX
• Pencher vers la machine
  • MSI
  • MSIX si les conditions s’y prêtent

« On veut installer sans droits administrateur » et « on veut que tous les utilisateurs utilisent l’application depuis le même emplacement » ne sont pas la même chose.

6.4 Fréquence de mise à jour et responsabilité d’exploitation

Vu sous l’angle de la cadence de mise à jour, grosso modo :

• Mises à jour trimestrielles à mensuelles : MSI suffit largement
• Mises à jour mensuelles à hebdomadaires : MSIX / ClickOnce sont bien plus confortables
• Mises à jour hebdomadaires à quotidiennes : des raisons d’envisager un updater personnalisé apparaissent
• Les mises à jour manuelles conviennent / le côté déploiement les contrôle : xcopy suffit

Une méthode de distribution relève autant de la sélection technologique que de la conception d’exploitation.

6.5 Distribution en environnement isolé et hors ligne

En environnement isolé, la simplicité l’emporte souvent sur une mise à jour automatique élégante.

• xcopy est solide
• MSI est également solide
• ClickOnce fonctionne aussi via des partages de fichiers ou des supports amovibles
• MSIX peut aussi fonctionner selon la façon dont on utilise App Installer

Mais si l’on met à jour fréquemment en environnement isolé, tant qu’on n’a pas aussi décidé « qui dépose la nouvelle version, où, et comment les anciennes versions sont conservées », l’exploitation a tendance à s’effondrer, quelle que soit la méthode choisie.

7. Les six dernières questions en cas d’hésitation

1. L’application doit-elle servir uniquement à l’utilisateur courant, ou doit-elle être installée à l’échelle de la machine ?
2. Y a-t-il des services / pilotes / shell extensions / un enregistrement COM ?
3. Va-t-on utiliser des fonctionnalités Windows nécessitant la package identity ?
4. Veut-on une installation réservée aux utilisateurs standards ?
5. La cadence de mise à jour est-elle mensuelle, hebdomadaire, ou plus élevée ?
6. L’environnement cible est-il isolé, et les versions d’OS sont-elles homogènes ?

Répondre à ces six questions suffit généralement à révéler le point d’atterrissage.

• 2 est « oui » → partir du côté MSI
• 3 est « oui » → envisager MSIX en premier
• 1 est l’utilisateur courant, 4 est « oui », et c’est une application de bureau .NET → ClickOnce est un candidat solide
• 4 est « oui », 2 est « non », et une exploitation « déposer et exécuter » suffit → xcopy est un candidat solide
• 5 est élevé et l’on veut porter soi-même l’UX de mise à jour comme partie de la valeur du produit → placer un updater personnalisé sur la liste de comparaison

8. Résumé

La distribution d’applications Windows se résume largement à cette phrase :

Décider séparément comment faire fonctionner l’installation initiale et qui porte la responsabilité de faire tourner les mises à jour continues.

Sur cette base, les jugements pratiques grossiers sont les suivants.

• MSI : applications de bureau traditionnelles qui vont profondément dans l’OS
• MSIX : applications qui veulent la package identity et le modern packaging / les mises à jour modernes
• ClickOnce : distribuer et mettre à jour facilement des applications métier .NET par utilisateur
• xcopy : outils autonomes pour lesquels déposer les fichiers suffit
• Updater personnalisé : produits dont l’équipe est prête à concevoir et exploiter elle-même les mises à jour

Et le plus important est ceci.

• S’il y a pilote / shell extension / service, la méthode de distribution se décide par l’approche d’intégration à l’OS, pas par l’apparence finale
• Si la package identity est nécessaire, MSIX pèse lourd
• Un updater personnalisé est le dernier recours, pas le premier choix
• En environnement isolé, la simplicité l’emporte souvent sur l’ingéniosité

En cas d’hésitation, fixer d’abord ne serait-ce que ces trois points — utilisateur ou machine, ce qui s’enregistre auprès de l’OS, et quelle est la fréquence des mises à jour — fait déjà avancer la discussion très loin.

9. Références

• Microsoft Learn, Windows Installer
• Microsoft Learn, What is MSIX?
• Microsoft Learn, Packaging overview for Windows apps
• Microsoft Learn, MSIX features and supported platforms
• Microsoft Learn, Support legacy context menus for packaged apps
• Microsoft Learn, App Installer file overview
• Microsoft Learn, Prepare to package a desktop application
• Microsoft Learn, Know your installer
• Microsoft Learn, Convert an installer that includes services
• Microsoft Learn, ClickOnce deployment and security
• Microsoft Learn, Manage updates for a ClickOnce application
• Microsoft Learn, Choosing a ClickOnce deployment strategy
• Microsoft Learn, ClickOnce cache overview
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle méthode de distribution Windows choisir pour une application avec des services ou un enregistrement COM ?

Commencez à réfléchir à partir de MSI. Quand une application s'installe à l'échelle de la machine, enregistre des services Windows ou des composants COM, a besoin d'associations de fichiers, ou doit installer des prérequis, MSI permet d'exprimer « comment l'application a été installée dans l'OS » selon les usages propres à Windows, ce qui limite les accidents. Ses faiblesses sont que l'authoring est discrètement difficile, qu'une conception négligée des upgrades et des patches fait mal plus tard, et que l'UX de mise à jour devient lourde pour des produits mis à jour fréquemment.

Qu'est-ce qui ne convient pas au packaging MSIX ?

Quatre points sont plus sûrs à vérifier avant de s'engager sur MSIX : les pilotes, les shell extensions in-process, les anciennes hypothèses Win32 non restreintes, et les configurations où l'on ne veut pas de package identity. Sur Windows 11 21H2 et versions ultérieures, MSIX peut enregistrer des legacy context menu handlers et des éléments similaires, mais les déclarations du manifeste et les conditions de version d'OS ciblée doivent être vérifiées. MSIX brille quand on peut supposer Windows 10/11 et qu'on veut une installation et une désinstallation propres, des mises à jour fréquentes, et la package identity.

ClickOnce vaut-il encore le coup pour des applications internes d'entreprise ?

Oui. ClickOnce reste remarquablement solide quand on veut distribuer une application .NET de bureau interne par utilisateur, rapidement, avec une mise à jour automatique intégrée, et une installation par des utilisateurs standards sans droits administrateur. Ce qu'il ne faut pas en attendre, c'est la prise en charge de produits qui touchent profondément l'OS, l'installation à l'échelle de la machine, ou le rôle proche d'un installateur qui regroupe plusieurs prérequis.

Quand une équipe doit-elle développer un updater personnalisé plutôt que d'utiliser les mises à jour intégrées ?

Traitez un updater personnalisé comme quelque chose que l'on ajoute lorsqu'une méthode de distribution existante ne peut pas répondre aux exigences de mise à jour, pas comme un premier choix. Cela devient pertinent avec une fréquence de mise à jour élevée, des canaux comme stable, beta et preview, des pourcentages de déploiement progressif, un contrôle fin des téléchargements en arrière-plan et des fenêtres de maintenance, ou une télémétrie de mise à jour propre à l'équipe. En contrepartie, on assume la vérification de signature, les manifestes de diffusion, les tentatives et reprises, le rollback, la récupération après une mise à jour cassée, et la mise à jour de l'updater lui-même — ce qui augmente, ce n'est pas la liberté, mais la responsabilité.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.