[wix-users] Stable (wrt. repair) conditional installation of component based on user selection at install time

Stephen Oberholtzer stevie at qrpff.net
Sun Aug 26 11:09:46 PDT 2018


Jacob: Separate installers for development vs production is not really
viable; furthermore, the user making the wrong choice is not something I'm
worried about, merely the installer automatically making the wrong choice
for the user.

So I ran some more tests and a surprising result came to pass: It appears
that the Windows Installer database remembered whether or not the component
was supposed to be installed!
So if I don't need to explicitly access the original selection in the
repair/uninstall UI, it would appear that I don't need to do anything
special.

For reference, here's what I did:
I created a proof-of-concept installer with two components; feature1.txt
and feature1_file2.txt; the latter had a condition of "INSTALLFILE2".
I added a custom action scheduled after CostFinalize that printed the
status of every component in the Session object.
(If anybody wants to see these, I can post them somewhere.)

Install without setting INSTALLFILE2:

Component: Name='feature1.txt' CurrentState='Absent' RequestState='Local'
Component: Name='feature1_file2.txt' CurrentState='Absent'
RequestState='Unknown'

File 2 was not installed

Ran repair:

Component: Name='feature1.txt' CurrentState='Local' RequestState='Local'
Component: Name='feature1_file2.txt' CurrentState='Local'
RequestState='Unknown'

File 2 was not (re)installed

Ran uninstall:

Component: Name='feature1.txt' CurrentState='Local' RequestState='Absent'
Component: Name='feature1_file2.txt' CurrentState='Local'
RequestState='Unknown'

=========================

I then re-ran the first batch, but manually created feature1_file2.txt
before uninstall; that file was not deleted, although I wasn't careful to
check the create date (NTFS has some deep magic called "tunneling", wherein
if you delete/rename a file and create a new one with the same name shortly
afterwards, it preserves the create date of the original file.)

=========================

Install with INSTALLFILE2=1:

Component: Name='feature1.txt' CurrentState='Absent' RequestState='Local'
Component: Name='feature1_file2.txt' CurrentState='Absent'
RequestState='Local'

Ran repair (msiexec /f):

Component: Name='feature1.txt' CurrentState='Local' RequestState='Local'
Component: Name='feature1_file2.txt' CurrentState='Local'
RequestState='Local'

Deleted both files and ran repair again . Both files were reinstalled.


Ran uninstall (msiexec /x):

Component: Name='feature1.txt' CurrentState='Local' RequestState='Absent'
Component: Name='feature1_file2.txt' CurrentState='Local'
RequestState='Absent'

File 2 was deleted.



On Thu, Aug 23, 2018 at 1:02 PM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> Or create separate installers for development vs production....
>
> Assuming a user will never choose the wrong option, or that you can "hide"
> the option in the MSI from the user is a bad design in my opinion.
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Stephen Oberholtzer via wix-users
> Sent: Wednesday, August 22, 2018 8:33 PM
> To: Edwin Castro <egcastr at gmail.com>
> Cc: Stephen Oberholtzer <stevie at qrpff.net>; WiX Toolset Users Mailing
> List <wix-users at lists.wixtoolset.org>
> Subject: Re: [wix-users] Stable (wrt. repair) conditional installation of
> component based on user selection at install time
>
> While I can't find any explicit documentation either way, I strongly
> suspect that the CostFinalize action is scheduled in a "firstSequence"
> style (i.e. it is only run inside InstallExecuteSequence if
> InstallUISequence isn't executed, such as in a silent install.)
>
> One other thing that I'm looking into is if it's possible to create a pair
> of invisible sub-features with very low priority (say, level=32767)  that
> are automatically selected when the 'development mode' option is selected;
> however, I need to better understand what sorts of things can
> enable/disable a feature for installation, to prevent unintended
> installation in production mode.
>
> On Wed, Aug 22, 2018 at 8:20 PM, Edwin Castro <egcastr at gmail.com> wrote:
>
> > I might be wrong here but if you get the UI data in the
> > InstallUISequence, then that data in the form of a property will be
> > used during CostFinalize in the InstallExecuteSequence to determine if
> > the component should be installed or not. Is this not the behavior
> you're seeing?
> >
> > You are correct, to make the selection sticky you'll want to use the
> > remember property pattern/idiom. I don't think you have another option
> > there. You can determine if you're doing a major upgrade or not and
> > include that into your conditions in InstallUISequence and
> InstallExecuteSequence.
> >
> > --
> > Edwin G. Castro
> >
> >
> > On Wed, Aug 22, 2018 at 4:57 PM Stephen Oberholtzer via wix-users <
> > wix-users at lists.wixtoolset.org> wrote:
> >
> >> I seek advice on how to manage a messy situation.
> >>
> >> I have a component (a file) that is shared by two features.   At
> >> installation time, the user specifies whether they are doing a
> >> "development" or "production" installation. (This is done in one of
> >> three
> >> ways: (1) by setting a property when running the installer, (2)
> >> placing a file with a certain name in [SOURCEDIR], or (3) answering a
> >> prompt displayed during the UI sequence.)
> >>
> >> - For a "development" installation, this component *must* be
> >> installed if either of the two features is enabled.
> >>   If, later, the user opts to repair, this component *should* be
> >> reinstalled if missing, but I can't get both that *and* the
> >> never-install-for-production, I can make due.
> >>
> >> - For a "production" installation, this component *must not* be
> installed.
> >> Doing so could cause the feature to behave in an unpredictable fashion.
> >>   If later, the user opts to repair, this component *must not* be
> >> installed.
> >>
> >> - Note that the features that use this component are not the only two
> >> features in the product.
> >>
> >> I see one way that the problem could be solved, but there are several
> >> hitches, so I'm wondering if there's a better way.
> >>
> >> * A component can have a Condition on it, but this Condition is only
> >> evaluated during CostFinalize, which is well before any UI kicks in;
> >> therefore, I would have to create a CA that calls MsiSetComponentState.
> >> * To make the dev/prod selection sticky, I could create a registry
> >> key; however, I need the dev/prod selection to *not* be sticky across
> >> major upgrades.  (Also, it's a bit clunky.)
> >>
> >> --
> >> -- Stevie-O
> >> Real programmers use COPY CON PROGRAM.EXE
> >>
> >> ____________________________________________________________________
> >> WiX Toolset Users Mailing List provided by FireGiant
> >> http://www.firegiant.com/
> >>
> >
>
>
> --
> -- Stevie-O
> Real programmers use COPY CON PROGRAM.EXE
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>



-- 
-- Stevie-O
Real programmers use COPY CON PROGRAM.EXE


More information about the wix-users mailing list