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