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

[Steve Sanders]

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/493a52848a4a9fa10e03f8782da2f725a1c983a9/packaging/windows/WIXInstallers
> Version 1.0.40.19 was built from:
https://github.com/keybase/client/tree/5e5798149e1c6e5de7900319be70a602308dfbba/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.