Web updates & patching (yet again)

[Pete B]

Hi
I am getting my head around web updates and patching and it's coming together but I do still have a question or two. Although I've read the pertinent help file pages (several times) and many of the 'don't understand patching and web updates' posts in the forum I'm still a bit unclear.
1. The update packs (Web Updates) help page states clearly that an update can be any downloadable file. OK, so as I distribute my app. as a web build comprising the setup.exe + 6 web media blocks, then could an update pack simply consist of a new (ie. updated WMB). I had a go at this but even though an update pack is defined and version 'binding' declared, you do still need a patch reference else the build will fail. Patch references always point to setup.exe files and patching always produces another setup.exe. So is there any way a web update can actually be 'any' downloadable file or is it actually always giong to be a setup.exe file.
2. Take for example app. version 1.0, web build, distribute and make sure the build files are saved to a separate location. Then along comes version 1.1 which is duly built and distributed in place of version 1.0 for new users. Now, need to build a patch for the 1.0 users out there so, patch reference the v 1.0 setup.exe saved above, define an update pack, then link it to version 1.0 on the versions page. Build patch.
Is the setup.exe produced by the patch meant to REPLACE the setup.exe created for version 1.1 ?
Does the patch setup.exe serve as a version 1.1 setup.exe for new users AND as the updated file(s) package for old version 1.0 users ?

If this sounds confused, then I am sorry but I don't think I'm alone with a little confusion over the 'interaction' between patching/web updates/update packs from perusing the forum. IA is a superb piece of software engineering and it is very apparent that the way in which it handles web updates, patching (and web builds) is its 'crowning glory' yet these issues are IMHO covered disjointedly in the help files, in bits and pieces dotted throughout the forum and not ( as far as I have unearthed ) in any detail in any technical publication. I know it's been said before but I'll stick my head above the parapet and say, why not produce a clear, preferably diagrammatic tutorial/technical document which practically demonstrates the use of IA's 'crowning glory', with real world examples and scenarios. Everybody hates writing help files but this would do IA (and its users) a power of good. It would even help people like me !

OK, soapbox put away, best wishes always

Pete B.

[Pete B]

Or perhaps if I put it a little differently ...
Is it possible for a web update to be anything other than an executable patch ?
I've used patching, it works just fine but the update packs help says that an update can be 'any downloadle file'. So, tried an update pack with version 'binding' but no patch references. From the updates.ini download, the target machine recognises an update is there (in this case a .7zip file corresponding to an update of an older .7zip web media block) but will not download it and even if it did I wonder if the target machine's installer would know what to do with it ?
Is it possible to update like this, ie. without use of patching and also not a 'NEEDSUPGRADE = TRUE' type of update ie. full uninstall/install.

thanks

Pete B.

[jimo]

Absolutely, why not?

You have several choices;

1. Create your own update.exe using IA to create a project with nothing but a progress dialog, the single file exe will download and run overwriting anything that matches. I am using this same methodology for supplying small updates where just a report file or a supporting file may have changed.

2. Download 7Zip the application, and create a self extracting archive, the default web update script uses run prgram which you can modify any way you need.

[Pete B]

Jimo, thanks for the information.

I assume that any subsidiary 'update.exe' in any of the options you have given would require the identical product GUID to the original product install in order to keep the installation 'tidy' and to facilitate a clean uninstall if required ? Is that what you do with the small file upgrades you mention ?

[jimo]

Yep, but keep in mind you need to remove all the NEEDSUPGRADE logic from the new script.

[Pete B]

Thanks again Jimo. I'll do some work on this. There are definitely circumstances where this approach would be more appropriate than patching and as long as the installation doesn't get 'split', it's looking good

cheers