InstallAware

I currently have an install tested and set to check for an update (via update packs) on each logon.

This works and it sees the update and prompts the user to download and then after download it prompts for install.

What I would like to do is NOT prompt for either, but to simply download and then initiate the install.

Looks like I will have to work in the updates script and possible remark out a lot of stuff, but the one area that may be an issue is selecting which update by default. For the updates on this install we are doing full upgrades that basically uninstall the original and re-install. No patches.

And each version should ONLY have one update option and that is the latest version... none of the intermediate ones.

Any thoughts?

This is pushing into the consulting realm. You may hope someone else has done this and can offer some insight, because I'm not seeing an opportunity for me to work on a solution for this in the short-term.

Yes you have to "remark out a lot of stuff" in updates script.

And each version should ONLY have one update option and that is the latest version

This could easily be controlled in the updates.ini. Pass the version of the requesting application and control which updates are available for this version.

Alibaba,

Thank you for your reply.

I had been examining the updates.ini... since I don't have the Studio version I can't easily debug what is going on.

I have found what I believe could be a big problem.

The updates.ini has a section where it will remove previously installed updates from the UPDATE_AVAILABLE variable. This is so the user doesn't see updates that he has already installed.

This section is examining the installedupdates.dat file to get these previous update versions.

Here is the problem.

The installedupdates.dat file is updated as if the current version successfully installed even if it did not, because there is no check in the updates script to verify it was successful.

So the next time it checks for an update it reads the installedupdates.dat which happens to have the last update version in there and the user will NEVER get the current update.

To me there needs to be a check that the update completed successfully before calling the following command:
The command that runs just before the write into text file is:
There is a flag to store a return value... what values can the update return for me to check?

I am guessing I need to alter the various Terminate Installation commands in the primary installer (not updates) so that it returns a code?

I don't think a code is returned by default is it?

A plain Terminate Install returns 0.

I'll have to investigate the nature and severity of this problem next week.

Developers insist you should be able to define your own return codes.

If you're able to reproduce any "pre-defined" return codes, it would be helpful to know how you did.

mills wrote:Developers insist you should be able to define your own return codes.

If you're able to reproduce any "pre-defined" return codes, it would be helpful to know how you did.

It looks like the original setup.exe is indeed returning 0 when completed and non 0 if I cancelled or it failed. I did not use any terminate with code commands... it was just the standard terminate withing the main setup. So some how it is returning codes in the run program reference above.

All I did was tell it to capture the return code and then I examine the result before I write into text file.

Here is a SECOND big problem.

I install the first version and it creates a GUID based folder under C:\Documents and Settings\All Users\Application Data. For example: {6D803930-319F-4A8D-B24D-94A1E28279F4}

I run the next version (full update) and it places the installupdates.dat into the existing GUID Folder {6D803930-319F-4A8D-B24D-94A1E28279F4} and it created a new GUID folder for the new product version {074359B1-6A63-4FFC-A9D7-1297BC22A413}.

Now if do an uninstall of the program at this point it changed the GUID Folder {074359B1-6A63-4FFC-A9D7-1297BC22A413} to ~0 and it left the original GUID Folder {6D803930-319F-4A8D-B24D-94A1E28279F4} which contains the original installupdates.dat.

So now what can happen is if the original version is installed again it still references the same original GUID Folder of {6D803930-319F-4A8D-B24D-94A1E28279F4} which contains the installupdates.dat which contains the value of the update that was previously done before the uninstall. So now the user will never get the update, because of this files existence. The update check basically thinks the user already has the update since the update version is still in that file from the original update prior to the uninstall.

I hope that makes sense. I am not sure how no one else is having this issue, but I have tested it many times over and it is a problem that could bite someone.

Greg

The problems:

Return codes: I'll have to see if we can collect a list of "predefined" return codes. I think this deserves a post of its own. In the mean time, since it sounds like any return codes you've seen are less than 100, wouldn't it make sense for you to generate your personalized return codes in a larger range (like maybe 10,000+)?

Updates: Are there two distinct issues being discussed related to updates or just the dat file? I'm going to explore this tomorrow...

I made an extra project just for the updater. I took the updates script and placed it in a new project. I do not install files with this new updater and so the updater is separated from my setups. The updater is called by the application itself and gets the version from the calling application and looks for this version in the updates.ini. You have to unpack the updater and call it with /update to avoid the two startscreens.

Greg,

Would alibaba's suggestion suit you? If not, would you be able to submit a sample project that exhibits the issue?

mills wrote:Greg,

Would alibaba's suggestion suit you? If not, would you be able to submit a sample project that exhibits the issue?

Perhaps alibaba could send me an example of what he is done so I am not guessing...

As to getting you a sample project. I can, but I am slammed under the gun so it will probably be next week.

FYI: The reason I chose InstallAware was suppose to be how simple it is, but I keep running into scenarios that are not simple to do and require me doing a fair amount of script alterations.

I think some of the scenarios I have been testing and wanting should be options within the GUI and installaware should handle the dirty work... This way your customers don't have to become scripting experts or install experts.

I am sure Installaware is still easier than the others... just seems like I can always find the problems or need what appears to be a basic need that is harder to do. Arghh.

alibaba wrote:I made an extra project just for the updater. I took the updates script and placed it in a new project. I do not install files with this new updater and so the updater is separated from my setups. The updater is called by the application itself and gets the version from the calling application and looks for this version in the updates.ini. You have to unpack the updater and call it with /update to avoid the two startscreens.

alibaba... could you send a copy of a project that is doing this?

If I understand you correctly you are doing what I was wanting to do and that is have the application check for the update so the application can initiate it if one exists.

Could you give a bit more detail?