[wix-users] Fwd: Trying to understand Bootstrapping behavior with properties

Fri May 13 07:11:29 PDT 2022

Just realized that my exchange with Jacob didn't get posted to the list, so
I'm copying it here in case others have suggestions.

A little more information about our situation:  Our app has been allowing a
user to change the location of the data files from what it was at
installation.  This change is written to the registry, but the patches
revert the registry location to what had been saved during installation.

I get the impression that this is not something that we can fix in the
patch code, so we should just tell our users not to do that and only change
the data location by uninstalling and reinstalling the program.

Would appreciate anyone telling me I'm wrong about this...

thanks,
Todd
---------- Forwarded message ---------
From: Todd Hoatson <todd.hoatson at gmail.com>
Date: Wed, May 11, 2022 at 3:00 PM
Subject: Re: [wix-users] Trying to understand Bootstrapping behavior with
properties
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>

Thanks for the quick reply, Jacob...  I'm afraid I'm not intuitive enough
to follow your solution.

> A patch is just a modification of an existing install.

Yes, I am aware of that.  But I didn't see anything in the linked document
which answered my question.  There was no mention of how properties are
handled for patches.  Did I miss something?

> I would suggest you look into the remember me pattern...

The remember me pattern described in the linked post did not describe its
application to patches.  We already have remembered information, and it is
retrieved without a problem.  Our problem is that the retrieved data is
overwritten.

In the post, Rob writes:  "Do you see how the AppSearch that solved our
problem creates a new one? It overwrites our attempt to set REMEMBERME to
'2' with the remembered value '1'."

Unfortunately, Rob doesn't explain why the value was overwritten.  I take
it this is a Windows Installer bug, for which there is no good
explanation...

Again, the Complete Solution shown in Rob's post does not mention anything
about patches.

> ... as well, if it’s designed to be serviced only by bundles, do your
searches in the bundle and property drive the MSI/MSP installs.

Sorry, this is completely opaque to me.  What do you mean by "do your
searches in the bundle and property drive the MSI/MSP installs"?  Can you
give a few snips of code as an example?

It seems like you are suggesting that the Registry search should be done in
the Bundle code, and the result should be passed to the MSI/MSP as a
parameter.  Is that correct?  How does that solve the problem?

thanks,
Todd

On Tue, May 10, 2022 at 12:33 PM Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> A patch is just a modification of an existing install.
> https://docs.microsoft.com/en-us/windows/win32/msi/patch-packages
>
>
>
> I would suggest you look into the remember me pattern (
> https://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/),
> as well, if it’s designed to be serviced only by bundles, do your searches
> in the bundle and property drive the MSI/MSP installs.
>
>
>
>
>
> *From:* wix-users <wix-users-bounces at lists.wixtoolset.org> *On Behalf Of *Todd
> Hoatson via wix-users
> *Sent:* Tuesday, May 10, 2022 12:06 PM
> *To:* WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> *Cc:* Todd Hoatson <todd.hoatson at gmail.com>
> *Subject:* [wix-users] Trying to understand Bootstrapping behavior with
> properties
>
>
>
> Apologies in advance for this long post...
>
> We have an installer that works well for us, and we also use bootstrapping
> to supply patches.
>
> The installer allows the user to accept the default location for data files
> (a.k.a. project files) or change the location. The actual location is
> stored in the registry.
>
> We recently realized that the patches were only using the default location
> and not pulling the correct location from the registry, so if the user
> accepted the default location, it worked well, but if the user had selected
> an alternate location, that location was overwritten in the registry with
> the default location, and the user was no longer to find the data files.
>
> The relevant code for the base installer is:
>
> <CustomAction Id='SetDefProjFolder' Property='DEFPROJFOLDER'
> Value='[WindowsVolume]My App Projects' />
> <Property Id="PROJFOLDERFOUND" Value="unset" />
> <CustomAction Id="VerifyProjectPath"
> Return="check"
> Execute="immediate"
> BinaryKey="CustomActions.CA.dll"
> DllEntry="VerifyProjectPath" />
>
> <CustomAction Id='UseDefProjFolder' Property='PROJFOLDER'
> Value='[DEFPROJFOLDER]' />
> <CustomAction Id='UseRegProjFolder' Property='PROJFOLDER'
> Value='[REGPROJFOLDER]' />
>
> <CustomAction Id='CheckUpgradeValue' Property='ISUPGRADE' Value='True'
> />
> <CustomAction Id='CheckPatchValue' Property='ISPATCH' Value='True' />
>
> <InstallUISequence>
> <Custom Action="SetDefProjFolder"
> After="FindRelatedProducts"></Custom>
> <Custom Action="VerifyProjectPath" After="SetDefProjFolder"></Custom>
> <Custom Action="UseDefProjFolder" After="AppSearch">NOT
> REGPROJFOLDER</Custom>
> <Custom Action="UseRegProjFolder"
> After="AppSearch">REGPROJFOLDER</Custom>
> </InstallUISequence>
>
> The C# code for the custom action is:
>
> [CustomAction]
> public static ActionResult VerifyProjectPath(Session session)
> {
> session.Log("Begin VerifyProjectPath in custom action dll");
> string regProjPath = GetProjectDirFromRegistry();
> session.Log("ProjectPath from Registry: " + regProjPath);
> if (string.IsNullOrEmpty(regProjPath))
> {
> session["REGPROJFOLDER"] = null;
> session["PROJFOLDERFOUND"] = "NotFound";
> return ActionResult.Success;
> }
>
> session["REGPROJFOLDER"] = regProjPath;
>
> if (Directory.Exists(regProjPath) &&
> Directory.GetFiles(regProjPath).Length > 0)
> session["PROJFOLDERFOUND"] = "AlreadyExisting";
> else
> session["PROJFOLDERFOUND"] = "InvalidRegEntry";
>
> return ActionResult.Success;
> }
>
> As I mentioned above, all this works great for the base installer. Note
> that both DEFPROJFOLDER and REGPROJFOLDER are set, and there is logic to
> choose which one to use.
>
> For the patch, I tried adding the following code to our bootstrap
> installer:
>
> <Property Id="PROJFOLDER">
> <RegistrySearch Id='RegistryDataFolder' Root='HKLM'
> Key='SOFTWARE\Wow6432Node\My App'
> Name='Settings_Directory' Type='directory'/>
> </Property>
>
> Note that there is no mention of DEFPROJFOLDER here, nor is it mentioned
> anywhere else in the bootstrap installer wix code. Similarly, there is no
> mention of the SetDefProjFolder or VerifyProjectPath custom actions.
>
> However, when I install a text patch with logging turned on, I see this:
>
> Action 15:32:48: SetDefProjFolder.
> Action start 15:32:48: SetDefProjFolder.
> MSI (c) (A4:8C) [15:32:48:122]: PROPERTY CHANGE: Adding DEFPROJFOLDER
> property. Its value is 'C:\My App Projects'.
> Action ended 15:32:48: SetDefProjFolder. Return value 1.
>
> How can this be in the patch log when it is not in the patch code?
>
> I also see this in the log:
>
> Begin VerifyProjectPath in custom action dll
> MSI (c) (A4!1C) [15:32:48:245]: PROPERTY CHANGE: Adding REGPROJFOLDER
> property. Its value is 'C:\Temp Projects\My App Projects\'.
> MSI (c) (A4!1C) [15:32:48:246]: PROPERTY CHANGE: Modifying
> PROJFOLDERFOUND property. Its current value is 'unset'. Its new value:
> 'AlreadyExisting'.
> Action ended 15:32:48: VerifyProjectPath. Return value 1.
>
> So that proves that the C# is being invoked, and the proper value is being
> retrieved from the registry. But wait - VerifyProjectPath IS NOT MENTIONED
> IN THE PATCH CODE!!! How is this possible?
>
> In addition, I also see this:
>
> Action 15:32:48: UseRegProjFolder.
> Action start 15:32:48: UseRegProjFolder.
> MSI (c) (A4:8C) [15:32:48:294]: PROPERTY CHANGE: Adding PROJFOLDER
> property. Its value is 'C:\Temp Projects\My App Projects\'.
> Action ended 15:32:48: UseRegProjFolder. Return value 1.
>
> And this proves that the registry value has been selected over the default
> value.
>
> But later in the log file I find this line:
>
> MSI (c) (A4:8C) [15:32:48:528]: PROPERTY CHANGE: Modifying PROJFOLDER
> property. Its current value is 'C:\Temp Projects\My App Projects\'. Its new
> value: 'C:\My App Projects'.
>
> And then again:
>
> MSI (c) (A4:8C) [15:32:48:576]: PROPERTY CHANGE: Modifying PROJFOLDER
> property. Its current value is 'C:\My App Projects'. Its new value: 'C:\My
> App Projects\'.
>
> And twice more for good measure:
>
> MSI (s) (18:E4) [15:32:52:850]: PROPERTY CHANGE: Modifying PROJFOLDER
> property. Its current value is 'C:\My App Projects\'. Its new value: 'C:\My
> App Projects'.
> ...
> MSI (s) (18:E4) [15:32:52:866]: PROPERTY CHANGE: Modifying PROJFOLDER
> property. Its current value is 'C:\My App Projects'. Its new value: 'C:\My
> App Projects\'.
>
> Can anyone help me understand how this is happening? Where is this coming
> from if it is not in the patch code...?
>
> thanks,
>
> Todd Hoatson
> Mobile: 763-291-3312
> Email: todd_hoatson at sil.org <todd.hoatson at gmail.com>
>
>
> --
> Todd Hoatson
> Mobile: 763-291-3312
> Email: todd.hoatson at gmail.com
> www.linkedin.com/in/toddhoatson
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> NOTE: This email was received from an external source. Please use caution
> when opening links or attachments in the message.
>

-- 
Todd Hoatson
Mobile: 763-291-3312
Email:   todd.hoatson at gmail.com
www.linkedin.com/in/toddhoatson

-- 
Todd Hoatson
Mobile: 763-291-3312
Email:   todd.hoatson at gmail.com
www.linkedin.com/in/toddhoatson