[:D]
Hi

We have a recurring problem with an inhouse developed MSI. This app is updated on a regular basis so we are deploying to our user base similarly regularly. If a user has older versions of the application the install will fail to start. We suspect there are issues with file versioning because the Upgrade Code and the Product Codes are set correctly, and on a clean PC with no previous versions the install is fine.

At present to fix this problem on those affected PC's we manually remove old versions as a work-a-round, which of course is time consuming and expensive. Can anyone advise how to remove all previous versions of an application (MSI deployed) without knowing the individual Product Codes, and/or better still a way to identify/error check to ascertain correct file versioning changes in an MSI.

I know the developer should sort out there act, but I suspect they may have lost track of some of their files in this package to the point where a new version may have older file versions than a previous version.

Any help is appreciated for this my first post. Thanks guys!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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....
Answered 10/28/2009 by: PackageExpert
Blue Belt

Please log in to comment
0
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
Answered 10/28/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
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.
Answered 11/02/2009 by: krpa
Senior Yellow Belt

Please log in to comment
2
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.
Answered 11/02/2009 by: PackageExpert
Blue Belt

Please log in to comment
0
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.
Answered 11/04/2009 by: krpa
Senior Yellow Belt

Please log in to comment
0
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
Answered 11/05/2009 by: VBScab
Red Belt

Please log in to comment
0
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.'
Answered 11/05/2009 by: krpa
Senior Yellow Belt

Please log in to comment
0
Apologies...

In that case, you clearly have no choice: just uninstall them.
Answered 11/06/2009 by: VBScab
Red Belt

Please log in to comment
0
Thx VBS.
Answered 11/08/2009 by: krpa
Senior Yellow Belt

Please log in to comment
0
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.
Answered 11/19/2009 by: TimoP
Orange Belt

Please log in to comment
0
Thanks Timo

Clear and useful.
Answered 11/19/2009 by: krpa
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity