[wix-users] Always do major upgrades

Wed Dec 7 11:56:08 PST 2016

http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html

Actually when you have a look at the docs of the "new" MajorUpgrade-Tag,
even the standard scheduling of RemoveExistingProducts does not rollback
the implizit deinstallation of your product.
"Note that if the installation of the upgrade product fails, the machine
will have neither version installed."

This was another surprise I did not expect.
Crazy sidenote, I found a product that uses the former Upgrade-Tag and
schedules RemoveExistingProducts "Before=InstallInitialize" and it just
works since years.
I tried upgrades and downgrades no issue, but when I try my newly created
MSI package it always fails on downgrade.

Instead of asking myself why the heck my setup cannot downgrade, I ask
myself how the other one does...

Joel Budreau <joel.budreau at gmail.com> schrieb am Mi., 7. Dez. 2016 um
17:55 Uhr:

> If you're looking to always run a full uninstall followed by a full
> install, you can just move the RemoveExistingProducts action before
> CostFinalize in the InstallExecuteSequence.
>
> Be aware, this solution will not support rollback. If the new MSI fails to
> install you will be left with nothing on the machine. You may or may not
> care about this tradeoff...
>
> - Joel
>
> > On Dec 7, 2016, at 7:59 AM, Wolfgang Haupt <haupt.wolfgang at gmail.com>
> wrote:
> >
> > Wow this situation is a bummer.
> > It seems like a very common scenario to me and I can't believe that this
> is
> > not supported by MSI.
> > Maybe I'm just plain wrong and I do things completely wrong.
> >
> > Anyway, thanks for the awesome clarification.
> >
> >
> > Best Regards,
> > Wolfgang
> >
> > Skildum, Mat <Mathew.Skildum at aspect.com> schrieb am Mi., 7. Dez. 2016 um
> > 16:33 Uhr:
> >
> >> Generating new component GUIDs will have no bearing on the issue you are
> >> trying to solve.  MSI will see that the component does not exist, but
> the
> >> file that is installed has a higher version than the one you are trying
> to
> >> install.  You will still have the same case as you described.
> >>
> >> The only way I have found to get around the way MSI updates files, and
> >> create an always overwrite situation like InstallShield supports, is to
> set
> >> a pseudo version.  In fact I took this straight from InstallShield.  If
> you
> >> look at an InstallShield generated MSI where always overwrite was being
> >> used, you will see they set a bogus file version to force the overwrite.
> >> Of course this is based on older versions of Installshield as I have not
> >> generated an MSI using InstallShield for many years.
> >>
> >> Mat Skildum
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
> Behalf
> >> Of Wolfgang Haupt
> >> Sent: Wednesday, December 7, 2016 9:04 AM
> >> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> >> Subject: Re: [wix-users] Always do major upgrades
> >>
> >> Thx for your fast answer.
> >> Would it be an option to always harvest my files with heat in a
> >> create_setup.bat and generate new GUID's for every component?
> >> Reading the MSI-Log it seems, the windows installer takes the GUID of my
> >> component to lookup if it's already installed, or does it take the
> keypath
> >> into account and I really have to change the filedate or version, to get
> >> this right.
> >> Basically this setup is a migration of a very old InstallShield-Setup
> that
> >> uses "always overwrite" utterly often.
> >>
> >>
> >> Skildum, Mat <Mathew.Skildum at aspect.com> schrieb am Mi., 7. Dez. 2016
> um
> >> 15:56 Uhr:
> >>
> >>> MSI does not truly support this type of functionality without some
> >>> hacks to the MSI.  Basically you have create a pseudo "always
> overwrite"
> >>> situation by setting false version numbers on the version components.
> >>> I do this with a post build step where I call a small VBScript that
> >>> updates the file version in the Files table to 99.99.99 or some other
> >>> high value you will never reach for a version.  You can do this for
> >>> all files if you want a global over write, or just for the versioned
> >>> files if they are all you are worried about.
> >>>
> >>> If this has been done, you should be able to upgrade or downgrade if
> >>> no issue as long as your upgrade table id handled correctly.
> >>>
> >>> Mat Skildum
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
> >>> Behalf Of Wolfgang Haupt
> >>> Sent: Wednesday, December 7, 2016 8:22 AM
> >>> To: wix-users at lists.wixtoolset.org
> >>> Subject: [wix-users] Always do major upgrades
> >>>
> >>> Hello,
> >>>
> >>> I think I stumbled across following problem:
> >>>
> >>>
> >>> http://stackoverflow.com/questions/15138731/wix-major-upgrade-not-inst
> >>> alling-all-files
> >>>
> >>>
> >>> https://blogs.msdn.microsoft.com/astebner/2015/11/16/why-windows-insta
> >>> ller-removes-files-during-a-major-upgrade-if-they-go-backwards-in-vers
> >>> ion-numbers/
> >>>
> >>>
> >>> http://stackoverflow.com/questions/4227456/windows-installer-deletes-v
> >>> ersioned-file-during-product-upgrade-instead-of-down?rq=1
> >>>
> >>>
> >>> I basically want to be able to up and downgrade my application from
> >>> whatever versions.
> >>> It's no problem for me that it cannot track files and save some
> >>> installation time, I just want to remove the existing installation and
> >>> then install the "new" (or older) version.
> >>>
> >>> When I read the docs it seems to me if I can use the MajorUpgrade-Tag
> >>> with "AllowDowngrades=yes", but still the installer is checking the
> >>> version of my Components after CostInitialize and keeps saying:
> >>> MSI (s) (9C:34) [15:02:05:904]: Disallowing installation of component:
> >>> {GUID} since the same component with higher versioned keyfile exists
> >>>
> >>> After that it removes my current version and does not install the
> >>> mentioned components anymore.
> >>> This keeps puzzling me since days.
> >>>
> >>> Does anyone have an answer/opinion on this topic?
> >>>
> >>>
> >>> Best Regards,
> >>> Wolfgang
> >>>
> >>> ____________________________________________________________________
> >>> WiX Toolset Users Mailing List provided by FireGiant
> >>> http://www.firegiant.com/ This email (including any attachments) is
> >>> proprietary to Aspect Software, Inc. and may contain information that
> >>> is confidential. If you have received this message in error, please do
> >>> not read, copy or forward this message.
> >>> Please notify the sender immediately, delete it from your system and
> >>> destroy any copies. You may not further disclose or distribute this
> >>> email or its attachments.
> >>>
> >>> ____________________________________________________________________
> >>> WiX Toolset Users Mailing List provided by FireGiant
> >>> http://www.firegiant.com/
> >>>
> >>
> >> ____________________________________________________________________
> >> WiX Toolset Users Mailing List provided by FireGiant
> >> http://www.firegiant.com/
> >> This email (including any attachments) is proprietary to Aspect
> Software,
> >> Inc. and may contain information that is confidential. If you have
> received
> >> this message in error, please do not read, copy or forward this message.
> >> Please notify the sender immediately, delete it from your system and
> >> destroy any copies. You may not further disclose or distribute this
> email
> >> or its attachments.
> >>
> >> ____________________________________________________________________
> >> WiX Toolset Users Mailing List provided by FireGiant
> >> http://www.firegiant.com/
> >>
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>