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é.
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é.
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é.
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
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
faisable mais c'est bricolé.
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
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
faisable mais c'est bricolé.
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
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
faisable mais c'est bricolé.
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
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
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
mon programme se connecte sur le serveur et récupère
le fichier version, avec un simple DownloadFile.
mon programme se connecte sur le serveur et récupère
le fichier version, avec un simple DownloadFile.
mon programme se connecte sur le serveur et récupère
le fichier version, avec un simple DownloadFile.
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é.
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" 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
version, donc utiliser les objets de versions...
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
version, donc utiliser les objets de versions...
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
version, donc utiliser les objets de versions...
" 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êmeversion, 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
" 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êmeversion, 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" 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
>> programme peut nécessiter de recompiler après correction au plus vite
> 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
>> programme peut nécessiter de recompiler après correction au plus vite
> 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
>> programme peut nécessiter de recompiler après correction au plus vite
> 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_' ;
>
>
>
>
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
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
faisable mais c'est bricolé.
Des idées ?
Merci.
Ted
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
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
faisable mais c'est bricolé.
Des idées ?
Merci.
Ted
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
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
faisable mais c'est bricolé.
Des idées ?
Merci.
Ted
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
> référence sur un serveur (comparer les dates de fichiers c'est facile,
> 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
> référence sur un serveur (comparer les dates de fichiers c'est facile,
> 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
> référence sur un serveur (comparer les dates de fichiers c'est facile,
> 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/