Comment un fichier EXE (programme VB6 compilé) peut tester sa version et se mettre à jour lui-même ?
13 réponses
teddy
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est
faisable mais c'est bricolé.
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog qui renvoie simplement : - 1 ère ligne : 1 si il faut une maj 0 sinon - 2 ème ligne : numéro de la dernière version - 3 ème ligne : description courte de la MAJ - 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Salut,
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page
http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog
qui renvoie simplement :
- 1 ère ligne : 1 si il faut une maj 0 sinon
- 2 ème ligne : numéro de la dernière version
- 3 ème ligne : description courte de la MAJ
- 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version
que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en
télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog qui renvoie simplement : - 1 ère ligne : 1 si il faut une maj 0 sinon - 2 ème ligne : numéro de la dernière version - 3 ème ligne : description courte de la MAJ - 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Jean-Marc
" teddy" a écrit dans le message de news:%
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est
faisable mais c'est bricolé.
Hello,
J'ai lu la solution de ng, qui est très bien. Moi j'utilise la méthode suivante:
sur le serveur, la dernière version du programme, avec un nom particulier, par exemple: "programme_V3.2.1.exe" et un fichier version.txt qui contient 1ere ligne : numero de la version du serveur : 3.2.1 2eme ligne : nom de l'executable sur le serveur : "programme_V3.2.1.exe"
mon programme se connecte sur le serveur et récupère le fichier version, avec un simple DownloadFile. Il compare sa version (App.major & App.minor & App.Revision) avec la première ligne de version. Si nécessaire, il propose la mise à jour. Si l'utilisateur accepte, il lance un second petit programme (maj.exe à que je distribue avec le programme, puis se ferme. On passe en paramètre de ligne de commande à maj.exe le nom de l'executable (la 2eme ligne) Le programme maj.exe downloade le nouveau programme (programmeV3.2.1.exe) et le renomme en programme.exe. Maj.exe signale qu'il a réussi la mise à jour et se ferme, en demandant à l'utilisateur de relancer. Il pourrait relancer lui même avant de se fermer.
On peut même masquer toute intervention à l'utilisateur, mais dans la (bonne) pratique, on évite.
Si tu as besoin, je peux poster le code minimal mais fonctionnel qui fait cela.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
" teddy" <teddy@wanadoo.fr> a écrit dans le message de
news:%23iiyTgZrFHA.1032@TK2MSFTNGP12.phx.gbl...
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est
faisable mais c'est bricolé.
Hello,
J'ai lu la solution de ng, qui est très bien. Moi j'utilise
la méthode suivante:
sur le serveur, la dernière version du programme, avec un nom
particulier, par exemple:
"programme_V3.2.1.exe"
et un fichier version.txt qui contient
1ere ligne : numero de la version du serveur : 3.2.1
2eme ligne : nom de l'executable sur le serveur :
"programme_V3.2.1.exe"
mon programme se connecte sur le serveur et récupère
le fichier version, avec un simple DownloadFile.
Il compare sa version (App.major & App.minor & App.Revision)
avec la première ligne de version. Si nécessaire, il propose
la mise à jour. Si l'utilisateur accepte, il lance un second
petit programme (maj.exe à que je distribue avec le programme,
puis se ferme. On passe en paramètre de ligne de commande à maj.exe
le nom de l'executable (la 2eme ligne)
Le programme maj.exe downloade le nouveau programme (programmeV3.2.1.exe)
et le renomme en programme.exe. Maj.exe signale qu'il a réussi la mise
à jour et se ferme, en demandant à l'utilisateur de relancer.
Il pourrait relancer lui même avant de se fermer.
On peut même masquer toute intervention à l'utilisateur, mais dans
la (bonne) pratique, on évite.
Si tu as besoin, je peux poster le code minimal mais fonctionnel
qui fait cela.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est
faisable mais c'est bricolé.
Hello,
J'ai lu la solution de ng, qui est très bien. Moi j'utilise la méthode suivante:
sur le serveur, la dernière version du programme, avec un nom particulier, par exemple: "programme_V3.2.1.exe" et un fichier version.txt qui contient 1ere ligne : numero de la version du serveur : 3.2.1 2eme ligne : nom de l'executable sur le serveur : "programme_V3.2.1.exe"
mon programme se connecte sur le serveur et récupère le fichier version, avec un simple DownloadFile. Il compare sa version (App.major & App.minor & App.Revision) avec la première ligne de version. Si nécessaire, il propose la mise à jour. Si l'utilisateur accepte, il lance un second petit programme (maj.exe à que je distribue avec le programme, puis se ferme. On passe en paramètre de ligne de commande à maj.exe le nom de l'executable (la 2eme ligne) Le programme maj.exe downloade le nouveau programme (programmeV3.2.1.exe) et le renomme en programme.exe. Maj.exe signale qu'il a réussi la mise à jour et se ferme, en demandant à l'utilisateur de relancer. Il pourrait relancer lui même avant de se fermer.
On peut même masquer toute intervention à l'utilisateur, mais dans la (bonne) pratique, on évite.
Si tu as besoin, je peux poster le code minimal mais fonctionnel qui fait cela.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
teddy
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une même version, donc utiliser les objets de versions... Merci tout de même. D'autres idées ?
Ted
" teddy" a écrit dans le message de news: %
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Des idées ? Merci.
Ted
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du
programme peut nécessiter de recompiler après correction au plus vite une même
version, donc utiliser les objets de versions...
Merci tout de même.
D'autres idées ?
Ted
" teddy" <teddy@wanadoo.fr> a écrit dans le message de news:
%23iiyTgZrFHA.1032@TK2MSFTNGP12.phx.gbl...
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est
faisable mais c'est bricolé.
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une même version, donc utiliser les objets de versions... Merci tout de même. D'autres idées ?
Ted
" teddy" a écrit dans le message de news: %
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Des idées ? Merci.
Ted
ng
Jean-Marc wrote:
mon programme se connecte sur le serveur et récupère le fichier version, avec un simple DownloadFile.
Oui j'ai oublié de préciser. Inutile de sortir windows, inet & co, ca suffit largement et c'est facile à utiliser.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
Jean-Marc wrote:
mon programme se connecte sur le serveur et récupère
le fichier version, avec un simple DownloadFile.
Oui j'ai oublié de préciser. Inutile de sortir windows, inet & co, ca suffit
largement et c'est facile à utiliser.
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
mon programme se connecte sur le serveur et récupère le fichier version, avec un simple DownloadFile.
Oui j'ai oublié de préciser. Inutile de sortir windows, inet & co, ca suffit largement et c'est facile à utiliser.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
LE TROLL
De mémoire, c'est paramétrable dans l'éditeur l'enregistrement des versions automatiquement incrémentées, encore faut-il l'utiliser...
" teddy" a écrit dans le message de news: eXS%
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une même version, donc utiliser les objets de versions... Merci tout de même. D'autres idées ?
Ted
" teddy" a écrit dans le message de news: %
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Des idées ? Merci.
Ted
De mémoire, c'est paramétrable dans l'éditeur l'enregistrement des versions
automatiquement incrémentées, encore faut-il l'utiliser...
" teddy" <teddy@wanadoo.fr> a écrit dans le message de news:
eXS%23ggarFHA.1984@tk2msftngp13.phx.gbl...
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du
programme peut nécessiter de recompiler après correction au plus vite une même
version, donc utiliser les objets de versions...
Merci tout de même.
D'autres idées ?
Ted
" teddy" <teddy@wanadoo.fr> a écrit dans le message de news:
%23iiyTgZrFHA.1032@TK2MSFTNGP12.phx.gbl...
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais faire avec FSO) et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est
faisable mais c'est bricolé.
De mémoire, c'est paramétrable dans l'éditeur l'enregistrement des versions automatiquement incrémentées, encore faut-il l'utiliser...
" teddy" a écrit dans le message de news: eXS%
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une même version, donc utiliser les objets de versions... Merci tout de même. D'autres idées ?
Ted
" teddy" a écrit dans le message de news: %
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je sais faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour est faisable mais c'est bricolé.
Des idées ? Merci.
Ted
jean-marc
" teddy" wrote in message news:eXS#
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire. Peux tu préciser et notamment expliquer les "objets de versions" ?
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
" teddy" <teddy@wanadoo.fr> wrote in message
news:eXS#ggarFHA.1984@tk2msftngp13.phx.gbl...
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du
programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire.
Peux tu préciser et notamment expliquer
les "objets de versions" ?
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire. Peux tu préciser et notamment expliquer les "objets de versions" ?
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
teddy
Ce qui permet d'afficher le No de version par exemple : App.Major & "." & App.Minor & "." & App.Revision
"jean-marc" a écrit dans le message de news: 43158bf4$0$10950$
" teddy" wrote in message news:eXS#
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire. Peux tu préciser et notamment expliquer les "objets de versions" ?
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Ce qui permet d'afficher le No de version par exemple : App.Major & "." &
App.Minor & "." & App.Revision
"jean-marc" <aa@BB.com> a écrit dans le message de news:
43158bf4$0$10950$ba620e4c@news.skynet.be...
" teddy" <teddy@wanadoo.fr> wrote in message
news:eXS#ggarFHA.1984@tk2msftngp13.phx.gbl...
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du
programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire.
Peux tu préciser et notamment expliquer
les "objets de versions" ?
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
Ce qui permet d'afficher le No de version par exemple : App.Major & "." & App.Minor & "." & App.Revision
"jean-marc" a écrit dans le message de news: 43158bf4$0$10950$
" teddy" wrote in message news:eXS#
Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation du programme peut nécessiter de recompiler après correction au plus vite une
même
version, donc utiliser les objets de versions...
Hello,
je n'ai pas compris ce que tu veux dire. Peux tu préciser et notamment expliquer les "objets de versions" ?
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Jean-Marc
Ok si tu ne veux pas utiliser ce moyen (qui est le meilleur) tu peux faire ta comparaison de version basée sur ce que tu veux à la place, le mécanisme reste identique, n'est ce pas.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
" teddy" a écrit dans le message de news:
Ce qui permet d'afficher le No de version par exemple : App.Major & "." & App.Minor & "." & App.Revision
"jean-marc" a écrit dans le message de news: 43158bf4$0$10950$ > > " teddy" wrote in message > news:eXS# >> Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation
du
>> programme peut nécessiter de recompiler après correction au plus vite
une
> même >> version, donc utiliser les objets de versions... > > Hello, > > je n'ai pas compris ce que tu veux dire. > Peux tu préciser et notamment expliquer > les "objets de versions" ? > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > mailto: remove '_no_spam_' ; > > > >
Ok si tu ne veux pas utiliser ce moyen (qui est le meilleur)
tu peux faire ta comparaison de version basée sur ce que tu veux
à la place, le mécanisme reste identique, n'est ce pas.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
" teddy" <teddy@wanadoo.fr> a écrit dans le message de
news:O1u0CZlrFHA.248@TK2MSFTNGP14.phx.gbl...
Ce qui permet d'afficher le No de version par exemple : App.Major & "." &
App.Minor & "." & App.Revision
"jean-marc" <aa@BB.com> a écrit dans le message de news:
43158bf4$0$10950$ba620e4c@news.skynet.be...
>
> " teddy" <teddy@wanadoo.fr> wrote in message
> news:eXS#ggarFHA.1984@tk2msftngp13.phx.gbl...
>> Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation
du
>> programme peut nécessiter de recompiler après correction au plus vite
une
> même
>> version, donc utiliser les objets de versions...
>
> Hello,
>
> je n'ai pas compris ce que tu veux dire.
> Peux tu préciser et notamment expliquer
> les "objets de versions" ?
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
> mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
>
>
>
>
Ok si tu ne veux pas utiliser ce moyen (qui est le meilleur) tu peux faire ta comparaison de version basée sur ce que tu veux à la place, le mécanisme reste identique, n'est ce pas.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
" teddy" a écrit dans le message de news:
Ce qui permet d'afficher le No de version par exemple : App.Major & "." & App.Minor & "." & App.Revision
"jean-marc" a écrit dans le message de news: 43158bf4$0$10950$ > > " teddy" wrote in message > news:eXS# >> Ouaip, ce qui m'ennuie c'est qu'un bug découvert pendant l'utilisation
du
>> programme peut nécessiter de recompiler après correction au plus vite
une
> même >> version, donc utiliser les objets de versions... > > Hello, > > je n'ai pas compris ce que tu veux dire. > Peux tu préciser et notamment expliquer > les "objets de versions" ? > > -- > Jean-marc > "There are only 10 kind of people > those who understand binary and those who don't." > mailto: remove '_no_spam_' ; > > > >
Patrick Garceau
Ici j'utilise 2 fichiers,
Prog1.exe (petit programme de vérification) Prog2.exe (application complète)
le fichier Prog1.exe est exécuté et vérifie si le Prog2.exe à une version plus récente sur un serveur, si le cas est vrai, alors on copie la version serveur sur la version locale, emsuite on exécute la version locale de prog2.exe
Ceci permet de compiler une nouvelle version et de la copier sur le serveur sans déranger qui que ce soit. Les gens n'ont qu'à fermer et redémarrer l'application locale.
Ici le prog2 vérifie aussi si le prog1.exe à changé sur le serveur.
La vérification dans l'application prog2 se fait au 2 ou 5 minutes je crois et affiche un message à l'utilisateur s'il détecte une nouvelle version sur le serveur.
En tk, ça marche très bien depuis 2 ans, et les utilisateurs sont parfois pas au courant qu'une nouvelle version est en cours.
Patrick
" teddy" wrote in message news:%
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est
faisable mais c'est bricolé.
Des idées ? Merci.
Ted
Ici j'utilise 2 fichiers,
Prog1.exe (petit programme de vérification)
Prog2.exe (application complète)
le fichier Prog1.exe est exécuté et vérifie si le Prog2.exe à une version
plus récente sur un serveur, si le cas est vrai, alors on copie la version
serveur sur la version locale, emsuite on exécute la version locale de
prog2.exe
Ceci permet de compiler une nouvelle version et de la copier sur le serveur
sans déranger qui que ce soit. Les gens n'ont qu'à fermer et redémarrer
l'application locale.
Ici le prog2 vérifie aussi si le prog1.exe à changé sur le serveur.
La vérification dans l'application prog2 se fait au 2 ou 5 minutes je crois
et affiche un message à l'utilisateur s'il détecte une nouvelle version sur
le serveur.
En tk, ça marche très bien depuis 2 ans, et les utilisateurs sont parfois
pas au courant qu'une nouvelle version est en cours.
Patrick
" teddy" <teddy@wanadoo.fr> wrote in message
news:%23iiyTgZrFHA.1032@TK2MSFTNGP12.phx.gbl...
Bonjour,
La question est dans l'objet du mail.
Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
solution ad'hoc.
Il s'agit simplement de tester le fichier EXE par rapport à une version de
référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème).
Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
Prog1.exe (petit programme de vérification) Prog2.exe (application complète)
le fichier Prog1.exe est exécuté et vérifie si le Prog2.exe à une version plus récente sur un serveur, si le cas est vrai, alors on copie la version serveur sur la version locale, emsuite on exécute la version locale de prog2.exe
Ceci permet de compiler une nouvelle version et de la copier sur le serveur sans déranger qui que ce soit. Les gens n'ont qu'à fermer et redémarrer l'application locale.
Ici le prog2 vérifie aussi si le prog1.exe à changé sur le serveur.
La vérification dans l'application prog2 se fait au 2 ou 5 minutes je crois et affiche un message à l'utilisateur s'il détecte une nouvelle version sur le serveur.
En tk, ça marche très bien depuis 2 ans, et les utilisateurs sont parfois pas au courant qu'une nouvelle version est en cours.
Patrick
" teddy" wrote in message news:%
Bonjour,
La question est dans l'objet du mail. Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la solution ad'hoc. Il s'agit simplement de tester le fichier EXE par rapport à une version de référence sur un serveur (comparer les dates de fichiers c'est facile, je
sais
faire avec FSO) et de le remplacer (c'est là qu'est le problème). Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé). Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
est
faisable mais c'est bricolé.
Des idées ? Merci.
Ted
Thierry
T'as raison.. C'est du bricolage... Tu connais les services Web ?
"ng" a écrit dans le message de news:
Salut,
> Bonjour, > > La question est dans l'objet du mail. > Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la > solution ad'hoc. > Il s'agit simplement de tester le fichier EXE par rapport à une version
de
> référence sur un serveur (comparer les dates de fichiers c'est facile,
je
> sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
> et de le remplacer (c'est là qu'est le problème). > Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
> Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour > est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog qui renvoie simplement : - 1 ère ligne : 1 si il faut une maj 0 sinon - 2 ème ligne : numéro de la dernière version - 3 ème ligne : description courte de la MAJ - 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
T'as raison.. C'est du bricolage... Tu connais les services Web ?
"ng" <ng@ngsoft-fr.com> a écrit dans le message de
news:uGBxEvZrFHA.3080@TK2MSFTNGP15.phx.gbl...
Salut,
> Bonjour,
>
> La question est dans l'objet du mail.
> Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la
> solution ad'hoc.
> Il s'agit simplement de tester le fichier EXE par rapport à une version
de
> référence sur un serveur (comparer les dates de fichiers c'est facile,
je
> sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
> et de le remplacer (c'est là qu'est le problème).
> Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
> Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour
> est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page
http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog
qui renvoie simplement :
- 1 ère ligne : 1 si il faut une maj 0 sinon
- 2 ème ligne : numéro de la dernière version
- 3 ème ligne : description courte de la MAJ
- 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version
que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en
télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
T'as raison.. C'est du bricolage... Tu connais les services Web ?
"ng" a écrit dans le message de news:
Salut,
> Bonjour, > > La question est dans l'objet du mail. > Je crois que cela a déjà été posé mais je n'ai pas trouvé avec Google la > solution ad'hoc. > Il s'agit simplement de tester le fichier EXE par rapport à une version
de
> référence sur un serveur (comparer les dates de fichiers c'est facile,
je
> sais faire avec FSO)
FSO, bahh... utilie plutot App.Major, App.Minor et App.Revision
> et de le remplacer (c'est là qu'est le problème). > Le fichier EXE ne peut être mis à jour quand on le lance (accès refusé).
Il suffit de le faire depuis un prog externe.
> Une solution avec un batch ou un vbs qui appelle l'EXE et le met à jour > est faisable mais c'est bricolé.
Oui c'est du bricolage, voici la solution que j'utilise :
1/ Récupèration de la page http://www.monserveur.com/mon_app/version.php?ma_version=version_du_prog qui renvoie simplement : - 1 ère ligne : 1 si il faut une maj 0 sinon - 2 ème ligne : numéro de la dernière version - 3 ème ligne : description courte de la MAJ - 4 ème ligne : URL vers la mise à jour (elle peut dépendre de la version que le client a deja)
2/ Si il faut une maj, on demande au client s'il veut la faire, puis en télécharge le fichier avec l'url de la 4ème ligne
3/ En lance l'exe téléchargé et on quitte le prog
4/ l'exe téléchargé fera la maj tout seul et rédémarrera le programme
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/
