Refresh system after Set Envrionment

[deploy]

When using "Set Environment" IA does not refresh the system so that new processes can see the modifications my installer has done. A logoff/login or reboot is required which is not acceptable in my current scenario.

What I want to accomplish is that the env.variable I have set/created is available to new processes. For example in a new command prompt I open after my installer is finished, or a new process I launch from IA/Run Program (I know most running processes will not handle the message and refresh, that's OK)

This behavior is discussed in:
viewtopic.php?f=2&t=2754
viewtopic.php?f=2&t=7687

When I used NSIS I used the SendMessage API like this and it worked just fine:
SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000

In IA I have tried (like others on this forum) a lot of combinations to produce the same result but nothing works.
Here's my last attempt:

~InstallAware Clipboard Data~
~Call DLL Function~
~{0ACA9C70-6665-4180-9494-B34BB8A522FD}~
~user32.dll,SendMessageA,void,,"double word",65535,"double word",26,"double word",0,"allocated string buffer (MAX_PATH length)",Environment,$~
~mIDEFunc.dll\mEXEFunc.dll~

What are we doing wrong?

[FrancescoT]

Dear User,

You can change environment variables at any time. However, this will only change the environment block for new processes executed after the change. Existing processes will keep on using their current environment block, which is the same as it was before you made the change.
New processes only will inherit the changed environment.

A process can elect to update its environment block dynamically, by calling SetEnvironmentVarible(). But an application needs to be written to explicitly do this; there's no mechanism in the operating system to universally update environment variables on the fly for running processes.

In fact if you do the following you can easily verify it;,

#1 run a command prompt window with entering the SET command to display the current environment variables and you will see, what currently is for this particular CMD.EXE process, the environment block value.

2# leave the above CMD prompt window open.

3# modify the environment variables via System Properties -> Advanced -> Environment Variables.

4# open a new Command Prompt window and enter the SET command .

5# Run the SET command again in the previous Command Prompt window.

Results:
If you Compare the SET commands output with the two Command Prompt windows, you will see that only the second CMD prompt windows will display the updated values for the Environment Variables ... instead the SET command with first CMD Prompt, continues to display the Environment Variables values as before the changes you made at point #3.

The Windows shell (...Explorer.exe) listens for WM_SETTINGSCHANGE messages, and will update its copy of the environment dynamically.

Please also have a look at the following link for more details;
http://msdn.microsoft.com/en-us/library/ms682653(VS.85).aspx

Finally, the above behavior is not an InstallAware limitation but instead, it is how the OS works.

If you don't want to restart the system after the changes, you could launch a dedicated separate process from your setup package after the Set Environment call and at least, after the Apply Install command, if you use the Windows Installer engine.
For this purpose you could create a very simple setup package ( ... for example based on the IntallAware Blank setup project template), that just does the tasks that you require after environment variables changes.

Hope this clarify your doubt.

[deploy]

Hello FrancescoT and thanks for the reply.
I follow your reasoning, and the example with the two CMD:s is perfect, this is exactly what I try to accomplish. Problem is it does not work that way with IA which was what I tried to point out. Maybe I was a bit unclear?

Please try the following to verify my problem (I'm on IA 15):
#1 open a command prompt and type SET
#2 Run an IA installer which consists of:

Code: Select all

~InstallAware Clipboard Data~
~Set Environment~
~{F2C825D1-63E8-482F-B6C0-B6476364D4C2}~
~IA_TEST~
~abc123~
~0~
~2~
~FALSE~
~TRUE~
~Set Variable~
~{EA08C49A-7099-4CF9-9E74-CF010A610422}~
~Native_Engine$MYAH$MYAH$FALSE~
~TRUE~


(In text:
Set Variable Native_Engine to TRUE
Set Environment Variable %IA_TEST% to abc123 )

#3 open a second command prompt after the installer has run and type SET

Results:
Neither of the CMD processes will see the variable the installer created. The expected result would be that the second CMD would see variable IA_TEST.

When IA make changes to the environment, this is NOT reflected to any new processes since IA does not notify Windows of the changes. That is why I am trying to work around this using CallDll->SendMessageA since I cannot allow a complete reboot of the system in my installer.

EDIT:
Yesterday during extensive testing/guessing of parameters for CallDll I *might* have commented out "Native_Engine=True" at some point when I actually got the rest correct.. Today (with the comment removed) the script below seem to work, if we continue the example with the two CMD:s, now the second one will pick up the new variable thanks to the dll call.

Working script:

Code: Select all

~InstallAware Clipboard Data~
~Call DLL Function~
~{0ACA9C70-6665-4180-9494-B34BB8A522FD}~
~user32.dll,SendMessageA,void,,"double word",65535,"double word",26,"double word",0,"allocated string buffer (MAX_PATH length)",Environment,$~
~mIDEFunc.dll\mEXEFunc.dll~
~Set Environment~
~{F2C825D1-63E8-482F-B6C0-B6476364D4C2}~
~IA_TEST~
~abc123~
~0~
~2~
~FALSE~
~TRUE~
~Set Variable~
~{EA08C49A-7099-4CF9-9E74-CF010A610422}~
~Native_Engine$MYAH$MYAH$FALSE~
~TRUE~


May I humbly suggest the following: Either implement in IA a command for notifying Windows of the changes ("Refresh Environment"?) or make the appropriate call within the Set Environment command directly. Otherwise a logoff or reboot *will always be required* to reflect changes you make to env.variables from within a IA setup.(unless one figures out how to make a somewhat obscure CallDll. As seen in previous threads I am not the first one to fail at this step )

[FrancescoT]

Dear User,

please excuse me, but I believe that you are still missing how the Set Environment works

Your dll call doesn't refresh the settings ... but only posts a Message to the top level windows due the HWND_BROADCAST parameter.

It is enough to run a new process after you applied your Environment settings to see them changed.

I have realised a simple dummy project to demonstrate it.
The project executes a SET command with the CMD prompt when it starts, to show the original System Environment values.
Then the setup package during installation sets an Environment variable "MYTESTVARIABLE = MyTestValue".

Once the package installation is completed, run it once again ... the CMD window will show the new System Environment updated values that now include the just created MYTESTVARIABLE.

[deploy]

Hello again Franscesco!

Since I can not convince you with words I attach a screenshot after running your pre-compiled example twice (\Realease\Single).
As you can see the variable is not set in the second CMD-prompt, newly spawned processes do not see the changes IA made to the environment.

setenv.PNG (84.79 KiB) Viewed 14047 times

And no, I haven't photoshopped this

I can reproduce this (using your binary) on both English Win XP x86/7 x64 on clean machines coming right out of MDT 2012 deployment with no software preinstalled.
Also: Considering I am not the first to report this behavior (see links in my first post) I hope I can convince you to look into this?

If I modify your example project to include the SendMessageA I posted above and place it after "Apply Install" and recompile it works as expected.
Let me know if you need any more information for troubleshooting this.

[FrancescoT]

Dear User,

I don't know why it seems to not work as expected with your test machine ... but with my test it works fine.

If you don't believe me ... I can post my screen-shot as well.

Regards

[deploy]

Dear FrancescoT,

I think we both can agree on one thing at least It is very strange that we get different results using the same binary. Did you test under Win 7 x64 as well?

I seem to be able to reproduce the behavior over and over on freshly installed computers, fully patched Win 7 x64. As you can see in my first post I am not the first to report this issue either. Chances are there are a number of computers out there where IA does not work as intended regarding env. variables.

Since I can reproduce this behavior, even with your binaries, would you want me to troubleshoot anything special? Perhaps open a support case (we are licensed customer)?

You have stated that a call to PostMessage is not necessary, but depending on how IA does things internally I think it might be? Please see:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Calling SetEnvironmentVariable has no effect on the system environment variables. To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message with lParam set to the string "Environment". This allows applications, such as the shell, to pick up your updates.

Regards,