Down the rabbit hole – Azure function environment variables

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;
		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.


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.


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.


  • 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 may also like...

Leave a Reply