[wix-users] Always do major upgrades

Wed Dec 7 12:02:06 PST 2016

Make that REINSTALLMODE="amus"

On Wed, Dec 7, 2016 at 12:01 PM, Joel Budreau <joel.budreau at gmail.com>
wrote:

> If you set your REINSTALLMODE to "emus" you should be able to force your
> files to be installed every time, whether upgrading or downgrading. Just
> make sure that you aren't installing any shared components since this
> change would forcefully downgrade another product's shared files.
>
> On Wed, Dec 7, 2016 at 11:56 AM, Wolfgang Haupt <haupt.wolfgang at gmail.com>
> wrote:
>
>> 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-upgrad
>> e-not-inst
>> > >>> alling-all-files
>> > >>>
>> > >>>
>> > >>> https://blogs.msdn.microsoft.com/astebner/2015/11/16/why-win
>> dows-insta
>> > >>> ller-removes-files-during-a-major-upgrade-if-they-go-backwar
>> ds-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/
>> >
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>
>