Discussion :

[T`lash]

Bonjour,

On voit de plus en plus (notamment pour le jeu en ligne) d'application lancée par un updater.
En clair, on ne lance pas directement l'appli en elle-même, mais un petit programme qui va d'abord vérifier en contactant un serveur distant si tous les composants sont à jour et télécharger puis installer ce qui doit l'être avant d'appeler le programme principal de l'appli.

Cette partie là ne me pose pas de soucis particulier.

Par contre, le fonctionnement qui m'intéresse de comprendre, c'est dans le cas où c'est l'updater lui-même qui doit être mis à jour...
La technique généralement employée est-elle de faire télécharger par l'updater un exécutable qui installera la nouvelle version une fois le premier arrêté ? (Cas dans lequel il faut s'assurer que le premier processus soit bien stoppé avant de pouvoir lancer la copie de fichiers).
Ou existe-t-il un technique miracle qui m'est encore inconnue ?

[DonQuiche]

Un processus enfant a une vie indépendante de celle du parent. Donc l'updater détecte qu'il doit être mis à jour, la télécharge, puis crée un autre processus et se ferme. Le second processus guette la fermeture de l'updater et le met à jour, puis le relance.

[T`lash]

Un processus enfant a une vie indépendante de celle du parent. Donc l'updater détecte qu'il doit être mis à jour, la télécharge, puis crée un autre processus et se ferme. Le second processus guette la fermeture de l'updater et le met à jour, puis le relance.

Non seulement autre processus, mais également autre programme car le fichier d'où vient le code ne doit pas pouvoir être modifié tant que ce code est en train d'être exécuté.

Il faut donc que le code de mise à jour soit séparé dans 2 programmes différents. Mais si on ne veut pas du tout polluer notre programme principal avec ce code utilitaire, il faut au moins 3 programme.

Je vois bien un programme lanceur qui vérifie si un fichier du genre "updater.exe.new" existe dans le dossier de l'appli, et, le cas échéant, supprime l'ancienne version puis renomme la nouvelle avant de poursuivre. Sinon il ne fait que lancer l'updater.

L'updater lui vérifie d'abord s'il est à jour pour savoir s'il doit télécharger sa nouvelle version et redonner la main au lanceur. S'il est à jour il vérifie les versions des modules du programme principal avant de le lancer.


J'imagine que c'est la bonne marche à suivre, non ?


Par contre, il faut que lorsque l'updater redémarre le lanceur ce dernier attende la fermeture du premier avant d'initier ses opérations sur les fichiers.
Qu'existe-t-il comme mécanisme pour qu'un processus soit en attente tant que celui qui l'a appelé n'a pas libéré toutes ses ressources (y compris le fichier contenant son code, donc sa fin de vie) ?

[DonQuiche]

Mais si on ne veut pas du tout polluer notre programme principal avec ce code utilitaire, il faut au moins 3 programme.

A la rigueur tu pourrais directement télécharger un exécutable si tu veux éviter d'en avoir un de plus dans le dossier appli. Mais ça posera problème si un jour tu veux des MAJ incrémentales ou ce genre de choses.

Sinon, à partir de W7 powershell est dispo en standard, tu pourrais te contenter d'un script. Ou avant ça peut-être du VBS. Voire peut-être un bête xcopy planifié via le service de planification de Windows.

Je vois bien un programme lanceur qui vérifie si un fichier du genre "updater.exe.new" existe dans le dossier de l'appli, et, le cas échéant, supprime l'ancienne version puis renomme la nouvelle avant de poursuivre. Sinon il ne fait que lancer l'updater.

Tu veux séparer le lanceur de l'updater ? Je ne vois pas trop l'intérêt. A la rigueur sur trois exe j'aurais plutôt choisi lanceur/updater, updater de l'updater, application.

Qu'existe-t-il comme mécanisme pour qu'un processus soit en attente tant que celui qui l'a appelé n'a pas libéré toutes ses ressources (y compris le fichier contenant son code, donc sa fin de vie) ?

Je ne pense pas que ce soit la bonne approche car le fichier pourrait ne pas être libéré immédiatement par l'OS. Au final je surveillerais plutôt l'état du fichier que celui du processus, en cherchant à écrire une fois par seconde jusqu'à obtenir l'autorisation ou à expiration d'une durée maximale.

[T`lash]

Tu veux séparer le lanceur de l'updater ? Je ne vois pas trop l'intérêt. A la rigueur sur trois exe j'aurais plutôt choisi lanceur/updater, updater de l'updater, application.

j'avais penché pour la solution que j'ai détaillé plus tôt parce qu'en cas de problème lors d'une mise à jour qui corromprait l'updater il suffit de remettre la nouvelle version et le lanceur (donc l'updater de l'updater qui est tellement simple qu'il ne devrait jamais ou extrêmement rarement avoir besoin de maj) va rétablir le bon fonctionnement.

Je pars du principe que l'ordre de lancement doit être inversement proportionnel à la fréquence des mises-à-jour.

De plus, d'un point de vue logique, on met à jour, puis on redémarre, jusqu'à ce que l'ensemble de l'appli soit à jour. Les mises-à-jour du programme principal ne peuvent pas être téléchargées tant que l'updater n'est pas à la plus récente version.

Les chemins possibles seraient donc :

• Tout est déjà à jour : (1) (2) (3)
• Nouvelle version du programme principal : (1) (2) (3')
• Nouvelle version de l'updater : (1) (2) (1) (2') (3)
• Nouvelle version de l'updater et du programme principal : (1) (2) (1) (2') (3')

Je ne pense pas que ce soit la bonne approche car le fichier pourrait ne pas être libéré immédiatement par l'OS. Au final je surveillerais plutôt l'état du fichier que celui du processus, en cherchant à écrire une fois par seconde jusqu'à obtenir l'autorisation ou à expiration d'une durée maximale.

Je prends ça en note, ça m'a l'air d'être une excellente idée.

[DonQuiche]

j'avais penché pour la solution que j'ai détaillé plus tôt parce qu'en cas de problème lors d'une mise à jour qui corromprait l'updater il suffit de remettre la nouvelle version et le lanceur

C'est vrai. Par contre il te sera impossible de mettre à jour le lanceur alors que tu pourrais avoir intérêt à le changer, ce qui n'est pas le cas de l'updater de l'updater. Et puis rebelote : en cas de corruption du lanceur tu es marron, qu'il s'agisse d'un pur lanceur ou d'un lanceur/updater.

[T`lash]

C'est vrai. Par contre il te sera impossible de mettre à jour le lanceur alors que tu pourrais avoir intérêt à le changer, ce qui n'est pas le cas de l'updater de l'updater. Et puis rebelote : en cas de corruption du lanceur tu es marron, qu'il s'agisse d'un pur lanceur ou d'un lanceur/updater.

Tu n'as pas compris ce que je disais : le premier lanceur (programme 1 dans la chaîne) c'est lui l'updater de l'updater. Son seul rôle c'est de remplacer l'updater (programme 2) par sa nouvelle version si elle se trouve dans le dossier. C'est de toute façon l'updater qui télécharge toute mise-à-jour se trouvant sur le serveur ; il installe celles du programme principal (3) mais c'est le lanceur qui installe celles de l'updater.

Le code du lanceur (1) doit être très réduit et ultra simple car dans cette archi c'est le seul composant à ne pas pouvoir être mis à jour automatiquement (donc il faut faire en sorte de ne pas avoir à le modifier).