Software Deployment

You need to read this thoroughly

http://msdn.microsoft.com/en-us/library/aa370579(VS.85).aspx

and if you're doing a major upgrade, you need to include the former's upgrade code in the latter's Upgrade table and the sequence as mentioned.

based on ur scenario, i would say that if an application updates regularly, then you should always use a patch that applies to the main MSI. Google it for more info....

and if u were upgrading a currently installed app, then you should always make sure the Product Code of the new MSI is not same as the old (installed on clients). Google more on MSI Upgrades but basically the product code of the old MSI should be present in the Upgrade table of current MSI and in the Install Execute table, the action RemoveExistingProduct should be in between InstallValidate and InstallInitialize.....of course if the old version of the product is 3.4.22.08 then you should increase it in the new version to 3.4.22.09 or more depending on u....you may also want to enable MigrateFeatureStates,,,,

of course another way would be to create a batch file or vbscript that runs the Msiexec /X product code before the installation of the new MSI...

i would recommend the upgrade table though....

but basically the product code of the old MSI should be present in the Upgrade table of current MSI

I'm sure you meant the Upgrade code of the old MSI should be in ...

Firstly, depending on a number of variables (changed msi-file name, new features, new components...) you can choose a Minor, Major or Small upgrade in your MSI, the full rundown of variables and what to change can be found here.


Basically changing the product code makes it so Windows Installer doesn't "see" that the older versions are actually the same application (no repair dialogs on an msiexec /I). As you read above you can leave it unchanged only under pretty strict conditions.
The upgrade code (which you're best off leaving the same between versions) will be used to check which applications need to be upgraded. You could probably just always put the version of your latest package in the VersionMax, leave the VersionMin blank and all lower versions will be upgraded.

By placing the RemoveExistingProducts action between InstallValidate and InstallInitialise, your MSI will first uninstall the previous version before your new package gets installed. If you put it later in the sequence Windows Installer will handle the upgrade differently. For more info on the sequencing of this action and differences in behavior, have a look here.


PJ

Thank you both packageExpert and PJ. As I read your posts am I correct in seeing that its either an upgrade/patch or a total uninstall you are discussing. Changing the product code/version number/ in the former produces an upgrade, and putting the RemoveExistingProducts action between InstallValidate and InstallInitialise in the latter instance uninstalls ALL? previous versions.

Thanks PE. Its all quite complicated, but my understanding is enhanced now...thank you.

We are in fact running msiexec /x before the package is deployed, but the upgrade table is cleaner and we have implemented that. Some of the old versions are not being removed either by script or the upgrade table, and based on what you have stated this is I assume because the developers have changed the upgrade code(s), and subsequently the new app isnt seeing the older versions?

I cant see how we can 'fix' that without rebuilds. And for now to ensure future stability we are ensuring product codes, version numbers, package codes are changed where applicable, and the upgrade table is populated.

Thank you.

I cant see how we can 'fix' that without rebuilds.Er...have you read that article? You just need to add the details of the other version to the Upgrade table. http://msdn.microsoft.com/en-us/library/aa372379%28VS.85%29.aspx

Thank you VBScab

Yes I have read the article and I know what to do thank you. But if you had read my last posting you would know we do not know in every instance what the changed upgrade codes are.....'Some of the old versions are not being removed either by script or the upgrade table..because the developers have changed the upgrade code(s), and subsequently the new app isnt seeing the older versions?'

Quoting from that article http://msdn.microsoft.com/en-us/library/aa372379%28VS.85%29.aspx
....'Each record in the Upgrade table gives a characteristic combination of upgrade code, product version, and language information used to identify a set of products affected by the upgrade.'

Apologies...

In that case, you clearly have no choice: just uninstall them.

Thx VBS.

This is a bit old but you need to be aware of one thing that this "major 2" type upgrade does:

If newer package has older binaries (.exe etc needed to be downgraded) upgrade process checks those binaries and will not install them (MSI thinks it is replacing them with older versions of the file), but those files will be removed by RemoveExistingProducts action. This can be avoided by using REINSTALLMODE=amus (default is omus).

No need to do that if your new package has newer binaries, but in case you run into this and wonder why does my package do repair-install when I open it first time that might be the cause.

Thanks Timo

Clear and useful.