- Written by Alexander Riedel
- Last Updated: 21 April 2016
- Created: 22 May 2012
- Hits: 2306
While investigating a bug report about another product’s installer we stumbled across a discrepancy with PowerShell’s PSModulePath environment variable.
On a virgin Windows 7 machine the environment variable is set to “C:\windows\system32\WindowsPowerShell\v1.0\Modules\” via a System Environment Variable.
There is no default that links to the per-user module path. If you query the environment variable in CMD you get the expected result:
If you do the same thing in PowerShell you get a different result:
Same thing happens in the ISE or any custom PowerShell host, like PrimalScript.
Now, Microsoft says here to add persistent changes to the PSModulePath variable in the profile. So my first reaction was to look for a profile which would add the local user’s module path to the environment variable. But since I tested this on a virgin Windows 7 VM, there is no profile. So PowerShell adds this to your environment settings on it’s own volition. Which means there is no way to exclude the current users module path.
I also respectfully disagree with Microsoft about adding changes to an environment variable to a profile. For one, I would expect environment variables to still work when I launch powershell with –noprofile. Secondly and most important to us, I cannot get a Windows installer to modify profiles. But modifying environment variables it can do.
So in order to do this correctly, your environment settings should reflect your current user module path:
The value in my case is C:\Users\Alex\Documents\WindowsPowerShell\Modules;“%PSModulePath%”
The %PSModulePath% takes the SYSTEM value and appends it to your user setting.
IMPORTANT: You must add %PSModulePath% at the end. If the system folder is not at the end, PowerShell.exe will append it again and you get duplicate entries.
MORE IMPORTANT: If you have a per-user value you must add the <User>\Documents\WindowsPowerShell\Modules folder as well. As soon as you have a user environment value, PowerShell will stop faking that entry for you.
Now any MSI installer which installs a PowerShell module into a custom path could in theory safely add to that path without disturbing or destroying other settings. It should take care to insert at the beginning rather than to append though. But since we cannot tell from within an MSI what user content is already there we just removed all PSModulePath environment editing from the ChangeVue installer and it will be up to the user to make the modifications. Maybe in the next version PowerShell will play by environment variable rules or make PSModulePath just an internal variable. Either way would take the confusion out of it.