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

Mon Aug 15 23:17:14 PDT 2016

Hello guys,

I'm terribly sorry that I could only respond just now and not earlier. 

I really appreciate your effort you made to make this clear to me and the
others and to help me find a proper solution. Thanks!

You could indeed convince me that using the three quads instead of the four
is the proper way of doing it.
Sadly, I could not convince my boss to switch the installer to another
product version but he said to me that it (the fourth quad) will only be
used for internal purposes and, when a customer gets the installer that it
will be one that has been incremented in the build quad. So I think it's
okay for me, although I'm not entirely happy with that.

Again, many, many thanks to you!

Best regards,
Steffen

-----Ursprüngliche Nachricht-----
Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag
von sampat magi
Gesendet: Samstag, 13. August 2016 02:21
An: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Betreff: Re: [wix-users] Updates with Major.Minor.Build.Revision needed

Omg!!! I have wasted your time unnecessary!!! Now rhe sin is one me , :(
:-(... I apologize for that!!!

Yes. Edwin. I didn't raise the question originally!!!

I can understand and agree  with whatever you explained and its very
straight, clear,and true.

I use only 3 quads for our product on major upgrades( sorry for using the
word patch here, again confusing).

Since he didn't ask about upgrades i just had a thought on displaying custom
error msgs for only downgrade scenario at its simple way.

I agree with you, that, the question is completely discouraging the msi
standards!!!

I hope, thus shouldn't have dragged us till here. I am really sorry about
that!!!

Take care

Sampat

On 13-Aug-2016 2:09 am, "Edwin Castro" <egcastr at gmail.com> wrote:

> I just realized that Sampat Magi is not the original poster, Steffen 
> Vogel. That probably explains why ProductVersion seemed to have 4 
> quads and 3 quads. I got confused on who I was responding to and whom 
> they were responding to.
>
> The reasons I mentioned my previous email are still valid and I hope 
> to convince the original poster to ensure the first three quads for 
> ProductVersion change so that their major upgrades work as expected.
>
> --
> Edwin G. Castro
>
>
> On Fri, Aug 12, 2016 at 11:54 AM, Edwin Castro <egcastr at gmail.com> wrote:
> > You've completely lost me.
> >
> > On Fri, Aug 12, 2016 at 7:50 AM, sampat magi <ssmcs060 at gmail.com> wrote:
> >> Ahh!! Something is bringing miscommunication!!!
> >
> > Agreed!
> >
> >> I am thinking on the second part of the original question, which 
> >> goes
> like
> >> this,
> >>
> >> 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,
> >
> > This sounds like your ProductVersion has four quads:
> >
> > ProductVersion = Major.Minor.Build.Revision
> >
> > This format is accepted by the Windows Installer *BUT* 
> > ProductVersion comparisons will ignore the fourth quad. You cannot 
> > change this behavior.
> >
> > The Upgrade table performs this comparison for you and can be used 
> > to set a property to tell you if you're trying to perform a downgrade.
> > The <MajorUpgrade/> element will automatically configure the Upgrade 
> > table to perform this check for you.
> >
> >> 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.
> >
> > The <MajorUpgrade/> element will produce a LauchCondition that 
> > prevents downgrades by inspecting the property created by the 
> > Upgrade table when a downgrade is detected. This uses the 
> > ProductVersion comparison that Windows Installer performs which only 
> > compares the first three quads.
> >
> > So you get this behavior for free when you follow the Windows 
> > Installer
> rules.
> >
> > You seem to want to ignore the automatic downgrade protection 
> > offered by <MajorUpgrade/> because it only compares the first three 
> > quads of ProductVersion. You want to perform your own comparison so 
> > that you can compare all four quads and schedule your actions 
> > depending on the results of your own comparison...
> >
> > Creating such a custom action to perform that comparison is doable 
> > and fairly trivial. You get a property, parse the property, compare, 
> > set property based on comparison result. Custom actions really do 
> > not get easier than that.
> >
> > BUT you only need this comparison IF, AND ONLY IF, you have a 
> > scenario where the first three quads are the same. All other 
> > scenarios are automatically captured by <MajorUpgrade/>.
> >
> > When the first three quads are the same, you are no longer 
> > performing a major upgrade. In fact it is unclear what you are actually
doing.
> >
> > Take a look at the table describing the different types of updates 
> > at 
> > https://msdn.microsoft.com/en-us/library/windows/desktop/aa370579.as
> > px
> >
> > The "Changed" value for the ProductVersion column corresponds to the 
> > three-quad comparison done by Windows Installer. This is the 
> > behavior you cannot change.
> >
> > You've changed the ProductCode (otherwise it wasn't going to be a 
> > major upgrade anyway) but you have NOT changed the ProductVersion.
> > This row does not exist on the different types of updates table. The 
> > reason the type of update matters is that it dictates which kinds of 
> > changes are allowed.
> >
> > You keep asking about detecting the "downgrade" scenario. That's 
> > wonderful but what about the "upgrade" scenario? When you're 
> > upgrading from 1.2.3.4 to 1.2.3.5? Those are both the same 
> > ProductVersion to the Windows Installer. I believe the Windows 
> > Installer tries to reconfigure your product even though the 
> > ProductCode changed! You're very likely not going to get the 
> > behavior you want and/or expect mostly because you're in undefined
space.
> >
> >> Or is there any better idea???
> >
> > Yes. The better idea is make sure ProductVersion will always have a 
> > proper three-quad change between major upgrades. There are many 
> > strategies on how to ensure a proper three-quad change between major 
> > upgrades BUT they all require that the first three quads change 
> > because the four quad is ignored if it exists. You can't change this.
> >
> >> My thought was to have type 19 CA to display appropriate downgrade 
> >> error message using version read from registry into a property!!
> >
> > Sure, using a type 19 CA to display an error message is an easy way 
> > to communicate with your user. A LaunchCondition is properly better. 
> > But this is beside the point. The "downgrade" case is not really of 
> > concern because you're trying to avoid it (as you should). The 
> > problem is with the opposite case where you are trying to upgrade 
> > even though the Windows Installer does not recognize the scenario as 
> > a valid upgrade.
> >
> >> Yes, we should Windows Installer rules and standards to avoid 
> >> additional overhead!!!
> >
> > This is not about overhead. It is about correctness, reliability, 
> > and reproducibility. You're not going to get any of those if you 
> > allow upgrades when only the fourth quad has increased.
> >
> >> We differentiate our products patches with 3 version fields.
> >
> > ... huh!? ... Are you using four quads or three? Which is it?
> >
> > What do you mean by product patches?
> >
> > Are you saying you're creating MSI with four quad ProductVersion but 
> > then trying to "patch" with MSP that only has three quad 
> > ProductVersion?
> >
> > Or are you saying ProductVersion always has three quad 
> > ProductVersion regardless of whether you've created an MSI or MSP?
> >
> > Or are you trying to say something else?
> >
> > You should note that you can package small updates, minor upgrades, 
> > and major upgrades in MSP and/or MSI packages. The extension does 
> > NOT determine whether you're installing a "patch" or an "upgrade". 
> > The different types of updates table linked above determines the 
> > type of update regardless of extension.
> >
> > I'll say it again because it is important. The package extension 
> > does not matter. PackageCode, ProductCode, and ProductVersion are 
> > what matter in determining what type of update will occur.
> >
> > Hopefully, I've done a better job giving you a taste for why you're 
> > headed down the wrong path. The problem isn't performing the 
> > comparison or doing something with the knowledge that the fourth 
> > quad in ProductVersion decreased ("downgrade"). Those things are
trivial.
> > The problem is what happens when you allow an "update" when the 
> > fourth quad in ProductVersion increased. The Windows Installer will 
> > not detect that scenario as a major upgrade and you will not get 
> > what you want or expect. It will not be correct. It will not be 
> > reliable. It will not be reproducible.
> >
> > But if you think you know better (and my you I mean your boss), then 
> > feel free to do what you want. You were warned. Good luck!
> >
> > --
> > Edwin G. Castro
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/
>

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