I have a question regarding the availability of environment variables from processes launched from within the installation instance. I am setting a number of variables and am wondering if they ever become available to batch files or processes which i am launching in CAs from within the installer.
I created a Deferred Execution CA which launches a separate application (and scheduled it after the WriteEnvStrings action) but it does not find the variables i am setting. I was wondering if the means by which the process is created from IS is copying the Env Block from the IS process rather than instantiating a new "updated" env block for the new process.
Would a Commit Execution CA give me what i need. If so then does one use the customActionData model to pass properties?
The Windows Installer service does not listen to environment changes, even though it is causing those changes. Because of this, and since Windows processes inherit environment variables from their parent process, environment variables installed by the current installer are not available until after the installation exits. Some detail was provided on this in an old MSDN chat:
Host: Chris (Microsoft) Q: (low-priority MSI question) Any way to ensure the environment is in place (e.g. for PATH additions) in msiexec's process before a custom action begins? (For NT-based OS's) We've run into some PATH problems with special registration steps we need to do.
A: Unfortunately, this is a very difficult problem which is inherent in the way that environment blocks are handled by Windows. When an environment variable is updated, a WM_SETTINGCHANGE message is sent to all windows on the system to indicate that the block has been updated. Only processes that actually listen and process this message will be able to refresh their environment block. For example, explorer processes this message, so if you start a new command prompt through explorer you will see your changes. However the service control manager does NOT listen for this message, so services started after the environment is updated will not see the update. This is why you often have to logoff and log on before your changes will be seen. MSI will pick up changes made before the install starts due to its client\server model, but it won't see changes made during the install.
There are ways to mitigate this. Windows has the concept of machine, user, process and volatile so although the SCM/MSIEXEC model lacks this capability, the custom action itself can manipulate the process space to effect the change for the duration of that process.
However, I'd note in my opinion that it should be a very rare case where a custom action should actually have a dependency on environment variables. I'd suggest seperating what needs to be done from how it's currently being done and consider changing the code to not have this requirement to simplify your design and decrease fragility.
