[wix-users] Fwd: Trying to understand Bootstrapping behavior with properties
Rob Mensching
rob at firegiant.com
Tue May 17 08:41:27 PDT 2022
> I prefer to think of a patch as modifying the existing installer via the MSP (in memory at runtime) and doing a reinstall.
That's _exactly_ what patching via MSP is. :)
- - - - - - - - - - - - - - -
I provide short answers on wix-users. Full commercial support is offered by FireGiant at http://www.firegiant.com/services
-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Hoover, Jacob via wix-users
Sent: Tuesday, May 17, 2022 8:19 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-users] Fwd: Trying to understand Bootstrapping behavior with properties
You haven’t provided enough authoring to know what’s going on. It sounded as if you were using a bundle to deploy your install and patches. Are you using DisplayInternalUI? How are you allowing the users to select an installation option? Are you deploying the original MSI wrapped in a bundle? Are your patches also deployed as a bundle, and if so are they patch bundles, or are you slip streaming them?
I prefer to think of a patch as modifying the existing installer via the MSP (in memory at runtime) and doing a reinstall. As such, your logs are showing you a combination of the existing install + whatever transformations were applied via your MSP.
https://docs.microsoft.com/en-us/windows/win32/msi/patching
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Todd Hoatson via wix-users
Sent: Friday, May 13, 2022 9:11 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Todd Hoatson <todd.hoatson at gmail.com>
Subject: [wix-users] Fwd: Trying to understand Bootstrapping behavior with properties
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<mailto: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<mailto: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<mailto: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<http
> s://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/<https://robmensching.com/blog/posts/2010/5/2/the-wi
> x-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<mailto: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<mailto:wix-users at lists.wixtoolset.org>
> >
> *Cc:* Todd Hoatson
> <todd.hoatson at gmail.com<mailto: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<mailto:todd_hoatson at sil.org>
> <todd.hoatson at gmail.com<mailto:todd.hoatson at gmail.com>>
>
>
> --
> Todd Hoatson
> Mobile: 763-291-3312
> Email: todd.hoatson at gmail.com<mailto:todd.hoatson at gmail.com>
> www.linkedin.com/in/toddhoatson<http://www.linkedin.com/in/toddhoatson
> >
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/<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<mailto:todd.hoatson at gmail.com>
www.linkedin.com/in/toddhoatson<http://www.linkedin.com/in/toddhoatson>
--
Todd Hoatson
Mobile: 763-291-3312
Email: todd.hoatson at gmail.com<mailto:todd.hoatson at gmail.com>
www.linkedin.com/in/toddhoatson<http://www.linkedin.com/in/toddhoatson>
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/<http://www.firegiant.com/>
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users
mailing list