[wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
Steve Sanders
steve at keyba.se
Wed Feb 21 09:23:12 PST 2018
Wow, Rob Mensching himself! Thanks for taking a look.
I am certain these installers were all run as user, not elevated. In one
case I managed to duplicate it myself (out of 50+ upgrades), and in another
case it was a knowledgeable colleague I trust to report accurately. I
assume you're referring to the lack of permissions error to write in
%localappdata%\Keybase\Gui ? I believe it is because one of our processes
installed to that directory was still running because our custom actions to
shut them down were not run because MajorUpgrade was not detected.
So far from the helpful info in this thread, it sounds like Windows itself
is failing to find the previous installation in FindRelatedProducts, though
the .msi files have proper upgrade tables.
Again, some of our processes are windowless (lower-case keybase.exe,
kbfsdokan.exe, upd.exe) and we have visible processes called upper-case
Keybase.exe which are electron based. Maybe the fact that these windowless
ones can't be identified normally is a factor?
I have no idea what to do about this and the hacks I'm considering are 1.
passing an argument from the burn bundle, which seems to detect
MajorUpgrade even when the MSI can't, or 2. check a registry key to see if
we're installed already
Option 3 is to rewrite it without Wix, like my colleagues keep suggesting,
but I think it would just lead to new, different pain.
On Tue, Feb 20, 2018 at 7:33 PM, Rob Mensching <rob at firegiant.com> wrote:
> 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