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

Thu Aug 11 23:06:10 PDT 2016

@David Connet, Thanks for the great idea with a different version format for
the MSi, but unfortunately I can't do this because of my boss.

@Phill Hogland, "which you can implement in the MSBuild targets related to
your .wixproj without affecting the rest of your build process." - could you
please give me an example what I can implement? I think I do not understand
it correctly. (I'm not that good in English)

For now I chose the suggestion from Sampat because it does fit my
requirements the best and I hope that it is relatively easy to implement.
I will inform you if it works, thanks :)

Steffen

-----Ursprüngliche Nachricht-----
Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag
von David Connet
Gesendet: Mittwoch, 10. August 2016 15:16
An: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Betreff: Re: [wix-users] Updates with Major.Minor.Build.Revision needed

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/