'installedupdates.dat' is not saved in the right place: Bug?

[JohnO]

After applying an update (say MyApp1.0 is updated to MyApp1.1), an 'installedupdates.dat' is created with the correct contents, but it is in C:\ProgramData\{GUID-for-MyApp1.0}. This means that when I select the Update shortcut for MyApp1.1 I am presented with the contents of the updates.ini on the web site - showing that MyApp1.1 is available. This must be wrong.

If I copy the 'installedupdates.dat' to C:\ProgramData\{GUID-for-MyApp1.1}, then I am told correctly that there are no updates available.

I searched this forum for 'installedupdates.dat' and I found a number of entries on this topic. The closest appears to be: http://www.installaware.com/forum/viewtopic.php?f=6&t=1906. However, this was reported in 2007, and looks like a bug being reported to me. I am puzzled as to why it hasn't been fixed. Unless, there is something I have missed.

In addition, it means that C:\ProgramData\{GUID-for-old-apps} never gets deleted, when an app is updated.

It then occurred to me that with this design, if I uninstalled MyApp1.1 and then reinstalled it, there wouldn't be a 'installedupdates.dat' and so, a user would be offered the opportunity to update MyApp1.1 to MyApp1.1. I have just tried this and that is what happened.

My conclusion is that the design is wrong, and has been for many years. Yet that doesn't make any sense - IA wouldn't leave such a silly bug in the product. Which leaves me 'dazed and confused'.

What I think would work is to put 'installedupdates.dat' into C:\\ProgramData\{GUID-Product-Code}. This would be permanent across all versions. I create such a folder to store a 'memento.ini' file that holds the location that the user selected for their 'workspace' (I added a new dialog based on the install location one). This is done in order to prompt them to reuse it during an update.

I will have a look to see if I can understand the code in the 'updates' script and change the location from EXEDIR to {GUID-Product-Code}, and see if that works... or not.

Regards, John

[FrancescoT]

Dear John,

before coming to hasty conclusions, I may suggest you to verify why the opportunity to update your installed product, in your case it is offered even if not opportune.

Are you sure that your update is correctly associated to the most appropriate version of your application family?

Regards

[JohnO]

Dear Francesco
My current project is MyApp2.2. I don't actually have a new project for MyApp2.2.1 - for testing purposes, I followed the white paper for updates, and just regenerated 2.2, with an Update Pack that defines MyApp2.2.1.exe and links it to Version 2.2 as its update.

After deploying the newly generated installer (= the update for 2.2) to my web server, I renamed the exe from MyApp2.2 to MyApp2.2.1, so that the Update processing will find and download it.

That all works fine, until after the completion of the update, and we come to near the end of the 'updates' script

Code: Select all

 
Run Program $SUPPORTDIR$\$UPDATE_NAME$.exe $UPDATE_PARAMETERS$ $SILENTVAR$ REBOOTCOMPUTER=FALSE RUNAPP=FALSE REBOOTNOW=CANCEL (WAIT)
  if Variable UPDATE_LOG Equals TRUE
     MessageBox: Debug - updates: writing instaledupdates.dat to EXEDIR, content = $UPDATE_NAME$$NEWLINE$exedir = $EXEDIR$
      Write into Text File $EXEDIR$\installedupdates.dat from Value $UPDATE_NAME$ (at end of file)
  end


At this point, the value in EXEDIR is "Program Data\{GUID-of-previous-version}", which is why 'installedupdates.dat' ends up there instead of in "Program Data\{GUID-of-updated-version}. So, when I repeat the process, the Updater doesn't know that the update has been installed.

I attach screen captures of the two folders in Program Data. You can clearly see that the timestamp for 'installedupdates.dat' is later than the timestamps for the files in the folder for the new version.

This also begs the question - why is the old folder not removed? I can't see that the old mia.lib and MyApp.exe are still required.

The only change to the updates script, in this version, is the addition of some MessageBoxes to show values when running.

I have an alternative version where I write out the 'installedupdates.dat' to a folder I already create called "Program Data\{product-code>" which is consistent across versions and never deleted until the app is uninstalled.

Regards, John

[JohnO]

A bit more info to shed some light on this.

I have added MsgBoxes at the end of the 'updates' script, and at the end of the 'main' script. Main displays the correct value for $UNINSTALLLINK$ - the {GUID} referring to the folder in 'Program Data' for the newly installed version.

Whereas, at the end of 'updates', a MsgBox shows that for: EXEDIR, UNINSTALLLINK and ENGINECACHE, the {GUID} party in all of them, refers to the folder in 'Program Data' for the previous version (i.e the one that has been removed and replace by the new version).

This is why I contend there is a bug - the 'updates' s cript writes the installedupdates.dat to the old folder, when it should be written to the new one.

Regards, John

[FrancescoT]

Dear John,

I am sorry, but I really believe that you missed some important aspects of the update process.

When you make available an update for a specific package version, this have to be specified with the version property for the served Update pack.
The version field must match the version of the already installed setup package (... the exact value you entered with the Product version property of the project), in order to have it recognized as a an update for the installed setup. You can't only change the output file name to have it recognized as a different version.

In other words you are having this problem, because the package that you install as update in reality it is not an effective update.,
It installs your previous application version and this is the reason why, when your run your update process once again, this is not recognized as installed.

To verify the update process correctly;

- create a new project from scratch, enable the WEB UPDATE Feature, define the URL used by the update process and assign to it the version 1.0 in project property.
- Build the project and install it on a target machine.
- Go back to the project, change the product version to 2.0, define the update pack and assign it as update for version 1.0.
- Build the project, place the generated UPDATE.INI along with the new generated version 2.0 setup exe to your update server URL
- From you target machine run the update process, verify the availability of the update and the proceed to install it.

Finally if you try to execute the update process from your target machine once again ... I am sure you will not find any update available, because your version 2.0 is currently installed.

I really hope that this clarify your doubt.

Regards

[JohnO]

Dear Francesco
Many thanks for your patience. My mistake was not changing the version value from 2.2. to 2.2.1. There was nothing I could see in the scripts that referred to the version.

Now, after update 2.2 to 2.2.1, when I look for another update, I get the message that none are available.

However, my researches on which folder the 'installedupdates.dat' is written to, do appear to be correct. That file is written to Program Data\{GUID for v2.2}. However, the check-for-updates function in 2.2.1 must be finding it in that (2.2) folder, otherwise it would tell me that updates are available.

My mistake was making the assumption that installedupdates.dat should have been written to Program Data\{GUID for v2.2.1}. Though that does seem to be the logical location.

This became an issue because we want our application to check for updates when it starts, and prompt the user (avoiding the UAC change windows? prompt), until we know there is an update. In order to make the check I need to know the location of installedupdates.dat. I guess as long as it's consistently in the {GUID for previous version folder}, I can write that location to my config.properties file.

I apologise for using up so much of your time due to my invalid assumption about the placement of the installedupdates file.

Regards, John

[FrancescoT]

No problem !

Regards