Qu'est-ce que ClickOnce ? - Fonctionnement, mises à jour, et les cas où c'est adapté ou non, du point de vue de la pratique

Dès qu’il est question de distribuer des applications de bureau .NET sous Windows, un nom revient discrètement mais régulièrement dans l’ombre de MSI et MSIX : ClickOnce.

Mais si l’on tranche sans réfléchir vers l’une de ces deux positions :

• c’est une vieille technologie, donc on ne l’utilise plus
• ou à l’inverse, ça a l’air simple, donc ClickOnce peut tout faire

on se trompe généralement.

ClickOnce n’est pas un installateur universel capable de tout faire. En revanche, pour distribuer une application métier .NET interne à des utilisateurs standard, mises à jour comprises, à faible coût d’exploitation, il reste aujourd’hui une option très solide.

Cet article présente ce qu’est ClickOnce, comment il fonctionne, ce qu’il fait bien et où il montre ses limites, du point de vue de la pratique, avec de nombreux diagrammes Mermaid. Le contenu s’appuie principalement sur les informations de Microsoft Learn vérifiables en avril 2026.

Les diagrammes sont conceptuels. Dans les environnements Markdown compatibles avec Mermaid, ils s’affichent sous forme de figures.

Table des matières

1. La conclusion d’abord
2. Qu’est-ce que ClickOnce ?
3. Ce qui compose ClickOnce
4. Du déploiement au lancement
5. Le mécanisme de mise à jour
6. Les points forts de ClickOnce
7. Les cas où c’est adapté
8. Les cas où ce n’est pas adapté
9. Pièges fréquents en pratique
10. Résumé
11. Articles connexes
12. Références

1. La conclusion d’abord

En une phrase, ClickOnce est une technologie de déploiement permettant de distribuer facilement des applications de bureau .NET sous Windows, par utilisateur, avec les mises à jour automatiques incluses.

Il convient à des cas comme ceux-ci.

• Applications métier internes en WinForms / WPF
• On veut que des utilisateurs standard puissent installer l’application
• Une distribution per-user suffit
• On veut une mise à jour built-in
• Un site web ou un partage de fichiers suffit comme canal de distribution

À l’inverse, avec des exigences comme celles-ci, il vaut mieux regarder d’autres méthodes dès le départ.

• Installation machine-wide pour tous les utilisateurs
• Service Windows, pilote, extension shell in-process, enregistrement COM poussé
• Une package identity est nécessaire
• On veut maîtriser les canaux de mise à jour, le déploiement progressif et une UX de rollback personnalisée
• L’installateur porte une responsabilité lourde, profondément ancrée dans l’OS

En résumé, ClickOnce est une méthode forte pour une distribution simple et des mises à jour simples, mais peu adaptée aux projets à intégration OS lourde.

D’abord, la position en un coup d’œil

flowchart TD
    A["Vouloir distribuer une application Windows"]
    B{"Y a-t-il une exigence d'intégration profonde à l'OS ?"}
    C["Partir de MSI / MSIX"]
    D{"S'agit-il d'une application de bureau .NET Windows<br/>pour laquelle une distribution per-user suffit ?"}
    E{"Veut-on distribuer à des utilisateurs standard ?"}
    F{"La mise à jour built-in suffit-elle ?"}
    G["ClickOnce est un candidat solide"]
    H["Comparer aussi xcopy / un updater personnalisé"]

    A --> B
    B -- Oui --> C
    B -- Non --> D
    D -- Non --> H
    D -- Oui --> E
    E -- Non --> H
    E -- Oui --> F
    F -- Oui --> G
    F -- Non --> H

2. Qu’est-ce que ClickOnce ?

ClickOnce est une technologie de déploiement d’applications Windows de Microsoft. Officiellement, elle est décrite comme une technologie de déploiement pour les applications basées sur Windows, pouvant être installées et exécutées avec une intervention minimale de l’utilisateur, et capables de se mettre à jour elles-mêmes.

Ce qui compte ici, c’est de ne pas voir ClickOnce comme un simple « type d’installateur ».

Dans les faits, ClickOnce est un modèle de déploiement qui prend en charge, ensemble, les points suivants.

• Quelle version distribuer
• Quels fichiers appartiennent à cette version
• Comment détecter les mises à jour
• D’où récupérer les mises à jour
• Comment conserver l’application dans un emplacement sûr, propre à chaque utilisateur
• Comment vérifier l’intégrité au lancement

Le cœur de ClickOnce n’est pas setup.exe en lui-même : il est plus juste de le voir comme un mécanisme qui gère ensemble la distribution, la mise à jour et le cache, centré sur des manifestes.

Même avec le .NET actuel, ClickOnce reste un candidat tout à fait normal. Dans Visual Studio, le Publish tool est utilisé pour .NET Core 3.1 et .NET 5 et versions ultérieures, et pour manipuler les manifestes manuellement, on utilise dotnet-mage.exe.

Les responsabilités dont ClickOnce s’occupe

flowchart LR
    CO["ClickOnce"]
    V["Quelle version distribuer"]
    U["D'où récupérer les mises à jour"]
    S["Conserver dans un emplacement sûr, par utilisateur"]
    I["Vérifier l'intégrité et lancer"]

    CO --> V
    CO --> U
    CO --> S
    CO --> I

3. Ce qui compose ClickOnce

Pour comprendre le fonctionnement de ClickOnce, le plus rapide est de bien saisir ces quatre éléments.

Le cœur du dispositif, ce sont les deux types de manifestes.

• Le manifeste de déploiement exprime « quelle version est actuellement la bonne réponse pour cette application »
• Le manifeste d’application exprime « ce que contient cette version »

Autrement dit, la décision de mise à jour de ClickOnce part d’abord du manifeste de déploiement, et c’est le manifeste d’application qui détermine ce qui est réellement récupéré.

Comment les quatre éléments s’articulent

flowchart LR
    Setup["setup.exe<br/>facultatif<br/>vérification / installation des prérequis"]
    Deploy["Manifeste de déploiement (.application)<br/>quelle version distribuer<br/>emplacement / conditions de mise à jour"]
    App["Manifeste d'application (*.exe.manifest)<br/>contenu de cette version<br/>liste des fichiers / hachages / point d'entrée"]
    Files["Fichiers de l'application<br/>exe / dll / config / data"]
    Cache["Cache ClickOnce<br/>per-user / per-application"]

    Setup --> Deploy
    Deploy --> App
    App --> Files
    Files --> Cache

setup.exe est un auxiliaire, pas le rôle principal

setup.exe attire souvent l’attention, mais ce n’est pas le rôle principal de ClickOnce. C’est un auxiliaire qui vérifie et installe les prérequis.

Par exemple, lorsque le bon runtime .NET ou des composants redistribuables supplémentaires sont nécessaires, setup.exe les met d’abord en place, et ce n’est qu’ensuite que le déploiement ClickOnce proprement dit commence.

4. Du déploiement au lancement

En simplifiant volontairement pour un usage pratique, le déroulement de ClickOnce ressemble à ceci.

1. L’utilisateur ouvre setup.exe ou le fichier .application depuis une page web ou un partage de fichiers
2. Dans les configurations utilisant setup.exe, les prérequis sont vérifiés et les éléments manquants sont installés
3. ClickOnce lit le manifeste de déploiement
4. Il lit le manifeste d’application vers lequel pointe le manifeste de déploiement
5. Il récupère les fichiers nécessaires et les place dans le cache ClickOnce propre à l’utilisateur
6. Dans les configurations avec disponibilité hors ligne, il enregistre l’application dans le menu Démarrer / la liste des applications
7. Ensuite, l’application se lance sous la gestion de ClickOnce

Le point important est que ce n’est pas l’état d’esprit consistant à placer des fichiers dans Program Files comme le ferait un installateur ordinaire.

Les applications ClickOnce vont dans une zone de cache sécurisée, propre à chaque utilisateur, isolée par application et par utilisateur. C’est l’une des caractéristiques majeures de ClickOnce.

De l’installation au premier lancement

sequenceDiagram
    participant U as Utilisateur
    participant P as setup.exe / .application
    participant D as Manifeste de déploiement
    participant A as Manifeste d'application
    participant C as Cache ClickOnce
    participant X as Fichiers de l'application

    U->>P: Ouvre
    Note over U,P: Dans les configurations utilisant setup.exe,<br/>la vérification des prérequis intervient d'abord
    P->>D: Récupère et lit
    D->>A: Référence la version cible
    A->>C: Récupère les fichiers nécessaires, vérifie l'intégrité
    C->>X: Place et lance

Uniquement en ligne ou disponible hors ligne

ClickOnce propose globalement deux modes de présentation.

• Uniquement en ligne : s’exécute depuis l’emplacement de publication. La sensation d’installation permanente est faible
• Disponible hors ligne : installée sur la machine de l’utilisateur, et lançable depuis le menu Démarrer

Pour les applications métier internes, en pratique, c’est la disponibilité hors ligne qui est le choix courant.

flowchart LR
    subgraph Online[Uniquement en ligne]
        O1["Se lance depuis l'emplacement de publication"]
        O2["Sensation d'installation permanente faible"]
        O3["Suppose généralement un réseau"]
        O1 --> O2 --> O3
    end

    subgraph Offline[Disponible hors ligne]
        F1["Installée dans l'espace utilisateur"]
        F2["Enregistrée dans le menu Démarrer"]
        F3["Lancement en local"]
        F4["Vérifie les mises à jour au moment défini"]
        F1 --> F2 --> F3 --> F4
    end

5. Le mécanisme de mise à jour

La force la plus évidente de ClickOnce reste, après tout, que le modèle de mise à jour est built-in.

La décision de mise à jour part du manifeste de déploiement

Une application ClickOnce lit le manifeste de déploiement et vérifie :

• s’il existe une nouvelle version
• si la mise à jour est obligatoire
• où l’obtenir

Une fois la mise à jour lancée, ClickOnce utilise le file patching pour éviter les téléchargements redondants. Comme modèle mental de travail, il est plus simple de se dire que ClickOnce compare le manifeste d’application de la nouvelle version à la version actuelle, et ne récupère que les fichiers qui ont changé.

Pour réfléchir à la vérification des mises à jour, on peut s’organiser autour de trois schémas.

• Vérifier avant le démarrage
• Vérifier après le démarrage
• Proposer une UI « vérifier les mises à jour » dans l’application

Cependant, les API disponibles et l’UI de configuration diffèrent entre .NET Framework et .NET 5+. Il ne faut pas se lancer dans l’implémentation en s’appuyant uniquement sur le souvenir d’anciens articles sur ClickOnce.

Le déroulement de la mise à jour

flowchart TD
    Start["Lancement de l'application"]
    Check["Vérifie le manifeste de déploiement"]
    New{"Y a-t-il une nouvelle version ?"}
    Run["Lance telle quelle"]
    Get["Récupère le manifeste d'application de la nouvelle version"]
    Compare["Compare les signatures / hachages des fichiers"]
    Download["Récupère ce qui a changé"]
    Switch["Constitue la nouvelle version et bascule"]
    Restart["Si nécessaire, exécute la nouvelle version après redémarrage"]

    Start --> Check --> New
    New -- Non --> Run
    New -- Oui --> Get --> Compare --> Download --> Switch --> Restart

Il est également utile de garder à l’esprit qu’en l’absence de connexion réseau, l’application s’exécute simplement sans vérification de mise à jour — le savoir évite la confusion en pratique.

Les versions sont conservées de manière isolée

ClickOnce est moins « écraser sur place les fichiers actuels » que « constituer correctement la nouvelle version, puis basculer dessus ».

De plus, le cache ClickOnce conserve séparément la version actuelle et la version précédente. C’est l’une des raisons pour lesquelles il pollue peu l’environnement et évite facilement les collisions de versions.

flowchart TB
    subgraph UA[Cache ClickOnce de l'utilisateur A]
        APrev["Version précédente"]
        ACur["Version actuelle"]
        AData["Paramètres / données"]
    end

    subgraph UB[Cache ClickOnce de l'utilisateur B]
        BPrev["Version précédente"]
        BCur["Version actuelle"]
        BData["Paramètres / données"]
    end

    APrev --> ACur
    AData --> ACur
    BPrev --> BCur
    BData --> BCur

Deux points sont à retenir ici.

• Difficile à mélanger avec d’autres utilisateurs
• Difficile à faire entrer en collision avec d’autres versions

Cette structure explique en grande partie pourquoi ClickOnce évite facilement le fameux DLL Hell.

6. Les points forts de ClickOnce

Les qualités de ClickOnce ne se résument pas à « facile à distribuer ». Ce qui paie en pratique, c’est à peu près ceci.

6.1 Facile à distribuer à des utilisateurs standard

ClickOnce s’accorde bien avec une distribution per-user, et le grand avantage est qu’il est facile à installer sans droits d’administrateur.

Une situation courante avec les applications métier internes est la suivante :

• les utilisateurs sont des utilisateurs standard
• on ne veut pas déposer une demande d’installation auprès du service IT à chaque fois
• mais on ne veut pas non plus arrêter les mises à jour

Dans ces conditions, ClickOnce est particulièrement fort. Sa prémisse — « s’installer dans l’espace de chaque utilisateur, en toute sécurité, mises à jour incluses » — colle dès le départ.

6.2 Pas besoin d’implémenter soi-même la mise à jour

Construire une mise à jour automatique à partir de zéro implique plus de travail qu’il n’y paraît.

• Détection de nouvelle version
• Téléchargement
• Vérification d’intégrité
• Bascule depuis l’ancienne version
• Récupération en cas d’échec
• UI de mise à jour
• Gestion de l’updater lui-même

ClickOnce prend en charge une grande partie de tout cela avec son modèle existant.

flowchart LR
    subgraph Custom[Responsabilités avec un updater personnalisé]
        C1["Détection de nouvelle version"]
        C2["Téléchargement"]
        C3["Vérification d'intégrité"]
        C4["Bascule"]
        C5["Récupération en cas d'échec"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[Responsabilités que l'on peut déléguer à ClickOnce]
        K1["Détection de nouvelle version"]
        K2["Récupération et vérification"]
        K3["Bascule"]
        K1 --> K2 --> K3
    end

Bien sûr, on ne peut pas tout faire librement. Mais les « mises à jour suffisantes » dont ont besoin les applications internes sont largement couvertes.

6.3 Les applications entrent rarement en conflit entre elles

Les applications ClickOnce sont isolées par application, par utilisateur et par version.

Cela rend difficiles les incidents classiques comme :

• les conflits de version des composants partagés
• l’écrasement d’une DLL qui casse une autre application
• la pollution de l’environnement par des remplacements manuels

6.4 Facile à publier depuis Visual Studio

ClickOnce s’accorde bien avec la fonctionnalité de publication de Visual Studio, et la courte distance jusqu’à la distribution est un autre avantage.

Avant d’entrer dans une autre discipline difficile comme l’authoring MSI, il est facile d’établir la boucle suivante :

• publier d’abord
• distribuer d’abord
• faire tourner les mises à jour d’abord
• obtenir d’abord les retours du terrain

6.5 Le report des paramètres reste, lui aussi, relativement simple

Si l’on utilise le fournisseur de paramètres d’application par défaut, ClickOnce dispose d’un mécanisme pour fusionner les paramètres de la version précédente dans la nouvelle version lors de la mise à jour.

Attention toutefois : cela suppose le fournisseur de paramètres par défaut. Avec un stockage de paramètres personnalisé, un fournisseur personnalisé, ou un emplacement de sauvegarde modifié, cela ne fonctionne évidemment pas tel quel.

7. Les cas où c’est adapté

ClickOnce convient particulièrement à des projets comme ceux-ci, dans l’ensemble.

Voici des exemples concrets où l’adéquation en pratique est bonne.

• Applications internes de saisie métier
• Outils de bureau pour devis, commandes, gestion des stocks, etc.
• Applications auxiliaires pour la configuration d’équipements
• Clients internes distribués aux agences, usines et back-offices
• Applications qui veulent des mises à jour, sans justifier la construction d’un updater dédié

Pour des applications comme celles-ci, rendre simples la distribution et la mise à jour est en soi la valeur recherchée. ClickOnce répond directement à cette valeur.

Un arbre de décision pour évaluer l’adéquation

flowchart TD
    S["Organiser les besoins"]
    Q1{"S'agit-il d'une application de bureau .NET<br/>comme WinForms / WPF ?"}
    Q2{"Une distribution per-user suffit-elle ?"}
    Q3{"Veut-on l'installer pour des utilisateurs standard ?"}
    Q4{"Peut-on distribuer via le Web / un partage de fichiers ?"}
    Q5{"Est-il acceptable de ne pas trop travailler l'UX de mise à jour ?"}
    G["ClickOnce est un candidat très solide"]
    O["Comparer d'autres méthodes"]

    S --> Q1
    Q1 -- Non --> O
    Q1 -- Oui --> Q2
    Q2 -- Non --> O
    Q2 -- Oui --> Q3
    Q3 -- Non --> O
    Q3 -- Oui --> Q4
    Q4 -- Non --> O
    Q4 -- Oui --> Q5
    Q5 -- Oui --> G
    Q5 -- Non --> O

8. Les cas où ce n’est pas adapté

À l’inverse, les situations dans lesquelles il ne faut pas forcer l’usage de ClickOnce sont tout aussi claires.

8.1 Une installation machine-wide est nécessaire

ClickOnce est fondamentalement per-user.

• On veut installer pour tous les utilisateurs en commun
• On veut installer avec Program Files comme hypothèse
• On veut déployer et gérer au niveau de la machine entière

Dans ce cas, MSI et consorts sont plus naturels que ClickOnce.

8.2 Service Windows / pilote / extension shell / enregistrement COM poussé

Il s’agit là de sujets qui touchent profondément l’OS.

• Service Windows
• Pilote
• Extension shell in-process
• Configurations qui supposent un enregistrement COM systématique

Dès que l’on entre dans ce territoire, on sort de la vision du monde « distribution légère » de ClickOnce.

8.3 On veut une package identity

L’une des raisons de choisir MSIX est le besoin d’obtenir une package identity.

ClickOnce ne va pas dans cette direction. Si ce que l’on veut, c’est du packaging moderne ou des fonctionnalités Windows qui supposent une package identity, mieux vaut privilégier MSIX.

8.4 On veut maîtriser l’UX de mise à jour et les canaux de diffusion en tant que produit

Par exemple :

• des canaux stable / beta / preview
• un déploiement progressif
• un ajustement du taux de déploiement en observant la télémétrie
• un contrôle fin des téléchargements en arrière-plan
• une stratégie de rollback personnalisée
• un cycle de vie complexe pour l’updater lui-même

Dès que l’on veut tout cela, les mises à jour built-in de ClickOnce ne suffisent plus.

8.5 Des outils où « juste déposer les fichiers » suffit

À l’inverse, certains cas peuvent être encore plus simples.

• Il suffit de déposer le dossier pour que ça fonctionne
• Un remplacement manuel suffit pour les mises à jour
• On le transmet par clé USB
• Dans un réseau fermé où la simplicité prime avant tout

Dans ce cas, la distribution xcopy peut impliquer moins de friction.

Quelles exigences orientent vers une autre méthode

flowchart LR
    A1["Installation pour tous les utilisateurs"] --> B1["MSI / parfois MSIX"]
    A2["service / pilote / extension shell / COM poussé"] --> B2["MSI / installateur dédié"]
    A3["Package identity requise"] --> B3["MSIX"]
    A4["Déploiement progressif / canaux / UX personnalisée"] --> B4["Updater personnalisé"]
    A5["Juste déposer les fichiers suffit"] --> B5["xcopy"]

ClickOnce n’est tout-puissant ni vers le haut ni vers le bas ; c’est en revanche une méthode forte sur les projets d’une complexité juste équilibrée.

9. Pièges fréquents en pratique

ClickOnce est pratique, mais un usage négligent conduit à quelques déconvenues. Voici en particulier les points à connaître à l’avance.

9.1 Ne pas le voir comme un « installateur ordinaire »

ClickOnce n’est pas un modèle où les fichiers sont placés à un emplacement d’installation fixe, sous une forme que l’humain gère directement.

Les fichiers réels vont dans un cache géré par ClickOnce, isolé par version. Cela ne s’accorde donc pas bien avec :

• une exploitation qui suppose un chemin EXE fixe
• une exploitation où l’on écrase directement les fichiers à la main
• une exploitation où l’humain contrôle l’emplacement réel des fichiers

ClickOnce est une méthode où ce n’est pas l’humain qui gère le placement des fichiers, mais où l’état de déploiement est géré par des manifestes.

9.2 Beaucoup d’anciens articles sur ClickOnce supposent le .NET Framework

Attention à ce point.

Même aujourd’hui, les résultats de recherche regorgent d’articles sur ClickOnce datant de l’époque du .NET Framework. Or, sur le .NET actuel, la situation diffère un peu.

• Sur .NET Core 3.1 / .NET 5 / .NET 6, l’API ApplicationDeployment ne peut pas être utilisée telle quelle
• À partir de .NET 7, certaines propriétés de déploiement peuvent être lues via des variables d’environnement
• Pour manipuler les manifestes manuellement, dotnet-mage.exe est l’outil de référence
• Côté Visual Studio également, des indications supposant l’ancien Publish Wizard peuvent ne plus s’appliquer telles quelles

Même si l’on a l’impression de « déjà connaître ClickOnce », il est plus sûr de ne pas se lancer dans l’implémentation en se fiant à d’anciens souvenirs.

9.3 Traiter les prérequis séparément

ClickOnce lui-même est un modèle de déploiement, mais l’application peut avoir besoin de prérequis pour fonctionner.

• Un runtime pris en charge
• Des composants redistribuables supplémentaires
• D’autres dépendances

C’est là qu’intervient une configuration bootstrapper utilisant setup.exe. Rester flou sur ce point produit le classique « on a distribué avec ClickOnce, mais ça ne fonctionne pas ».

9.4 Le report des paramètres dépend de « quoi » et « comment » on les enregistre

Avec le fournisseur de paramètres par défaut, la migration des paramètres lors de la mise à jour reste relativement simple. En revanche, avec :

• un fournisseur de paramètres personnalisé
• une hypothèse de roaming
• un emplacement de sauvegarde des paramètres modifié soi-même
• une structure de paramètres fortement modifiée entre les versions

cela ne fonctionne évidemment pas tel quel.

9.5 Ne pas prendre à la légère la signature et le chemin de mise à jour

ClickOnce dispose d’un mécanisme de distribution et de mise à jour, mais cela ne fait pas disparaître pour autant la responsabilité en matière de sécurité.

En particulier en production, il vaut mieux clarifier dès le départ :

• comment gérer le certificat de signature
• comment afficher le nom de l’éditeur
• comment gérer la source des mises à jour
• comment séparer l’auto-signature de test de la signature de production

flowchart TD
    Cert["Certificat de signature de code"]
    AppMan["Manifeste d'application"]
    DepMan["Manifeste de déploiement"]
    Verify["Vérifié côté client"]
    Run["Mise à jour / exécution"]
    Tamper["Manifeste altéré"]
    Stop["Arrêt en cas d'échec de vérification"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. échec de vérification .-> Stop

« Il y a une mise à jour automatique = c’est rassurant » n’est pas la conclusion à tirer : ce que l’on décide de faire confiance, et comment cette confiance est maintenue, doit être réfléchi à part.

9.6 Si l’on déplace l’emplacement de publication, revoir deploymentProvider

Ce point est discret, mais il pose de sérieux problèmes en pratique.

Une application ClickOnce déjà installée va chercher les mises à jour à l’emplacement pointé par deploymentProvider dans le manifeste de déploiement. Autrement dit, même si l’on copie l’intégralité du dossier de publication vers une autre URL ou un autre partage, sans mettre à jour deploymentProvider, les clients peuvent continuer à regarder l’emplacement d’origine.

Et si l’on modifie un manifeste à la main, il faut le re-signer.

Le flux opérationnel, de la publication à la prise en compte de la mise à jour

flowchart TD
    Build["Build"]
    AppManifest["Génère le nouveau manifeste d'application"]
    SignApp["Signe le manifeste d'application"]
    UpdateDep["Met à jour le manifeste de déploiement vers la nouvelle version"]
    SignDep["Signe le manifeste de déploiement"]
    Publish["Dépose à l'emplacement de publication"]
    Client["Le client détecte la mise à jour"]

    Build --> AppManifest --> SignApp --> UpdateDep --> SignDep --> Publish --> Client

En définitive, ce qui compte dans l’exploitation de ClickOnce, ce n’est pas tant le fait d’avoir placé les fichiers que la cohérence entre les manifestes et les signatures.

10. Résumé

En une phrase, ClickOnce est

un mécanisme pour distribuer des applications de bureau .NET sous Windows, facilement par utilisateur, avec des mises à jour prises en charge à faible coût.

Ses points forts sont principalement les suivants.

• Facile à distribuer à des utilisateurs standard
• Un modèle de mise à jour built-in
• Des mises à jour faciles, limitées aux fichiers modifiés
• Une isolation facile des applications et des versions
• Une publication facile depuis Visual Studio
• Une bonne adéquation avec les applications métier internes

Cependant, ce n’est pas une solution universelle.

• Installation machine-wide
• Service / pilote / extension shell
• Enregistrement COM poussé
• Package identity
• Canaux personnalisés ou déploiement progressif
• Travailler l’UX de mise à jour comme une valeur produit

S’il existe des exigences de ce type, il faut penser du côté de MSI / MSIX / d’un updater personnalisé, plutôt que de ClickOnce.

ClickOnce n’est pas un installateur simplifié qui convient à tout, mais sur les projets où il est adapté, il reste aujourd’hui encore très solide.

Si ce que l’on veut distribuer est :

• une application métier .NET Windows,
• pour laquelle une installation par utilisateur suffit,
• destinée à des utilisateurs standard,
• sans vouloir gérer soi-même les mises à jour,

alors ClickOnce figure parmi les candidats très sérieux.

11. Articles connexes

• Comment choisir une méthode de distribution pour une application Windows - Tableau de décision MSI / MSIX / ClickOnce / xcopy / updater personnalisé
• Votre outil de mise à jour automatique est une frontière de confiance - Pourquoi HTTPS seul ne suffit pas
• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception

Sujets connexes

Pages de sujets proches de cette thématique. À partir de cet article, vous pouvez accéder aux services et articles connexes.

Sujets techniques Windows

Un point d’entrée qui rassemble les sujets techniques sur le développement Windows, l’investigation de bugs et la réutilisation des actifs existants.

Services liés à ce thème

Cet article se rattache aux pages de services suivantes. Merci d’entrer par celle qui vous semble la plus proche.

Développement d’applications Windows

Pour les applications métier internes, les outils de configuration d’équipements ou les remaniements de logiciels existants, savoir lequel de ClickOnce / MSI / MSIX / xcopy présente le moins de friction change considérablement selon la mise au point réalisée avant l’implémentation.

Voir le service Nous contacter

Conseil technique et revue de conception

Des questions comme « ClickOnce suffit-il ? », « faut-il se tourner vers MSIX ou MSI ? » ou « faut-il se contenter de la mise à jour built-in ou la gérer soi-même ? » deviennent plus faciles à trancher lorsqu’elles sont clarifiées avant l’implémentation.

Voir le service Nous contacter

Profil de l’auteur

Go Komura

Représentant, KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’investigation de bugs, avec une force particulière sur les projets comportant des actifs existants et les enquêtes sur des pannes dont la cause est difficile à identifier.

Voir le profil Nous contacter

12. Références

• Microsoft Learn - ClickOnce deployment and security
• Microsoft Learn - ClickOnce for .NET on Windows
• Microsoft Learn - How ClickOnce performs application updates
• Microsoft Learn - Choosing a ClickOnce update strategy
• Microsoft Learn - ClickOnce deployment manifest
• Microsoft Learn - ClickOnce application manifest
• Microsoft Learn - ClickOnce cache overview
• Microsoft Learn - ClickOnce and application settings
• Microsoft Learn - Install prerequisites with a ClickOnce application
• Microsoft Learn - ClickOnce and Authenticode
• Microsoft Learn - Security, versioning, and manifest issues in ClickOnce deployments

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.

Qu'est-ce que ClickOnce ?

ClickOnce est une technologie de déploiement permettant de distribuer facilement des applications de bureau .NET sous Windows, par utilisateur, avec les mises à jour automatiques incluses. Officiellement, il s'agit d'une technologie de déploiement pour les applications basées sur Windows qui peuvent être installées et exécutées avec une intervention minimale de l'utilisateur, et qui se mettent à jour elles-mêmes. Dans les faits, c'est un modèle de déploiement centré sur des manifestes qui prend en charge à la fois la distribution, la mise à jour et la gestion du cache : l'application est conservée dans une zone de cache sécurisée propre à chaque utilisateur, isolée par application, par utilisateur et par version.

Peut-on encore utiliser ClickOnce aujourd'hui ? N'est-ce pas une technologie dépassée ?

Même avec le .NET actuel, ClickOnce reste un candidat tout à fait normal. Dans Visual Studio, le Publish tool est utilisé pour .NET Core 3.1 et .NET 5 et versions ultérieures, et pour manipuler les manifestes manuellement, on utilise dotnet-mage.exe. Attention toutefois : la situation diffère de l'époque du .NET Framework. Sur .NET Core 3.1 / .NET 5 / .NET 6, l'API ApplicationDeployment ne peut pas être utilisée telle quelle, et à partir de .NET 7, certaines propriétés de déploiement se lisent via des variables d'environnement. Il est plus sûr de ne pas se lancer dans l'implémentation en se fiant uniquement au souvenir d'anciens articles.

À quel type d'application ClickOnce est-il adapté ?

Il est particulièrement adapté aux applications métier internes en WinForms / WPF, lorsqu'on souhaite les distribuer à des utilisateurs standard sans droits d'administrateur, qu'une distribution per-user suffit, et qu'on veut disposer d'une mise à jour built-in. Un site web ou un partage de fichiers suffit alors comme canal de distribution. À l'inverse, pour une installation machine-wide destinée à tous les utilisateurs, pour un service Windows, un pilote, une extension shell, un enregistrement COM poussé, une exigence de package identity, ou pour maîtriser des canaux de mise à jour et un déploiement progressif, ClickOnce n'est pas adapté : il faut alors envisager MSI, MSIX ou un updater personnalisé.

Comment fonctionne la mise à jour automatique de ClickOnce ?

La détection des mises à jour part du manifeste de déploiement (.application). L'application lit ce manifeste pour vérifier s'il existe une nouvelle version, si la mise à jour est obligatoire, et où l'obtenir. Lors de la mise à jour, ClickOnce utilise le file patching : il compare le manifeste d'application de la nouvelle version à la version actuelle et ne récupère que les fichiers modifiés, ce qui évite les téléchargements redondants. Le cache ClickOnce conserve séparément la version actuelle et la version précédente ; l'idée est de constituer correctement la nouvelle version avant de basculer dessus. En l'absence de connexion réseau, l'application s'exécute simplement sans vérification de mise à jour.

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.