0

I have a merge module which searches for some registry locations to read values and save to Properties. Here is the code segment:

  <Fragment Id="RegSearch">
<Property Id="HOST_APP_PATH" >
  <RegistrySearch Id="HOST_App"  
                  Root="HKLM"
                  Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\HOST.exe"
                  Name="Path"
                  Type="raw"
                  />
</Property>
<Property Id="HOST_ROOT_PATH" >
  <RegistrySearch Id="HOST_Root"
                  Root="HKLM"
                  Key="SOFTWARE\HostApplication\Installation Info"
                  Name="HOST_Root"
                  Type="raw"
                  />
</Property>

Windows Installer puts this search in AppSearch custom action.

Problem: AppSearch executes this search very early, before WriteRegistryValues of Host Installer, it won't get any values and properties with this search won't be defined, because registry to search was never written there.

Question 1: Can we reschedule this registry search from merge module after WriteRegistryValues of Host Installer?

Question 2: Is there any other way to search registry after Host Installer executes WriteRegistryValues? Probably with some custom action?

Farrukh Waheed
  • 2,163
  • 2
  • 29
  • 59

1 Answers1

0

AppSearch is a standard action provided by the windows installer and by design is intended to run very early. This is because it's frequently used by the LaunchConditions standard action to decide if an installation can continue or not. It's also useful for deciding whether features and components should be installed.

MSI is a very opinionated framework. I suspect that there is something wrong with your current design that is going to be incompatible with MSI.

Is host installer the same MSI or a different MSI? Assuming it's the same, why couldn't you just put your data in some MSI properties and use those properties to write to the registry? Then you wouldn't need to read the values back in because you'd already have them in properties.

What do you need these properties for after writing them to the registry? Usually writing them to the registry would be the end game. I'm not sure what else you are doing next.

If host.msi is a different MSI, why are you having one MSI install another MSI? That's not MSI design. In this case you would need a bootstrapper. Host MSI would run first then this MSI. But even then it's kinda strange that a second MSI would depend on properties set by a first MSI. I'd think the bootstrapper UI and Application would gather this information and pass it as secure custom public properties to both MSIs.

To answer question 1: No a merge module can only insert actions into the sequence. It can't reschedule actions. 2: You would have to use a custom action. But as I said above, this feels like the wrong path to me.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks. No its not two msi's. host.msi is different and consuming msm. Above property searching is happening in msm and problems are occurring after msm is merged with host.msi. – Farrukh Waheed Apr 26 '18 at 11:46
  • 1
    I think what you are looking at is your MSM has a dependency on your MSI. It can't work that way. I would research the concept of configurable merge modules. http://wixtoolset.org/documentation/manual/v3/xsd/wix/configurationdata.html https://msdn.microsoft.com/en-us/library/windows/desktop/aa368027(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa372408(v=vs.85).aspx – Christopher Painter Apr 26 '18 at 11:58