[wix-users] Updates with Major.Minor.Build.Revision needed
egcastr at gmail.com
Fri Aug 12 13:39:14 PDT 2016
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!!!
>> I am thinking on the second part of the original question, which goes like
>> 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
> 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
> 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 188.8.131.52 to 184.108.40.206? 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
>> Yes, we should Windows Installer rules and standards to avoid additional
> 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
> 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
More information about the wix-users