Un billet "Installation ou mise à jour Liveupdate" précédent sur ce thème détaille le mécanisme d'installation d'une application avec mise à jour automatique par un serveur web/http. Ce nouveau billet détaille l'étape suivante, la détection de la disponibilité d'une mise à jour pour les applications déjà déployées. Lorsque l'on sait "comment ça marche", on peut rapidement trouver pourquoi un poste récalcitrant refuse par exemple de proposer une mise à jour...

Rappel sur le principe de l'installation avec mise à jour automatique :

1. sur le poste de développement une procédure d'installation est générée. Il s'agit par défaut d'un exécutable install_serveur.exe.
2. l'exécution de cette procédure install_serveur.exe permet par un transfert FTP de déposer sur un serveur web une installation de référence composée de :
   
   1. une page HTML contenant le lien d'installation de l'application,
   2. un dossier \INSTALL\ contenant la procédure d'installation de l'application "install.exe".
3. sur tous les postes qui vont utiliser l'application, il suffit de télécharger puis d'exécuter l'application install.exe du serveur web. cette installation est faite une seule fois, car à chaque nouveau lancement l'application va automatiquement contrôler si une mise à jour est disponible, et si oui proposer son installation.

Voilà pour le principe, alors comment ça marche :

Lors de l'installation puis des mises à jour de la version de référence (point 2 du principe ci-dessus) sur le serveur web, un fichier \INSTALL\WDUPDATE.NET est créé. C'est un simple fichier de paramètres, au format texte type .INI. Il contient notamment la version de l'exécutable de l'application inclus dans cette installation.

Lors de l'installation de l'application sur le poste d'un utilisateur (point 3 du principe ci-dessus), il y a également la création d'un fichier WDUPDATE.NET, qui va contenir la version de l'exécutable installé sur le poste.
A chaque lancement de l'application sur le poste de l'utilisateur, une requête HTTP ou HTTPS suivant la configuration faite à l'installation, est envoyée vers le serveur qui héberge la version de référence. Cette requête permet de lire le fichier WDUPDATE.NET placé sur le serveur web. Grâce à cette lecture, l'exécutable connaît dès son lancement la version de l'application qui peut être installée à partir du serveur. Si cette version est supérieure à celle en place sur le poste, la mise à jour est proposée.

Pour simplifier à l'extrême, c'est donc simplement la comparaison de deux numéros de versions qui sont mémorisés dans un fichier de paramètres en local, et son homologue sur le serveur. On peut donc rapidement déduire la marche à suivre lorsqu'un poste ne détecte pas la disponibilité d'une mise à jour :

• la requête http(s) envoyée vers le serveur permet bien d'avoir un WDUPDATE.NET, mais la version qu'il contient elle est inférieure à celle de l'application installée (enregistrée dans le WDUPDATE.NET local),
• la requête http(s) envoyée pour vers le serveur pour récupérer le WDUPDATE.NET ne passe pas. Antivirus trop agressif, Firewall, proxy.... tout ce qui peut bloquer une requête http(s) standard doit être contrôlé...

Pour remonter rapidement à la source d'une mise à jour non détectée, il est possible de voit la requête http(s) envoyée par l'exécutable pour récupérer le WDUPDATE.NET du serveur. Il faut utiliser pour cela un utilitaire tel que Wireshark (cf. billet Le b.a.-ba de l'analyse de trames ...) :

• lancer Wireshark, configurer la capture d'un filtre sur "tcp port http" (ajouter d'autres filtres si le poste à d'autres applications faisant en parallèle des requêtes http),
• lancer l'application utilisant la mise à jour "liveupdate",
• le première échange visible dans Wireshark permet de voir la requête GET vers le WDUPDATE.NET du serveur, avec la réponse obtenue...

Exemple de capture de trame par Wireshark :