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

Fri Aug 12 17:21:07 PDT 2016

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.aspx
> >
> > 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/
>