[wix-users] Serious problem with FindRelatedProducts and install context
Edwin Castro
egcastr at gmail.com
Tue Mar 27 19:01:50 PDT 2018
Just remember that "the original install" is not really a thing. You can
only determine 2 things:
1.) Has this package been installed per-machine previously?
2.) Has this package been installed per-user *by this user* previously?
If the package was installed per-user previously by a *different* user,
then you won't know and will be "forcing" all future installs to be
per-machine if this user selects per-machine.
Any and all previous installs done per-user by different users will no
longer be able to upgrade after a per-machine install occurs. Those
installs will be forever stuck at the version they had when the per-machine
install happened. Need a new feature or bug fix? Sorry you can't upgrade
your existing per-user install because somebody else installed per-machine
after you!
The requirement doesn't really make sense. It is a bad requirement.
--
Edwin G. Castro
On Tue, Mar 27, 2018, 18:32 Alan Sinclair <anadem at gmail.com> wrote:
> > What if UserA installed per-user and then a sysadmin installed
> per-machine and then UserB tries to install per-user? That's three
> different installs and none of them would logically be upgrades because the
> context is different.
>
> You're right of course, but we don't need to support those cases... not
> sure what management will require if/when they happen ;-)
> However I was asked for a dual-scope installer, and need to make it able
> to update, forcing subsequent installs to the same scope as the original
> install. Per-user will be to the usual per-user locations (to avoid needing
> elevation), with per-machine going to the usual per-machine slots.
>
> (My windows installer experience likewise has been all per-machine with
> enterprise software --and that was over ten years ago-- so I'm both
> ignorant and rusty.)
>
> Thanks for the ideas
> Alan
>
> On Tue, Mar 27, 2018 at 4:49 PM, Edwin Castro <egcastr at gmail.com> wrote:
>
>> I *think* burn doesn't support dual-scope out of the box. That said, you
>> could write a custom BA that presented that choice to the user and passes
>> the appropriate ALLUSERS and MSIINSTALLPERUSER values.
>>
>> I'm guessing you intend to force per-machine if the product was installed
>> per-machine previously.
>>
>> What if a user really wants a per-user install even though there is
>> already a per-machine install?
>>
>> What if UserA installed per-user and then a sysadmin installed
>> per-machine and then UserB tries to install per-user? That's three
>> different installs and none of them would logically be upgrades because the
>> context is different.
>>
>> I don't have practical experience with per-user installs because I do
>> setup exclusively for enterprise software that is intended to be installer
>> per-machine only ... *but* ... The more I think about this the more I think
>> it never makes sense to have installers that target both per-user and
>> per-machine contexts. They really are different beasts and probably deserve
>> their own separate MSI packages. I could see a single bootstrapper that was
>> responsible for determining the kind of install/upgrade we're interested in
>> and then installing the appropriate MSI but that would be about it.
>>
>> --
>> Edwin G. Castro
>>
>> On Tue, Mar 27, 2018 at 4:36 PM, Alan Sinclair <anadem at gmail.com> wrote:
>>
>>> oops, meant to write AppSearch not FindRelatedProducts (brain fail)
>>>
>>> The issue isn't per-machine vs per-user, it's per-machine upgrading
>>> per-machine. Installing the dual-scope package, only per-user previous
>>> installations are detected and upgraded.
>>>
>>> When version 1.0 is installed per-machine, a subsequent install of
>>> version 2.0 does not 'see' the v1.0 installed product, and installs v 2.0
>>> as a fresh new product (overwriting the per-machine files if v.2.0 is
>>> installed per-machine .. which is what I meant by "only one set of files")
>>>
>>> *> I have a feeling you'll need a bootstrapper to install the upgrade
>>> MSI *
>>>
>>> Would that be an exe which passes ALLUSERS and MSIINSTALLPERUSER to
>>> msiexec to install the MSI?
>>> Would Burn be a candidate for that? I've never used Burn. Can Burn allow
>>> the user to choose per-machine or per-user in a non-upgrade install? (for
>>> an upgrade we'd want to remove the ability to choose)
>>>
>>> many thanks
>>> Alan
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 27, 2018 at 4:23 PM, Edwin Castro <egcastr at gmail.com> wrote:
>>>
>>>> Just curious, what do you mean "there's only one set of files"?
>>>>
>>>> A per-user install and per-machine install should probably install to
>>>> different locations. What if UserA and UserB both perform per-user
>>>> installs? Those installs should not conflict with one another and should
>>>> not conflict with a per-machine install.
>>>>
>>>> I have a feeling you'll need a bootstrapper to install the upgrade MSI
>>>> with appropriate values for ALLUSERS and MSIINSTALLPERUSER depending on
>>>> whether the user wants to install/upgrade per-user vs per-machine...
>>>>
>>>> --
>>>> Edwin G. Castro
>>>>
>>>>
>>>>
>>>> On Tue, Mar 27, 2018 at 4:05 PM, Alan Sinclair via wix-users <
>>>> wix-users at lists.wixtoolset.org> wrote:
>>>>
>>>>> I'm making a dual-scope MSI which uses the InstallScope dialog for the
>>>>> user
>>>>> to choose per-user or per-machine. It installs fine, but upgrades to a
>>>>> per-machine installation fail.
>>>>>
>>>>> FindRelatedProducts seems to search only the scope in current force
>>>>> when it
>>>>> runs, and it's sequenced right at the start (so early it doesn't even
>>>>> appear in the log.)
>>>>>
>>>>> My MSI has ALLUSERS=2 and MSIINSTALLPERUSER=1, with the InstallScope
>>>>> dialog
>>>>> changing that as required, so FindRelatedProducts looks only in
>>>>> per-user
>>>>> scope. If an earlier-versioned MSI was installed per-machine,
>>>>> FindRelatedProducts
>>>>> does NOT find it, so the install does not upgrade, and Control Panel's
>>>>> ARP
>>>>> shows the product twice (there's only one set of files, of course).
>>>>>
>>>>> Is there any way to solve this? Can FindRelatedProducts be run later
>>>>> in
>>>>> the sequence, after the UI? Or can FindRelatedProducts be run twice?
>>>>>
>>>>> Or can I add custom actions before FindRelatedProducts to look in the
>>>>> registry and check previous install scope, then adjust ALLUSERS etc
>>>>> accordingly so FindRelatedProducts searches the right scope?
>>>>>
>>>>> How can a dual-scope package be upgraded in both per-user AND
>>>>> per-machine
>>>>> installations?
>>>>>
>>>>> Thanks
>>>>> Alan
>>>>>
>>>>> ____________________________________________________________________
>>>>> WiX Toolset Users Mailing List provided by FireGiant
>>>>> http://www.firegiant.com/
>>>>>
>>>>
>>>>
>>>
>>
>
More information about the wix-users
mailing list