[Débat] Mise à jour d'une application

Le
Dams
Bonjour,

je lance un petit débat pour partager les différentes méthodes
concernant la mise à jour de vos applications.

En effet, pour ma part je procède comme suit :

1. Je génère (avec Inno Setup) un fichier d'installation setup.exe qui
permet à un utilisateur d'installer l'application complètement sur son
poste et un update.exe qui contient les fichiers mis à jour (l'Exe,
Analyse etc..) Cet update.exe est accessible uniquement par mon
application lorsqu'une mise jour est disponible. Le setup.exe et
update.exe sont sur un FTP.

2. Dans mon application, un menu "Vérifier les mises à jour en ligne"
est présent, ceci a pour but d'aller lire dans un fichier ".txt" la
dernière version disponible de mon appli (ex: 4.0.5) et je compare
cette version avec celle de l'application (ex: 4.0.4) en cours pour
télécharger ou non le fichier "update.exe".

3. Si les 2 versions sont identiques pas de problèmes on affiche un
message indiquant que l''application est à jour. Sinon, on propose le
téléchargement de la mise à jour (update.exe) et on l'exécute apr=
ès
avoir fermé mon application.

Inconvénient : devoir générer 2 installs à chaque nouvelle version =
(le
setup.exe et l'update.exe)
Avantage : Je sais pas si il y en a, mais en tout cas ça fonctionne
depuis 5 ans et ça me permet de contrôler via un assistant d'install,
la mise à jour de chaque fichier si nécessaire.

Bon dev !
Dams
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gilles
Le #21335651
Dams avait soumis l'idée :
Bonjour,

je lance un petit débat pour partager les différentes méthodes
concernant la mise à jour de vos applications.

En effet, pour ma part je procède comme suit :
Inconvénient : devoir générer 2 installs à chaque nouvelle version (le
setup.exe et l'update.exe)
Avantage : Je sais pas si il y en a, mais en tout cas ça fonctionne
depuis 5 ans et ça me permet de contrôler via un assistant d'install,
la mise à jour de chaque fichier si nécessaire.



Je fais à peu près pareil mais pour éviter que l'update soit trop
volumineux :

L'exe qui fait l'upgrade est livré avec l'appli, et il partage les
mêmes dll. (il ne pèse presque rien)

L'appli détecte sa mise à jour, et télécharge un package de mise à jour
(généralement un .exe zippé et un fichier d'instructions à analyser par
le logiciel d'update (mise à jour de BDR, de fichiers de paramètres
etc)).

Si la version des DLL est différente, les DLL sont également
téléchargées (cas de changement de version de Windev), sinon on se
contente juste de l'exe.
Roumégou Eric
Le #21337821
Gilles a formulé ce dimanche :
Dams avait soumis l'idée :
Bonjour,

je lance un petit débat pour partager les différentes méthodes
concernant la mise à jour de vos applications.

En effet, pour ma part je procède comme suit :
Inconvénient : devoir générer 2 installs à chaque nouvelle version (le
setup.exe et l'update.exe)
Avantage : Je sais pas si il y en a, mais en tout cas ça fonctionne
depuis 5 ans et ça me permet de contrôler via un assistant d'install,
la mise à jour de chaque fichier si nécessaire.



Je fais à peu près pareil mais pour éviter que l'update soit trop volumineux
:

L'exe qui fait l'upgrade est livré avec l'appli, et il partage les mêmes dll.
(il ne pèse presque rien)

L'appli détecte sa mise à jour, et télécharge un package de mise à jour
(généralement un .exe zippé et un fichier d'instructions à analyser par le
logiciel d'update (mise à jour de BDR, de fichiers de paramètres etc)).

Si la version des DLL est différente, les DLL sont également téléchargées
(cas de changement de version de Windev), sinon on se contente juste de
l'exe.



pour ma part je suis sorti récemment de l'utilisation de WDINST que
j'utilisais depuis 4 ans.
(voir post d'il y a 1 ou 2 semaine)

cela devenait ingérable et surtout il était impossible d'installer un
nouveau poste; cela ne fonctionnait plus sans raison.

Donc je suis arrivé à une solution bcp plus manuelle mais que je n'ai
pas encore finalisée.

Je vais certainement agir sur un calcul de hash du fichier wdl pour
savoir s'il y a une mise à jour.
J'utilise cela depuis 1 ans sur la partie la plus versatile de mon
projet (entendez celle qui bouge le plus) et cela marche vraiment très
bien.

Donc faut que je fasse le mème type de système pour le coeur du soft.

--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
Roumégou Eric
Le #21352791
Dams a pensé très fort :
Bonjour,

je lance un petit débat pour partager les différentes méthodes
concernant la mise à jour de vos applications.

En effet, pour ma part je procède comme suit :

1. Je génère (avec Inno Setup) un fichier d'installation setup.exe qui
permet à un utilisateur d'installer l'application complètement sur son
poste et un update.exe qui contient les fichiers mis à jour (l'Exe,
Analyse etc..) Cet update.exe est accessible uniquement par mon
application lorsqu'une mise jour est disponible. Le setup.exe et
update.exe sont sur un FTP.

2. Dans mon application, un menu "Vérifier les mises à jour en ligne"
est présent, ceci a pour but d'aller lire dans un fichier ".txt" la
dernière version disponible de mon appli (ex: 4.0.5) et je compare
cette version avec celle de l'application (ex: 4.0.4) en cours pour
télécharger ou non le fichier "update.exe".

3. Si les 2 versions sont identiques pas de problèmes on affiche un
message indiquant que l''application est à jour. Sinon, on propose le
téléchargement de la mise à jour (update.exe) et on l'exécute après
avoir fermé mon application.

Inconvénient : devoir générer 2 installs à chaque nouvelle version (le
setup.exe et l'update.exe)
Avantage : Je sais pas si il y en a, mais en tout cas ça fonctionne
depuis 5 ans et ça me permet de contrôler via un assistant d'install,
la mise à jour de chaque fichier si nécessaire.

Bon dev !
Dams


Bonjour,

Je fais suite à ce post pour expliquer comment je procède dorénavant
pour gérer la màj de mon appli.

Je pose sur un serveur distant les fichiers DLL, WDL, EXE etc ...
Pour une première install, je fourni un fichier .BAT qui lance la
récupération FTP.
Donc là je suis dans une sorte d'installation semi automatique, mais
qui a le mérite d'être simple, voire de pouvoir être contournée
manuellement en utilisant un client FTP. (rappel je suis resté bloqué
avec WDINST qui refusait les primos install sans raison déclarée)
Ensuite mon appli compte deux parties
- une partie générique (la plus grosse) qui ne bouge plus souvent
- une partie spécifique qui elle peut bouger plus d'une fois par jour.

Quand les personnes appellent la partie spécifique, le programme
calcule le hash fichier d'un fichier wdl local (c'est un projet à part
généré en bibliothèque) et le compare au hash fichier du mème fichier
sur le repertoire distant.
le hash du fichier distant m'est retourné par une page AWP qui tourne
sur ce mème serveur (un mini web service en sorte).
Si certain sont intéressé par cette page AWP je peux en fournir le
source (simplissime)

Si les hash sont différents, je lance une récup FTP avec WD puis je
charge mon wdl.
puis j'appelle la fenêtre à jour. ça cela marche impec depuis 6 mois.

Pour le module principal, je fais maintenant le mème principe.
Je teste le hash du fichier WDL principal (au lancement de la
connexion) et si différence, j'enchaine sur une récup FTP.

A ce stade, je ne sais pas si je peux (dois) recharger cette WDL ou
prévenir l'utilisateur qu'il doit relancer l'appli. (je vais regarder
ça ce matin)
Mais comme cette partie ne doit pas bouger souvent, cela ne me gène
plus trop.

Pour publier mes modifs de prog, je travaille avec des raccourcis de
.bat qui sont des ftp DOS sur mon bureau et c'est très simple. Et
surtout tellement plus léger que les mises en prod par http qui me
bloquaient tout pendant 30 mn.

Voilà ce qui peut paraitre un peu compliqué mais c'est surtout que
maintenant je sais ce qui se fait, ce qui doit se faire et comment
intervenir.

--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
Roumégou Eric
Le #21358981
Roumégou Eric avait prétendu :
Dams a pensé très fort :
Bonjour,

je lance un petit débat pour partager les différentes méthodes
concernant la mise à jour de vos applications.

En effet, pour ma part je procède comme suit :

1. Je génère (avec Inno Setup) un fichier d'installation setup.exe qui
permet à un utilisateur d'installer l'application complètement sur son
poste et un update.exe qui contient les fichiers mis à jour (l'Exe,
Analyse etc..) Cet update.exe est accessible uniquement par mon
application lorsqu'une mise jour est disponible. Le setup.exe et
update.exe sont sur un FTP.

2. Dans mon application, un menu "Vérifier les mises à jour en ligne"
est présent, ceci a pour but d'aller lire dans un fichier ".txt" la
dernière version disponible de mon appli (ex: 4.0.5) et je compare
cette version avec celle de l'application (ex: 4.0.4) en cours pour
télécharger ou non le fichier "update.exe".

3. Si les 2 versions sont identiques pas de problèmes on affiche un
message indiquant que l''application est à jour. Sinon, on propose le
téléchargement de la mise à jour (update.exe) et on l'exécute après
avoir fermé mon application.

Inconvénient : devoir générer 2 installs à chaque nouvelle version (le
setup.exe et l'update.exe)
Avantage : Je sais pas si il y en a, mais en tout cas ça fonctionne
depuis 5 ans et ça me permet de contrôler via un assistant d'install,
la mise à jour de chaque fichier si nécessaire.

Bon dev !
Dams


Bonjour,

Je fais suite à ce post pour expliquer comment je procède dorénavant pour
gérer la màj de mon appli.

Je pose sur un serveur distant les fichiers DLL, WDL, EXE etc ...
Pour une première install, je fourni un fichier .BAT qui lance la
récupération FTP.
Donc là je suis dans une sorte d'installation semi automatique, mais qui a le
mérite d'être simple, voire de pouvoir être contournée manuellement en
utilisant un client FTP. (rappel je suis resté bloqué avec WDINST qui
refusait les primos install sans raison déclarée)
Ensuite mon appli compte deux parties
- une partie générique (la plus grosse) qui ne bouge plus souvent
- une partie spécifique qui elle peut bouger plus d'une fois par jour.

Quand les personnes appellent la partie spécifique, le programme calcule le
hash fichier d'un fichier wdl local (c'est un projet à part généré en
bibliothèque) et le compare au hash fichier du mème fichier sur le repertoire
distant.
le hash du fichier distant m'est retourné par une page AWP qui tourne sur ce
mème serveur (un mini web service en sorte).
Si certain sont intéressé par cette page AWP je peux en fournir le source
(simplissime)

Si les hash sont différents, je lance une récup FTP avec WD puis je charge
mon wdl.
puis j'appelle la fenêtre à jour. ça cela marche impec depuis 6 mois.

Pour le module principal, je fais maintenant le mème principe.
Je teste le hash du fichier WDL principal (au lancement de la connexion) et
si différence, j'enchaine sur une récup FTP.



Bon en test cela fonctionnait (car WDTEST ne doit pas utiliser les
wdl).
Mais en prod, comme je le craignais, on ne peut remplacer la branche
sur laquelle on est assise.
Donc j'ai crée un petit exe, un launcher qui s'occupe du contrôle, de
la recup ftp puis envoie l'exe principal.





A ce stade, je ne sais pas si je peux (dois) recharger cette WDL ou prévenir
l'utilisateur qu'il doit relancer l'appli. (je vais regarder ça ce matin)
Mais comme cette partie ne doit pas bouger souvent, cela ne me gène plus
trop.

Pour publier mes modifs de prog, je travaille avec des raccourcis de .bat qui
sont des ftp DOS sur mon bureau et c'est très simple. Et surtout tellement
plus léger que les mises en prod par http qui me bloquaient tout pendant 30
mn.

Voilà ce qui peut paraitre un peu compliqué mais c'est surtout que maintenant
je sais ce qui se fait, ce qui doit se faire et comment intervenir.



--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
Publicité
Poster une réponse
Anonyme