InstallAware

I am trying to make an update pack for a version of my software. What I would like to do is always have the most recent version be the update for any previous version. To that end I had this updates.ini file:
Anyone with verison 0.0.0.1 gets prompted for 0.0.0.3. But anyone with 0.0.0.2 gets a popup message saying there are no available updates. When I change it to this:
The users of 0.0.0.2 now can get the update to 0.0.0.3. I tried playing with the second updates.ini file and any update named 0.0.0.3 will not get read by 0.0.0.2. I have to name it something like "test" to make it work.

Questions:
1. Is there something about naming updates the way I have that is messing this up? How should it be named to do what I am trying to do?
2. What causes the update to give the popup message "There are no available updates for .... try again later"? Sometimes this message appears, sometimes the update link runs and nothing at all happens.

Thanks

1. I'd run the script in the debugger to see why this behavior is occuring. You should be able to use any kind of variation of update names, for sure.

2. If the updates.ini file cannot be downloaded, nothing happens (you may want to tweak that to display a message that reads like "unable to contact server" or something similar). When no updates are available for the current version, then the other dialog you already encountered is shown.

Thanks for the tip. I started stepping through the debugger and I think the problem is in the installedupdates.dat file. I have been installing/uninstalling/cancelling installs on a test machine and I think somhow the .dat file was thinking I already had the update in question. When I renamed it it would work since it appeared to be a new update. I can't verify this 100% because in the middle of testing I had some website problems and lost all my updates and I can't reproduce the problem.

One other question: Why use the installedupdates.dat file at all? Each update (at least in my case) is going to give the program a new version number so the user wouldn't be able to re-install the same update again anyway. Did you include that in the script for situations where you are updating settings and not changing the program version? If that is the case I'll just remove that section of the script. I just want to make sure you guys didn't include it for some other reason I can't think of right now.

Ok.. I was able to replicate the problem and its kinda odd. Here is how it works.

1. Download version 1 from a website and install.
2. Update to version 2 using the auto-update.
3. Uninstall the application.
4. Go back to the website and re-download version 1 and install (it will use the cache of internet explorer and not re-download the file).
5. Try to update and it stops when trying to read the [Update Packs for Versions] in the INI file and does not find that section of the file.

I'm not sure exactly why it isn't reading the file. I noticed if I force internet explorere to re-download instead of using the cached version it found the update.

You may get tired of me posting on this subject over and over, but I finally know the problem for sure.

1. Install version 1.
2. Update to version 2.
3. Uninstall.

The uninstall removes the files from c:\\Program Data\\{GUID} that were stored with the update to version 2. The Program Data for version 1 is still there... it is never removed afaik. Now if you re-install version 1 it goes back to its original directory in c:\\Program Data\\{GUID} and uses the installedupdates.dat file that is in place there.... preventing it from ever updating to version 2 again. This could be the intended behaviour as far as I know, but it does raise a couple of questions.


1. Even though it is minor, wouldn't this leave a long trail of downloaded and installed files on the users computer? Wouldn't it be better to delete the directory during the uninstall?

2. I think I'm going to remove use of installedupdates.dat from my MSI script. Any adverse affects in doing this that I might not be aware of?