In common with a lot of build processes ours uses a 4 part version number, major.minor.day.revision, in a given day the revision can change if the developers rebuild but the shipping product would never have the same major.minor.day version. This causes a problem with Windows Installer major upgrades because it only uses 3 part versions numbers to detect upgrades. I would like to perform a major upgrade even if only the revision changes and think I have found a way but would be interested in any issues it may cause.
RemoveExistingProducts is scheduled after InstallValidate, so the product will be removed before anything new is installed. The upgrade code is: <Upgrade Id="$(var.UpgradeCode)"> <UpgradeVersion Minimum="$(var.Version)" IncludeMinimum="no" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" /> <UpgradeVersion Minimum="0.0.0" IncludeMinimum="yes" Maximum="$(var.Version)" IncludeMaximum="yes" Property="PREVIOUSVERSIONDETECTED" /> </Upgrade> The key here is that PREVIOUSVERSIONDETECTED has IncludeMaximum="yes", this will generate ICE61 but will allow upgrades will the same version number. NEWERVERSIONDETECTED is set with IncludeMinimum="no" so that the newer version detected launch condition on triggers if the build is from a new day. This works but is it a really bad thing to do? Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
