The other day I was working on a solution that used the environment variable HOME
to determine whether or not it is running locally or deployed. When the HOME
was not empty, the path to a file was built with the HOME + \sites\wwwroot\ + relative path
.
public static string getFilename(string basename)
{
var filename = "";
var home = getEnvironmentVariable("HOME");
if (home.Length == 0)
{
filename = "../../../" + basename;
}
else
{
filename = home + "\\site\\wwwroot\\" + basename;
}
return filename;
}
This worked for the solution right up to the point that I decided to add some unit tests to validate my changes.
Symptoms
Locally my unit test worked fine, but when running on a hosted agent the following was the result. Meaning that the unit test did not translate the path to the file as I expected.

Looking into the failure deciding that it could only come from not being able to find a file path.

Digging through the environmental variables of the hosted agent I noticed the culprit. Because the hosted agents also use the environment variable HOME
, the path changed and my tests failed.
Solution
Not wanting to add another dependency on deployment, like introducing a new variable that I only set during deployment to notify the code that you are running in a production setting. I started to look around the environment variables on a deployed Azure function. Using the Console option in the Azure portal, requesting the command: printenv
, noticing the variable WEBROOT_PATH
.
Changing the HOME
to WEBROOT_PATH
solved the problem of my unit tests not working but introduced a new problem running in the Azure portal.
Error getting categories json file: ActivityLogs/ActivityLogCategories.json. Could not find a part of the path ‘D:\Program Files (x86)\SiteExtensions\Functions\2.0.12950\32bit\ActivityLogs\ActivityLogCategories.json’.
Telling me the variable WEBROOT_PATH
was empty at function runtime and, that a relative path could not work because Azure functions are being executed from a program files directory and not the wwwroot
. It appears that due to sandboxing some variables are not accessible during runtime, even if you change the scope of the System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
to use the EnvironmentVariableTarget.Machine
. So what variables can I use then?
Now while I am changing this piece of code I didn’t want to support something that was only there for testing purposes and asking around a colleague of mine mentioned that there is an interface offered by the AzureFunctions\WebJobs that could provide me with the needed information.

Giving me exactly what I need.
Takeaways
- When using azure functions, environment variables are being used to configure your function. Running in a sandbox some variables are not accessible.
- Use the Kudu interface to identify environments variables instead of running console
printenv
. - Use specific descriptive names for your own environment variables instead of generic ones like
HOME
. This reduces the chance of conflicts with systems that are not maintained by you. - Using relative paths don’t work, Azure functions are executed from a different location.
You must be logged in to post a comment.