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

Wed Aug 10 05:07:47 PDT 2016

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/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant
http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/