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.
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.
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.
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.
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.
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.
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 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 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
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.
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.
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.