Enabling Self Repair on User Environment Variables
I was originally posting this as a question, but as I was writing it I came up with an idea that worked. I'm posting this as an FYI since nothing came up when I searched the forum.
Using Wise Package Studio 5.51
I have a poorly written app (for many reasons other than this one) which requires the User ID to be placed in a User Environment Variable. I found that it did not appear to be possible to set Environment Variables as a key component which are repaired on first run under a new user profile. Am I correct on this or did I miss something? It seems that keys can only be file, registry or ODBC. Not Environment Variable.
Anyway, adding them directly to the HKCU registry hive only sort-of worked. The variables would not be available, and the application failed, until the user logged in again. Apparently the environment variables would not refresh until the next login even though they did appear in Control Panel > System > Advanced > Environment Variables.
What I ended up doing was to add a dummy flag registry key in HKCU\Software\[AppName]\UserProfileStuff and set it to 1. Placed this in a new component (called it RegistryHKCU_1) and set the registry entry as the component key. I then moved the Environment Variables from the Environment component to the RegistryHKCU_1 component. Now, if the key component of RegistryHKCU_1 is not present in HKCU (which is the dummy flag registry key HKCU\Software\[AppName]\UserProfileStuff), the environment variables will also be created along with the dummy flag registry key.
Feel free to comment if you have something to add.
Using Wise Package Studio 5.51
I have a poorly written app (for many reasons other than this one) which requires the User ID to be placed in a User Environment Variable. I found that it did not appear to be possible to set Environment Variables as a key component which are repaired on first run under a new user profile. Am I correct on this or did I miss something? It seems that keys can only be file, registry or ODBC. Not Environment Variable.
Anyway, adding them directly to the HKCU registry hive only sort-of worked. The variables would not be available, and the application failed, until the user logged in again. Apparently the environment variables would not refresh until the next login even though they did appear in Control Panel > System > Advanced > Environment Variables.
What I ended up doing was to add a dummy flag registry key in HKCU\Software\[AppName]\UserProfileStuff and set it to 1. Placed this in a new component (called it RegistryHKCU_1) and set the registry entry as the component key. I then moved the Environment Variables from the Environment component to the RegistryHKCU_1 component. Now, if the key component of RegistryHKCU_1 is not present in HKCU (which is the dummy flag registry key HKCU\Software\[AppName]\UserProfileStuff), the environment variables will also be created along with the dummy flag registry key.
Feel free to comment if you have something to add.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
kkaminsk
19 years ago
Wow it's definately an agressive way to deal with it. I am pretty sure you can refresh the environment via rundll32.exe but the syntax I cannot find. (It's been two years since I was over at that client's site)
Not sure if that will help you much but it would be nice to have environment variables self heal.
Not sure if that will help you much but it would be nice to have environment variables self heal.
Posted by:
MSIPackager
19 years ago
I'd agree with Loki's method - it's a good way of ensuring a repair triggers a component for installation - you can always add a GUID to the reg key if you want to make 100% sure it's unique [;)]
Particularly useful with machine based installs when you need to ensure current user reg keys / files etc are created when the app is run.
Particularly useful with machine based installs when you need to ensure current user reg keys / files etc are created when the app is run.
Posted by:
VikingLoki
19 years ago
kkaminsk -
Can you provide details on that environment variable refresh thing? If you put the registry entries directly into HKCU, bypassing the Environment table, and kick off that custom action at the end of every install, repair & uninstall (heck, on anything I guess), that could work well. That should make the environment variables self healing since you're treating them as registry keys, and you don't have the problem of not being refreshed until the next login. Hmmm... a problem on uninstall, maybe? Nah, I'm guessing no so long as the refresh CA is done at the end.
The only downside to the "same component" method is if the install suceeds but the user environment variables are altered or deleted afterwards, self repair won't kick in. Direct insertion of a reg key will be true self repair on the env vars so long as you always follow it with that refresh CA.
Can you provide details on that environment variable refresh thing? If you put the registry entries directly into HKCU, bypassing the Environment table, and kick off that custom action at the end of every install, repair & uninstall (heck, on anything I guess), that could work well. That should make the environment variables self healing since you're treating them as registry keys, and you don't have the problem of not being refreshed until the next login. Hmmm... a problem on uninstall, maybe? Nah, I'm guessing no so long as the refresh CA is done at the end.
The only downside to the "same component" method is if the install suceeds but the user environment variables are altered or deleted afterwards, self repair won't kick in. Direct insertion of a reg key will be true self repair on the env vars so long as you always follow it with that refresh CA.
Posted by:
kkaminsk
19 years ago
Ok, I am not 100% sure if this is the one but this will update all changes in HKCU without logging out. I think this is the one but I am trying to get a hold of someone at that client site to try and confirm this. Not sure if they will remember either but it's worth a shot.
RUNDLL32.EXE USER32.DLL,UpdatePerUserSystemParameters ,1 ,True
RUNDLL32.EXE USER32.DLL,UpdatePerUserSystemParameters ,1 ,True
Posted by:
WiseUser
19 years ago
Couldn't you just add the variable as a registry key and as an environment variable within the same component, and use the registry item as the keypath?
Or, am I missing something (it's late)?
Or, am I missing something (it's late)?
Posted by:
VikingLoki
19 years ago
My hesitation with that method is that the component ends up with a double reference. The order they are applied might make a difference. i.e. if the environment variable changes the value first, then the registry entry is checked and found to be identical, well that's ok. BUT if the registry entry is first and it changes the environment variable in the registry, then the environment variable is checked in the registry and it is seen as identical, it may decide that no changes are necessary and the environment variables wouldn't be updated.
Putting a registry value and an environment variable in the same component is risky because it is very dependent on exactly how Windows Installer is coded, and the situation might not have been considered when the code was written. Even if I see it work a dozen times, I still couldn't bring myself to trust it over a deployment of 20,000.
Putting a registry value and an environment variable in the same component is risky because it is very dependent on exactly how Windows Installer is coded, and the situation might not have been considered when the code was written. Even if I see it work a dozen times, I still couldn't bring myself to trust it over a deployment of 20,000.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.