[wix-users] Serious problem with FindRelatedProducts and install context

[Wheeler, Blaine (DSHS/DCS)]

+ 1 to Edwin


-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Edwin Castro via wix-users
Sent: Tuesday, March 27, 2018 7:02 PM
To: Alan Sinclair
Cc: Edwin Castro; WiX Toolset Users Mailing List
Subject: Re: [wix-users] Serious problem with FindRelatedProducts and install context

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/
>>>>>
>>>>
>>>>
>>>
>>
>

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/