InstallAware

Hello
I have been using IA Dev. for about a year now having built a varied range of install routines which have run very well indeed but I've got myself into a corner ...
Scenario : web media block based routine comprising in total 6 WMBs, setup.exe and updates.ini. So far in its existence this routine has been patched 3 times against the 3 previous installers. So far so good ...
Now, for version 4 I have decided that one of the files currently residing in one of the WMBs which contains a group of files I thought I would never have to update , does have to be updated and also this group of files because they are an initial empty database framework are set to never overwrite.
I thought the easiest way to deal with this was to revise my current script by removing this one file from its current WMB and give it its own WMB. Did new web build for new installs and created patch for existing installs. I guess you know what comes next, new installs are fine but any previous installs don't get updated with this new file from the new WMB. What's interesting though is that the required updated file is in the patch (I'm patching a whole file and the size gives it away !).
Then tried much the same thing but putting this file as offline content, thought thats got to work, ... still in the patch but not installed.
If I replace the current client setup.exe with the new one then of course I can force a full uninstall/install but this is very bad because it wipes out a current user's data !
How can I force an existing current installer to recognize this new WMB/OFFLINE CONTENT or whatever form I make it, which is definitely in a patch, which it will definitely download and then install it ? Please any suggestions for suitable jiggery pokery that don't involve complete uninstall/install will be really appreciated because I'm stuck ! ... thanks in anticipation.
Pete B.

I think i understood correct what you want to do, so here it's a solution it might work.

You can create a NEW installer, that does not create an ARP entry (not shown in Control Panel/ Add Remove programs) that will REPLACE the files you want and then prompt your users to download the latest web install setup file (which will not uninstall the old version).

Gizm0 : thanks for the really quick reply, very much appreciated. I think I basically understand where you are coming from with this and I know I presented a fairly complex scenario.
I guess I could knock out the ARP entry by calling DeleteRegistry for the appropriate subkey immediately after ApplyInstall in this 'custom' additional installer but I'm a bit lost as to how, if this new installer is the one a user gets as an update (patch) + prompt, how I then lead them on to the latest actual software update ...
Anyhow, on reflection, I'm absolutely certain that whatever I do given this unfortunate situation, it is going to be something of a kludge. So with that in mind, for info, I think I will probably actually force the software to throw an exception if it doesn't find this new file, handle it and display a nice friendly prompt in the software telling them to download the file before the software can continue.
Obviously completely new installs get the file already split from its old WMB into a new one, so they are not an issue.
I think that's about as 'friendly' as I can make it given the circumstances and it means there will not any 'oddball' installations kicking around to clutter up the MSI database.
Thanks again for the help, barring any forthcoming revelations which allow totally seamless integration of my exact requirements in a nutshell ... I guess that's it.

Pete B.

OK, here it goes:

* New installer: A single self extracting installation that replaces the files
* New Install File: The update (version 4) installer with correct WMBs

1) Create a new Installer containing the files to be changed and add a web update reference to your NEW install file (containing the correct WMB) and place the updates.ini to you webserver (don't overwrite the previous one, create a new folder an place it there).
2) Mark it (the new installer) as an update on your current application, so the user's will be prompted to download it
3) Make your users install it and at the end of the install , run the $UNINSTALLLINK$ /update. That will force the newly updated file, to download your NEW Install File, with the correct WMB.
4) When the new install file get's downloaded (with correct WMB) it will find the older installation and prompt for repair install, uninstall etc etc.
If a repair install is NOT destroying user's settings, make a repair install otherwise let your users know, that they will need to cancel this action.

With the above scenario you achieve:
1) To install the latest files
2) To download the latest/correct web install file for your users to have

To remove the ARP entry, search this forum, there are a lot of different approaches on how to do it. There is a thread where a user reports that OLD ARP entries are staying when new versions with different package names get installed. Read it and you'll find your solution in there.

Gizm0 : sincere thanks for this 'plan of action'. I studied it carefully and produced an installer, trialled it and scrapped it ... sorry, but in operation it was, well ... a little inelegant I'm afraid. Where you said ...

If a repair install is NOT destroying user's settings, make a repair install otherwise let your users know, that they will need to cancel this action.

I just have this horrible gut feeling that users would just screw that up big time and my support inbox would be full of "your latest update has lost all my data" !
FWIW I have forced the program to throw an exception on not being able to find the updated file (Ok, I know that's not exactly elegant either but 'any port in a storm'). This is discretely disguised as a ... "Dear user, you really need to get an updated copy of this file don't you ?" prompt
Thanks again, all the best

Pete B.

Well, Pete.. At least you found a solution.. That's something, isn't? [:P]