HOMEDRIVE and HOMEPATH variables don't exist for Windows Service Account
Hi All,
Setup
- runs on Azure DevOps Build Agent on a Windows server
- Agent runs under dedicated Service account
- Agent Build project using
MSBuild - project includes
MSBuild.Node.targetsand others -
npmis installed on two locations:-
C:\Users\Me\AppData\Roaming\npm(Default location) -
'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\NodeJs
-
Problem
The EnsureNodeModules target runs the where.exe, and chooses the wrong npm (the one under C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\NodeJs).
This results in problems later in the build task (Grunt task fails).
Reason of failure
Although npm is installed on the default location (as described in MSBuild.Node.props), it is not found on that location.
<GlobalNodeModulePath>$(HOMEDRIVE)$(HOMEPATH)\AppData\Roaming\npm</GlobalNodeModulePath>
The reason for this is that the HOMEDRIVE and HOMEPATH environment variables are volatile variables. These variables are created (on user level) when the user logs in on the machine (stating up explorer.exe). If the user hasn't logged in (after a reboot), these environment variables don't exist. (More info here)
Because we run the Build Agent on a dedicated user account (which never runs explorer.exe), HOMEDRIVE and HOMEPATH resolve to nothing. So GlobalNodeModulePath resolves to \AppData\Roaming\npm, which is not a real path, so the EnsureNodeModules target runs where.exe to find npm, and find the wrong one.
WorkAround
The simple work around for this problem is adding an environment variable: LocalNodeModulePath=%APPDATA%\npm
What do I want?
Finding the source of this problem costed me a lot of time. Really a lot!!
I want to spare future me of those troubles, so it would be nice if this issue is fixed permanently.
How to fix?
I think that this can be fixed by replacing $(HOMEDRIVE)$(HOMEPATH)\AppData\Roaming\npm with $(USERPROFILE)\AppData\Roaming\npm in MSBuild.Node.props
Question: Will this also work on Linux machines?