[wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
Rob Mensching
rob at firegiant.com
Tue Feb 20 19:33:59 PST 2018
Is it possible, one MSI is installed per-user and the other being installed per-machine?
_____________________________________________________________
Short replies here. Complete answers over there: http://www.firegiant.com/
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Steve Sanders via wix-users
Sent: Tuesday, February 20, 2018 5:31 PM
To: Edwin Castro <egcastr at gmail.com>
Cc: Steve Sanders <steve at keyba.se>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
I tried to detail above, and linked the actual logs - not sure what you're asking.
> 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.
On Tue, Feb 20, 2018 at 5:23 PM, Edwin Castro <egcastr at gmail.com> wrote:
> That's a bundle log rather than an MSI log. That detection is for the
> bundle rather than for the MSI. What does the bundle log say for the
> MSI package? What does the MSI log say?
>
> --
> Edwin G. Castro
>
> On Tue, Feb 20, 2018 at 5:12 PM, Steve Sanders <steve at keyba.se> wrote:
>
>> Positive it's a MajorUpgrade. Again, this problem happens only
>> intermittently with the same 2 bundles. In both success and failure
>> cases, the burn log contains:
>> [2200:27D8][2018-02-16T19:30:30]i102: Detected related bundle: {
>> 48d54dff-2ea8-461a-a1f3-bea0d2c2c26f}, type: Upgrade, scope: PerUser,
>> version: 1.0.39.39, operation: MajorUpgrade
>>
>> The app package has Product Id="*" , so it is always a major upgrade,
>> AFAIK.
>>
>> Logs are already verbose AFAIK, they're linked to above.
>>
>> On Tue, Feb 20, 2018 at 3:28 PM, Edwin Castro <egcastr at gmail.com> wrote:
>>
>>> Are you sure you have a MajorUpgrade? Is it at all possible that the
>>> Windows Installer thinks you're modifying or repairing a currently
>>> installed product? What does the verbose log say? What happens when
>>> the ProductVersion changes but the ProductCode does not?
>>>
>>> --
>>> Edwin G. Castro
>>>
>>> On Tue, Feb 20, 2018 at 3:22 PM, Steve Sanders via wix-users <
>>> wix-users at lists.wixtoolset.org> wrote:
>>>
>>>> I don't remember, maybe it was a FilesInUse chicken/egg problem, as
>>>> in https://buildmaestro.wordpress.com/2011/03/14/suppress-files
>>>> inuse-dialog-on-uninstall/
>>>> ? I could theoretically shut down our processes before that, but
>>>> would then need a rollback option to restart them on
>>>> failure/cancel/full disk, etc.
>>>> One of our requirements is to support silent update.
>>>>
>>>> On Tue, Feb 20, 2018 at 2:22 PM, Hoover, Jacob <
>>>> Jacob.Hoover at greenheck.com>
>>>> wrote:
>>>>
>>>> > If Language is null or an empty string (""), FindRelatedProducts
>>>> ignores
>>>> > *msidbUpgradeAttributesLanguagesExclusive* and detects all languages.
>>>> >
>>>> >
>>>> >
>>>> > The one thing I do think is strange, why do you suppress
>>>> InstallValidate?
>>>> >
>>>> >
>>>> >
>>>> > <InstallValidate Suppress="yes">FAKE_PROPERTY</InstallValidate>
>>>> >
>>>> >
>>>> >
>>>> > *From:* Steve Sanders [mailto:steve at keyba.se]
>>>> > *Sent:* Tuesday, February 20, 2018 4:07 PM
>>>> > *To:* Hoover, Jacob <Jacob.Hoover at greenheck.com>
>>>> > *Cc:* WiX Toolset Users Mailing List
>>>> > <wix-users at lists.wixtoolset.org>
>>>> >
>>>> > *Subject:* Re: [wix-users] Previous package not found (and
>>>> > therefore
>>>> not
>>>>
>>>> > uninstalled) during major upgrade
>>>> >
>>>> >
>>>> >
>>>> > According to Orca, the upgrade tables look like this, same as one
>>>> built
>>>> > with Wix 3.9 except for the version of course. Is it a problem
>>>> > that Language is empty?
>>>> >
>>>> >
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.39.39 513
>>>> WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.39.39
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.40.19 513
>>>> WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.40.19
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > and one from 6 months ago:
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.26.918 513 WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.26.918
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Feb 20, 2018 at 1:17 PM, Steve Sanders <steve at keyba.se>
>>>> wrote:
>>>> >
>>>> > I tried to figure out what the Upgrade table is and how to find
>>>> > it,
>>>> but
>>>> > nearest I can tell, Wix is supposed to handle/populate it from
>>>> > the MajorUpgrade element:
>>>> > <MajorUpgrade DowngradeErrorMessage="A newer version of Keybase
>>>> > is
>>>> already
>>>> > installed." AllowSameVersionUpgrades="yes" />
>>>> >
>>>> >
>>>> >
>>>> > This hasn't changed for more than a year - I suppose it is
>>>> > possible
>>>> that
>>>> > wix 3.11 changed the way it populates this upgrade table? I will
>>>> > try dumping it from some MSIs using Orca and see.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Feb 20, 2018 at 10:48 AM, Hoover, Jacob <
>>>> > Jacob.Hoover at greenheck.com> wrote:
>>>> >
>>>> > Well, if FindRelatedProduct is truly failing then it's a windows
>>>> installer
>>>> > issue. However I seriously don't think this is the issue. Per
>>>> > https://msdn.microsoft.com/en-us/library/windows/desktop/
>>>> > aa368600%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 I would
>>>> compare
>>>> > the Upgrade table from an old "never broken" install and a newer
>>>> "sometimes
>>>> > broken" installer.
>>>> >
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org]
>>>> > On
>>>> Behalf
>>>> > Of Steve Sanders via wix-users
>>>> > Sent: Tuesday, February 20, 2018 12:38 PM
>>>> > To: WiX Toolset Users Mailing List
>>>> > <wix-users at lists.wixtoolset.org>
>>>> > Cc: Steve Sanders <steve at keyba.se>
>>>> >
>>>> > Subject: Re: [wix-users] Previous package not found (and
>>>> > therefore not
>>>> > uninstalled) during major upgrade
>>>> >
>>>> > I am positive because of the associated updater log, among other
>>>> reasons,
>>>> > which shows version 1.0.39-20180121191330+5e57981 (that's the
>>>> > semantic version, the windows version being 1.0.39.39) applied
>>>> > 2018/01/23
>>>> 11:57:11,
>>>> > then the updater considers that version current when it checks
>>>> > for
>>>> the next
>>>> > update:
>>>> > 2018/02/16 19:30:03 INFO Checking for update, current version is
>>>> > 1.0.39-20180121191330+5e57981
>>>> > (updater gets this version by running the installed program with
>>>> > the "version" argument.)
>>>> >
>>>> > Again, our custom actions are supposed to close our processes in
>>>> > the upgrade case, but if upgrade case is not detected, they can't
>>>> > close
>>>> the
>>>> > processes.
>>>> >
>>>> > I guess we could hack around this with some registry entries, but
>>>> detecting
>>>> > + applying upgrades is one of the main reasons to use a tool like
>>>> > + Wix
>>>> I
>>>> > thought. Again, this happens only intermittently, and didn't seem
>>>> > to happen ever with Wix 3.9.
>>>> >
>>>> > Thanks again, everyone, for taking a look.
>>>> >
>>>> > On Tue, Feb 20, 2018 at 3:23 AM, Nir Bar via wix-users <
>>>> > wix-users at lists.wixtoolset.org> wrote:
>>>> >
>>>> > > The failing log says the the RESTART MANAGER is disabled so
>>>> FilesInUse
>>>> > > is used. FilesInUse can only detect applications with a window.
>>>> > >
>>>> > > However, this has nothing to do with upgrade detection. I've
>>>> > > never encountered a false-false upgrade detection.
>>>> > > Are you absolutely sure that another version is already installed?
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Nir Bar, Independent WiX Expert. Creator of-
>>>> > > JetBA: WiX WPF Bootstrapper User Interface Framework
>>>> > >
>>>> > > JetBA++: WiX Native Bootstrapper User Interface Framework
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > > ____________________________________________________________
>>>> ________
>>>> > > 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/
More information about the wix-users
mailing list