Archive: Update Check / Auto Update / Web Download
Update Check / Auto Update / Web Download
Hi,
I'm using NSIS as installer for some apps I wrote. This works great. Now I'm wondering:
Is there a tool available that compares the local version of an app to the version available for download, notifies the user if this is the case and maybe even automatically download (and maybe install) this new version?
How I do this :)
On regular updates (like weekly advertisement rotation ;) ) program first reads XML configuration file (fixed URL), where one of optional tags is "version=xxx". This may be static or script generated file, XML or not. Next step - parsing, and if available version is high then the current one, program displays message box or adds "Update" item to main program popup menu. If "yes" you can point default browser to package URL. Or program can silently download new package without any popups or menu items - very good for big packs, you can do this at night( few GBytes ;) ). New package URL may be static (defined during last install/update) or dynamic (defined as attribute in the xml file).
Finally this is easy (if packages are not huge), but I don't know ready and free tools :(
I've done this numerous times. What Takhir explained is exactly how I did it.
-Stu
I am using this method to:
install update files.... if needed...
Or launch my 'real' application and write an 'user variable' xml file if everything is up to date...
all the user does is click on my nsis app...to them they are clicking on the main app...
this is extremely powerful :) and quite cool
My 'installer' (or rather some software I wrote in NSIS) would update itself (the exe file)
I'd firstly download the update to "myapp.exe_update" (through the main "myapp.exe" application)
I'd then extract a seperate exe called "install_update.exe", Exec it and Quit.
The "install_update.exe" program would Delete "myapp.exe" and Rename "myapp.exe_update" to "myapp.exe" (after a confirm MessageBox).
Finally it would Exec it and Quit itself also!
-Stu
yes...I do that too with what I am doing now:)
all of my relevant file versions are in a ini file downloaded and compared to a local ini file....Seemed the writing files to the registry was blocked for certain corporate users, so I switched to straight INI comparisons.
really cool in that you can update/replace the icon of your installer.exe this way....
I am very happy with it so far...in that it makes installing/launching applications a brain-dead /one-click affair for the average user
It happens so fast that the user does not know the difference.
g
Originally posted by TakhirThat's a good way to get the job done. But it requires every app to take care of it's own auto-update.
How I do this :)
That's possible with NSIS.
See this for example:
http://hmd.hostileintent.org/mapupdater/manual.html
That was written in NSIS (by myself :))
-Stu
Is the source code of that app available?
In most cases requirements for "updater" integration with main application are too high to create universal program. But I'll think about this too :) . Mapupdater is a specialized program, but I like it's ideas. Most probably this should be hidden resident application with a list of programs and schedule, some settings dialog (like mapupdater shows).
What kind of integration is required?
1. For example, customer wants Update banner to be visible on the top of his application if new version is available, so we need at least some common interface between "versions tracker" and app.
2. Partial and silent replacements like dlls (not a whole package download for big apps) may be a real head pain (for example, sometimes it is not easy to restart application with replaced dll - you should stop it first, and not all apps accepts WM_CLOSE).
May be more reasons, but finally we can skip most of them if application was designed with "tracker" requirements, so these requirements should be standartized first (or stupied customers will never agree with this).
A bit long, but I think this is no bad idea.
I thought about the following Update feature, so one could have 1 installer for all:
- full install from scratch
- updater
- web updater
- web install
Special web features within installer only make sence if the files are only downloaded if needed.
My current solution is one installer for Full and Update (Update removes the previous install, letting only some user settings there). This kind of Update outmatches file-only-updates a bit, because you can change application files as you want. No need to worry about compatibility.
So the ideal solution (for me) would be:
The installer has some file listing with version numbers of the application at the time the installer was created. Maybe the files itself are contained in the installer.exe. It may ask the user to get some new file listing via internet (online update). In any case installer has some recent listing and may have some required files in it. Installer checks what files are missing. In update mode installer checks whether the missing files were already installed (i.e. on user's hard disk). After this some files may be missing. In this case the installer downloads just these files, stores all files (fresh files from web, up to date files from installer itself, up to date files from previous installation) into some temp dir, then the previous installation gets removed and the new release gets installed.
Advantages:
- minimal download needs
- one installer for update and installation from scratch
- offline installer and online installer
- you could simply build some installer without application files to build some online-only-installer (webinstall)
- you could include all needed files for some offline-only-installer (maybe with online-check-for-new-updates option during install)
Even if the install package is older than the previously installed version you could use it to bring the application up to date.
I didn't realise this yet because this seems to be a heavy and complex task. Probably this isn't worth while for just one or two people.
Originally posted by stbIt's only complex and heave when everyone has to write it from scratch, just like an installer.
I didn't realise this yet because this seems to be a heavy and complex task. Probably this is worth while for just one or two people.
Hi,
maybe we can build a team of few people to realise this. Maybe 3 or 4 people is a good team size. Of course I'm with this.
Some idea's:
I wrote quite some NSIS code and realised that for most features macros are easier to handle than functions. You don't need "un." (double) and you only include code you actually use. So I would prefer some macro set.
Some work is required on defining and comparing some "file version list". My suggestion is some ini file:
[myapp.exe]
version=1.2.3.4
[myapp_helper.dll]
version=5.6.7.8
This is simple and maybe extensible (I think about MD5 checksum).
I have some macros to install DLLs similar to the upgradeDll macro (and that newer thing in current NSIS). I think this should be flexible enough so everyone can user his own technique. Building some temp dir with the install files (including corresponding fileversionlist.ini) should be fine.
I looked at some macros and macro libs like LogicLib and StrFunc. Personally I prefer using my own macro set. That's mainly because I learned NSIS "from scratch" :-) But I don't want to enjoin these things - that interdepends with my work package (size).
We would use nsisDl, wouldn't we? Otherwise we could add some more helper functions into the download dll we would use. So if some C(++) guys want to join...
Just some ideas.
Stefan
The upgrader (and file version list) should be automatically generated I think, if possible, in the same step as compiling the .nsi.
I'd also be nice to generate only a single container, with all single files individually compressed (non-solid). This container could then even be used as normal installer.
You could then download individual files by requesting only a part (both FTP and HTTP support this, right).
To make it clear: I want some single installer.exe which has _all_ features. I may build different installers but only to get different file sizes (e.g. one webinstaller 100kb, one full installer, one full installer without M$ runtimes).
Yes, files should be downloaded separately (otherwise the thing is easy: download the fresh full installer from the web). Whether
Of course building installers should be batch-processable. I build all my installers using some bat file. Creating the ini file would be some pre-processing step (if you have files in your app without version information inside you need this, if not you can make your own little NSIS preprocessor).
PS: I prefer code running on most OS. Maybe some old W95 installation can be excluded from web features if IE is not installed.. but in general installer should work on all OS (not just win2k/xp)
Is there anything like this working already?
My needs would be a file that people can download once and on its first run it installs let's say 10 files on a ftp or http location. Next time the user runs the application it should check for updates, eg if there are additional 2 files download them and put into install dir.
Any examples? I am totally new and search for a free installer system with web updating. Of the ones i found nsis looks most promising, but i am lost...
Maybe the first version should be a simple updater that only checks whether there's an update available and if so, notifies the user.
Then more complex versions can be made later.
Currently, my app checks for updates directly, downloads some app_update.exe from some fix URL, starts this exe and quits itself.
For now I just download something like full package without runtimes. This package checks whether runtimes are installed (they will be) and then makes some uninstall/reinstall.
So what I need is
1. some smaller update package (only downloading updated components)
2. some web installer which only downloads needed components (most people will have those runtime libraries anyway).
I think this can be combined to some full/upgrade/online/offline installer. Detecting whether the current app is up to date is some small part of this and will happen automatically.
Some META code:
It all begins after the user starts some install.exe.
1. Check whether application is already installed and get version number of this previous installation.
2. Ask the user to check the web for a new version. This may be obligatory (webinstall.exe).
3. Compare installed version to included/web version. The user may downgrade, upgrade or repair installation (install same version). If no previous installation exists this will be just some full installation.
4. If user wants to perform some installation: Try to get all files needed for the new version. They may be on the hard disk already (previous installation), they may be included with the install.exe or the may need to be downloaded from the web.
5. Copy files from previous installation to TEMP, remove previous, install new.
Application and file version should be managed using some ini file. One can be found within install.exe (if this is no online-only-webinstaller), one can be found in the previous installation's application directory, one may be downloadable from the web. At least one such file is necessary to install.
So, to make your "check for update" program, you would make some small installer whithout appversion.ini and without any application files. So the user is forced to make the online-up-to-date-check.
I think the complete solution may be useful for many people as all common scenarios can be handled. And I think it could be done if we split the task into a couple of macros:
- download macros (download single files from the web, download appversion.ini)
- file managing macros (save previous installation's files, store files from install.exe and from URL))
- version compare macros (comparing app versions, file versions)
So, anyone interested in joining this?
Hi,
I was wondering if anything happened with this project? I am new to NSIS so I do not (yet) have the experience to develop the code discussed here...can anyone point me in the right direction of a developed solution?
The InetC plugin is the core piece of kit here along with ReadINIStr.
Stu
Yes. I think the remaining work can be done with some macros. It would be useful to define a common format for file versions so we can all use the same macro kit. I think this is something which will evolve with time...
I did some things myself but did not make this generic yet. I need some people who commit to this one (and who can contribute specific ideas and code).
Hello,
Is this Updater project ready now?
best regards
josabraham
Is this updater project still active?
Is it available?
Thanks :-)