[wix-users] Updates with Major.Minor.Build.Revision needed

[Edwin Castro]

We use four quad versions for file and product versions at the file
level and in our bundle (Bundle/@Version). We compute a three quad
version for MSI (Product/@Version) in our build script.

We use the following formula for our MSI Product/@Version:

ProductVersion.Major = BundleVersion.Major
ProductVersion.Minor = BundleVersion.Minor
ProductVersion.Build = 10000 * BundleVersion.Build + BundleVersion.Revision

This places some limitations on the range for BundleVersion.Build and
BundleVersion.Revision but those limitations are acceptable for our
releases.

Perhaps a similar translation would work for you.

--
Edwin


On Wed, Aug 10, 2016 at 6:16 AM, David Connet
<dcon at agilityrecordbook.com> wrote:
> Or version the MSI differently... I'm dealing with creating an appxbundle
> for the winstore for Centennial - that (currently at least) uses x.y.z.0.
> The 4th part must be 0 (no idea why, but it fails verification if you
> don't).
>
> So my strategy is to map the EXEs 4th quad to the package's 3rd. Since the
> 4th is also our build number, that means 1.2.3.4 and 1.2.5.7 will work.
> (Where it fails is if we had to release 1.2.3 after a 1.2.5 - luckily we
> don't do that.)
>
> Dave
>
>
> On 8/10/2016 5:07 AM, Magi, Sampattakumar S wrote:
>>
>> Can't we do,
>>
>> 1. write version to registry during install
>> 2. write simple CA to compare all versions bits and warn if lesser than
>> current?
>>
>>
>>
>> -----Original Message-----
>> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
>> Of Phill Hogland
>> Sent: Wednesday, August 10, 2016 5:33 PM
>> To: 'WiX Toolset Users Mailing List' <wix-users at lists.wixtoolset.org>
>> Subject: Re: [wix-users] Updates with Major.Minor.Build.Revision needed
>>
>> In general your build system does not need to change and your binaries can
>> continue to use all four quads of a version string.  File level version
>> comparison is based on all four quads ((Major.Minor.Build.Revision).
>>
>>
>> If you use a WiX Burn bootstrapper project to chain multiple MSIs (or EXE
>> packages) then the Bundle/@Version, displayed in the ARP as your 'product'
>> version can also use all four quads (Major.Minor.Build.Revision).
>>
>>
>> MSI only uses the first three quads for the MSI package's version (Wix
>> attributet Product/@Version), which you can implement in the MSBuild targets
>> related to your .wixproj without affecting the rest of your build process.
>> If using this 'first-three quad' version is what you are trying to avoid,
>> (even if you did not have to change the rest of your build system).  Good
>> luck!  In that case don't try to use MSI, find a different deployment
>> technology.  But the better path is to use MSI and conform to the MSI
>> versioning rules which generally does not mean that you need to change
>> existing build processes for your other binaries or the displayed product
>> version which you reveal to a user.
>>
>>
>>
>> ________________________________
>> From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of
>> Steffen Vogel <codedevbird at gmail.com>
>> Sent: Wednesday, August 10, 2016 6:43:50 AM
>> To: 'WiX Toolset Users Mailing List'
>> Subject: Re: [wix-users] Updates with Major.Minor.Build.Revision needed
>>
>> Thank you for your response.
>>
>> Could you please explain to me what you mean with "Install higher
>> verision,
>> trigger lower version msi, leave it as." ?
>>
>> I think the WIX_DOWNGRADE_DETECTED could help me a lot, thanks for that.
>>
>> Best regards,
>> Steffen
>>
>> -----Ursprüngliche Nachricht-----
>> Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag
>> von Magi, Sampattakumar S
>> Gesendet: Mittwoch, 10. August 2016 12:58
>> An: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> Betreff: Re: [wix-users] Updates with Major.Minor.Build.Revision needed
>>
>> Install higher verision, trigger lower version msi, leave it as. Open the
>> log check ,
>>
>> 1. FaindRelatedProducts
>> 2. WIX_DOWNGRADE_DETECTED
>>
>> If this prop is being set, then
>>
>> 3. Write CA to warn user , use above prop
>>
>> Sampat
>>
>> -----Original Message-----
>> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
>> Of
>> Steffen Vogel
>> Sent: Wednesday, August 10, 2016 4:02 PM
>> To: wix-users at lists.wixtoolset.org
>> Subject: [wix-users] Updates with Major.Minor.Build.Revision needed
>>
>> Dear WIX-mailing list,
>>
>>
>>
>> I am working on an installer that installs our companies products. As we
>> only use the 4th version, (for example 1.0.0.123 or 1.0.0.345) in our
>> buildsystem, I was explicitly told to make the installer work with it so
>> we
>> don't have to change it (all our products are doing this).
>>
>> It should upgrade older versions and, if not preventing it which would be
>> the best, at least should warn if you are going to do a downgrade.
>>
>>
>>
>> As I don't know how to trigger the updates etc. manually, and do not
>> really
>> want to do this stuff manually, I am using the MajorUpgrade-tag in the
>> installers:
>>
>>
>>
>> <MajorUpgrade DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
>>
>>                   AllowDowngrades="no"
>>
>>                                   AllowSameVersionUpgrades="yes"
>>
>>                   Schedule ="afterInstallInitialize" />
>>
>>
>>
>> This handles the updates really fine but allows downgrades if only the 4th
>> version differs, which is not good.
>>
>> I am now searching for a possibility to prevent users from doing a
>> downgrade.
>>
>> Additionally, I before used the <Upgrade>-tag with <UpgradeVersion> which
>> filled me some properties (,NEWERVERSIONDETECTED',
>> ,OLDERVERSIONBEINGUPGRADED' or ,SELFFOUND') depending on what was going
>> on.
>>
>> With using the <MajorUpgrade>-tag, these aren't getting filled anymore and
>> my conditions won't work anymore as expected.
>>
>>
>>
>> Now I am asking you to please help me find a good solution in which the
>> installer uses all (Major.Minor.Build.Revision) for version comparison,
>>
>> which prevents downgrades with a specific error message and tells me
>> what's
>> going on via properties or something so I can schedule my actions
>> depending
>> on that.
>>
>> Or is there any better idea???
>>
>>
>>
>> Any help is strongly appreciated!!!
>>
>>
>>
>> Many many thanks,
>>
>> Steffen Vogel
>>
>>
>>
>> Note:
>>
>> I tried to write my own custom action that could take a path to a file and
>> the current installers version and gets the files version from it, so we
>> have something to compare.
>>
>> With this custom action I can set properties like ,NEWERVERSIONDETECTED',
>> ,OLDERVERSIONBEINGUPGRADED' or ,SELFFOUND'. If I find a new version for
>> example, I will set ,NEWERVERSIONDETECTED' to ,1'.
>>
>>
>>
>> But I don't know if it's really good / safe and how to schedule it
>> correctly, I think is has to run before the Welcome dialog is being
>> displayed but I am relatively new to WIX and don't know enough about
>> sequences in WIX.
>
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/