How to automatize a VFP exe download to the more recent version?

See here:

http://www.sweetpotatosoftware.com/spsblog/2008/02/15/VFPApplicationUpdatingMadeSimple.aspx

Bye, Olaf.

Thanks for your interations!
I just start reading carefully and come back soon...

Just to elucidate the actualization is currently done by a installer - the users first need to check by themself if it's necessary in the site, and then if so go to this page:

http://www.espiriplug.com.br/Corrige_Financeiro_v2.php

Hello, Olaf

The solution you pointed (sweetpotato) is the simplest

One  more thing just if you could help.

I don't know if I correctly configured the .ini or I'm misconcepting something , even the  version of the instaler (.exe) is updated the appupdate.exe keep downloading the zip from the site everytime it's fired...

The .ini

[UPDATE]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;The ApplicationToUpdate entry specifies the application that appudate.exe should execute
;after it has finished checking for updates, downloading, installing, and/or running scripts
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

applicationtoupdate=Instalador_Livrarias_PATCH_v2156.exe

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Some applications require elevated permissions on Windows Vista.
;If the ApplicationToUpdate requires elevation set the following
;RunApplicationAsAdmin entry to TRUE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

runapplicationasadmin=FALSE

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;If the ApplicationToUpdate requires parameters to be sent to it
;when running it, they can be specified in the ApplicationCommandLineParams entry
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

applicationcommandlineparams=

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;The VersionSource entry specifies the location of the file containing the version
;number of the update that is currently available to the users. This entry can be a
;local or remote file path, an FTP URL, or an HTTP URL.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;versionsource=http://www.sweetpotatosoftware.com/serverupdate/sampleapp.exe.txt

versionsource=http://www.espiriplug.com.br/gecc2.txt


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;The UpdateSource entry specifies the location of the update file that should be
;downloaded and unzipped if the users choose to update. This entry can be a
;local or remote file path, an FTP URL, or an HTTP URL.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;updatesource=http://www.sweetpotatosoftware.com/serverupdate/sampleapp.exe.zip

updatesource=http://www.espiriplug.com.br/Espiriplug_prj/Downloads/Livrarias_PATCH_v2156.zip



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Sometimes it is useful or necessary for Admins to be in charge of downloading
;the updates and then redistributing them to the other users. The CopyUpdateTo entry
;will cause the appupdate.exe to copy the upgrade files (VersionSource and UpdateSource)
;to the location specifed. Presumably the other users would have their appupdate.ini
;modified so that versionsource and UpdateSource would point to the location
;specified by the Admin's CopyUpdateTo entry. The users' CopyUpdateTo would be left
;blank.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

copyupdateto=


[MESSAGE]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;The entries in the Message section determine the text that is displayed to the
;user when the Update screen is displayed. The Caption entry is for the caption
;of the update screen that displays in the Title Bar.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

caption=Update Available

Select allOpen in new window

The gecc2.txt  at net



The installer that keep being downloaded

Thanks in advance!

Well, yes, you have a misconception. Look at the original INI.

applicationtoupdate=sampleapp.exe

This does NOT sepcify a patch or update, but the INSTALLED application. This application is what you want to update, not the update itself.

In this case the app to maintain is sampleapp.exe, and that name will stay sampleapp.exe, version independant.

The updatesource is specifying where to get the update.

Bye, Olaf.

Sorry the insistance

But if I decide to update the installer itself (that is also an .EXE) it must work out too, doesn't it?

Since the installer could have a set of files that must be actualized...

So in my conception AppInstaler must check if the installer is out of date

You cannot update running program by itself. You may schedule the update program replacement in Windows Registry or you may update the installer by the application installed - so the installer code is used at two places in fact...

Another option is to start the installer as a batch which can copy the installer from given place before it starts... which in turn makes the installer useless because you may start the application as a batch which will copy the app from given place/subfolder (if present) and then executes the newly copied version.

Appinstaller is a simple exe only patching the main application exe, no more no less. That's how this is designed. No matter how you insist on the updater being updatable, the update mechanism is only designed to replace one exe, it's not even designed to execute a setup, which does an update. Appinstaller is the updater itself.

And no matter how you think about this in detail, the INI variable is not meant for the updater, it's meant for the main app. That's how it's designed.

If you don't like that, the design is too simple for you, then roll your own. You may start with this and change it as you wish. It was just a recommendation.

Bye, Olaf.

Thank you for the interactions.

I think to put 'Appinstaller' itself inside the current installer package could be interesting to install it with the other files (system itself/ manual/ etc...)

No matter by now if it doesn't check if it's necessary to update or not the installer package when it's fired.

Every time a user decides to fire 'Appinstaller' (that was installed at their PC as an app) the most recent 'installer package' (with the most recent files and even a more complete AppInstaller version inside it) is downloaded and the local files updated (no matter if it's really necessary or not doing that, by now...).

In meanwhile I'm going to study how to develop the feature of download the package installer only if it's necessary.

This is what I do:

Updater checks for new version and downloads it. When the main application is closed it updates it. Inside the new version is a database version. If it's great than the current versions it self-updates the database using CREATE TABLE, ALTER TABLE AND DELETE TABLE.

Also the updater downloads the new updater version and the main application installs it. So in total there are two exes: Application.exe and Updater.exe.

Hello

Finally, I made it simple closer to your initial suggestions

1. Created a table called Version in MySQL DB at net provider with the columns: System/ Version Number/ date

2. When the user logs VFP app a connection with the remote DB is done  and a query to the Version table is made obtaining the current version for the app in use.

3. If a more recente version exists the user is asked to make an upgrade, if it's desired the user is directed to the actualization page via  

executeshell("http://www.espiriplug.com.br/Corrige_Financeiro_v2.php")

Select allOpen in new window

and the VFP app is closed.

4. Then the user actualize the app in the known way.

I tested, it works well.

Awesome!

After interact and reflect I found a solution that Works well