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

[Edwin Castro]

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