[wix-users] Previous package not found (and therefore not uninstalled) during major upgrade

[Steve Sanders]

Thanks for looking at the logs, I appreciate it. I saw the insufficient
privileges entry you cite, but again, it is very infrequent, and I think
that is more related to a failure to close the running program, which is a
result of failing to detect the previous installation. Again, why would
the  WIX_UPGRADE_DETECTED and  UPGRADINGPRODUCTCODE properties be set only
sometimes, with seemingly identical circumstances? In the upgrade case,
custom actions are run to shut down our processes, but the conditions to do
so don't seem to be reliably detected.

We shipped nearly the same installer with dozens of major upgrades to
thousands of customers with Wix 3.9 and never saw this.

On Mon, Feb 19, 2018 at 3:11 PM, Steve Sanders <steve at keyba.se> wrote:

> Answered below, but if any of that were wrong, upgrades would never work,
> would they? They nearly aways do, except 1 out of every 10 or 20 times.
>
> WixStdBA: https://github.com/keybase/client/blob/
> 5e5798149e1c6e5de7900319be70a602308dfbba/packaging/windows/
> WIXInstallers/KeybaseBundle/Bundle.wxs#L23
>
> MIS:  <MajorUpgrade DowngradeErrorMessage="A newer version of Keybase is
> already installed." AllowSameVersionUpgrades="yes" />
> https://github.com/keybase/client/blob/5e5798149e1c6e5de7900319be70a6
> 02308dfbba/packaging/windows/WIXInstallers/KeybaseApps/KeybaseApps.wxs#L20
>
> Upgrade codes the same:
> https://github.com/keybase/client/blob/5e5798149e1c6e5de7900319be70a6
> 02308dfbba/packaging/windows/WIXInstallers/KeybaseApps/KeybaseApps.wxs#L3
> https://github.com/keybase/client/blob/493a52848a4a9fa10e03f8782da2f7
> 25a1c983a9/packaging/windows/WIXInstallers/KeybaseApps/KeybaseApps.wxs#L3
>
> On Mon, Feb 19, 2018 at 2:58 PM, Hoover, Jacob <Jacob.Hoover at greenheck.com
> > wrote:
>
>> Are you using WixStdBA or a custom BA?  Does the MSI have a MajorUpgrade
>> authoring? Are the UpgradeCode's the same between the two MSI's?  Is the
>> Bundle/@UpgradeCode the same between the two bundles?
>>
>> -----Original Message-----
>> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
>> Behalf Of Steve Sanders via wix-users
>> Sent: Monday, February 19, 2018 4:06 PM
>> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>> Cc: Steve Sanders <steve at keyba.se>
>> Subject: [wix-users] Previous package not found (and therefore not
>> uninstalled) during major upgrade
>>
>> I started to make a Github issue but realized it is encouraged to check
>> with the mailing list first. All sources, build logs and installer logs are
>> linked below.
>>
>> * Which version of WiX are you building with?
>>
>> > 3.11.0.1701
>>
>> * Which version of Visual Studio are you building with (if any)?
>>
>> > Microsoft (R) Build Engine version 14.0.25420.1
>>
>> * Which version of the WiX Toolset Visual Studio Extension are you
>> building with (if any)?
>>
>> > (WiX Toolset Visual Studio Extension version in
>> > major.minor.release.build
>> format) - not sure, it doesn't get logged, does it? Production builds are
>> headless, with msbuild - logs are available, see below
>>
>> * Which version of .NET are you building with?
>>
>> > 4.0 (I think)
>>
>> * If the problem occurs when installing your packages built with WiX,
>> what is the version of Windows the package is running on?
>>
>> > Windows v10.0 (Build 16299: Service Pack 0)
>>
>> * Describe the problem and the steps to reproduce it.
>>
>> > This is a bundle with a package, Keybase Apps, being upgraded from
>> version 1.0.39.39 to 1.0.40.19. Occasionally, the upgrade sequence fails
>> and the new version installation seems to be attempted though the old one
>> is there. The new install seems to fail due to files being in use,
>> including some background CLI processes that do not have windows, according
>> to some logs.
>>
>> > We have verified that the same installer sequence on the same machine
>> only fails occasionally. Logs from a success case, a failure case, and
>> build logs from both installers can be found at
>> https://keybase.pub/zanderz/wixupgrade/test/
>>
>> > Installer sources are mostly the same between the two. Version
>> > 1.0.39.39
>> was build from:
>> https://github.com/keybase/client/tree/493a52848a4a9fa10e03f
>> 8782da2f725a1c983a9/packaging/windows/WIXInstallers
>> > Version 1.0.40.19 was built from:
>> https://github.com/keybase/client/tree/5e5798149e1c6e5de7900
>> 319be70a602308dfbba/packaging/windows/WIXInstallers
>>
>> > When comparing side by side, the successful upgrade case contains:
>> ```
>> PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED property. Its value is
>> '{FC280A6D-DEED-4892-8C86-68467C1647CB}'.
>> PROPERTY CHANGE: Adding MIGRATE property. Its value is
>> '{FC280A6D-DEED-4892-8C86-68467C1647CB}'.
>> ```
>> > Also seen in a successful log is: `Command Line:
>> UPGRADINGPRODUCTCODE={7DBE161A-7943-4288-BD53-35939F3CE32E}
>> CLIENTPROCESSID=6872 CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL
>> `
>> > and associated values of `UPGRADINGPRODUCTCODE` In the failure log,
>> > UPGRADINGPRODUCTCODE and WIX_UPGRADE_DETECTED don't
>> seem to be set.
>>
>>
>> * Describe the behavior you expected and how it differed from the actual
>> behavior.
>>
>> > Major upgrades should consistently detect the existing product and run
>> its uninstaller. It seems like previous versions of Wix tools never had
>> this problem, but we're not positive.
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>
>