AzureWebJobsScriptRoot variable is not defined on Azure Functions, but defined locally

[PingPongSet]

AzureWebJobsScriptRoot variable is not defined on Azure Functions. The code below returns no value.
System.Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Process)["AzureWebJobsScriptRoot"];
Is this a bug with Azure Functions?

If so, what is an alternative solution?

Before the issue is fixed by Microsoft, can this variable, AzureWebJobsScriptRoot, be defined myself to "%HOME%\site\wwwroot" on Azure?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 18aa54fd-3aa1-37c5-925c-51a0195b1030
• Version Independent ID: 60198016-1ea9-e7ae-b00b-2c665d5ad8ca
• Content: App settings reference for Azure Functions
• Content Source: articles/azure-functions/functions-app-settings.md
• Service: azure-functions
• GitHub Login: @ggailey777
• Microsoft Alias: glenga

[mike-urnun-msft]

Hi @PingPongSet Thank you for your feedback! We will review and update as appropriate.

[DixitArora-MSFT]

@PingPongSet We are working with Product group on this and will share the findings soon.

[paulbatum]

If you configure a function app with a different value for AzureWebJobsScriptRoot, then the functions host should honor that new value. For example, if you set AzureWebJobsScriptRoot = D:\home\site\wwwroot\foo then the functions host would look for a host.json file and function directories in the D:\home\site\wwwroot\foo location.

By default, this environment variable is not set. So it is expected that if you did not set it yourself, then System.Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot") will return null.

Be aware that if you modify this setting, other components like the portal, visual studio, visual studio code, etc will not be aware of setting and will deploy your code to the normal default location. If you want to customize this setting, its up to you to make sure the application code is deployed to the right location.

[PingPongSet]

@paulbatum,

Thanks for your reply.

First, can you please confirm the path where Functions apps are installed is "D:\home\site\wwwroot"? and the D drive and folder path will not change, or there is no plan to change.

Second, please rectify the doc below, as it is contractory to what you said. This will make it official.

" In a function app, the default is %HOME%\site\wwwroot."
https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azurewebjobsscriptroo

Third, Can you explain is it a bug with Azure Functions or an error with the document?

[paulbatum]

1. Yes. You can confirm this yourself. Just make a new function app in VS, or the portal, or anywhere really, and deploy. Then go to the kudu console (platform features -> Advanced tools (kudu)) and look at the file system. Or use the console option (platform features -> console).

2. Not sure what doc edit you are asking for? The doc correctly states what the default is if the user does not specify the AzureWebJobsScriptRoot setting.

3. Sorry, what bug?

One final note. If you're looking to discover the root path through application code, you can do it by having your function take an ExecutionContext and then access FunctionAppDirectory e.g.

        public static void Run([TimerTrigger("*/5 * * * * *")]TimerInfo myTimer, ExecutionContext executionContext, ILogger log)
        {
            log.LogInformation(executionContext.FunctionAppDirectory);
            log.LogInformation(executionContext.FunctionDirectory);            
        }

[DixitArora-MSFT]

@PingPongSet Just following up here.. Hope previous comment helps.Do let us know if you have any further queries

[PingPongSet]

Please re-read the content on my previous comments where details are specified on the bug.

Don't you think this is a bug with Azure Function? The variable returns correct value locally, but it is NOT defined on Azure Function when it is documented its default value of the document: https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azurewebjobsscriptroo

ExecutionContext doesn't work when dependency injection via constructor is used.

[DixitArora-MSFT]

@PingPongSet Behavior is expected as Paul has already share the details regarding this.

[PingPongSet]

Again, the documentation and implementation of this variable is an issue/bug, as I mentioned on previous comments.

I don't want to spend more time on this now because we don't reach the agreeement.

[paulbatum]

I have reread your post. In it you say:

The code below returns no value.

System.Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Process)["AzureWebJobsScriptRoot"];

Is this a bug with Azure Functions?

The answer is no. The expected behavior is that code would return null unless you add an app setting with name AzureWebJobsScriptRoot.

When the documentation says In a function app, the default is %HOME%\site\wwwroot it means that if you do not specify this environment variable, the functions host will use %HOME%\site\wwwroot.

It does not mean that running the code System.Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot") will return %HOME%\site\wwwroot

This is true for many of the settings listed on that same doc page (e.g AzureWebJobsDisableHomepage, AzureWebJobsDotNetReleaseCompilation).

[paulbatum]

@DixitArora-MSFT I think this issue can be closed.

[irakliy81]

@paulbatum - it doesn't seem like Azure is honoring the AzureWebJobsScriptRoot setting. If I set it to something like D:\home\site\wwwroot\foo, it is still loading functions from D:\home\site\wwwroot (even though I have host.json and function folders under D:\home\site\wwwroot\foo).

The setting seems to work correctly in local environments, but not on Azure.

[paulbatum]

Ahh, thank you. I did not realize that it works this way (perhaps it changed at some point), but it does look consistent with this implementation:

https://github.com/Azure/azure-functions-host/blob/690321b72c45f61f9d665ff8c23f980bc31c1c85/src/WebJobs.Script.WebHost/Configuration/WebScriptHostConfigurationSource.cs#L42-L63

Note specifically that the AzureWebJobsScriptRoot setting is only used locally. Perhaps this is what @PingPongSet was referring to and I misunderstood?

I think it would make sense to remove the documentation for this setting, given that it is not used in Azure.

@DixitArora-MSFT @ggailey777 can we reopen this, and use this issue to track the doc update?

[irakliy81]

@paulbatum - thank you for the clarification! Would it make sense to create a separate issue asking to make AzureWebJobsScriptRoot setting work in Azure too? This could be very useful in some scenarios I'm working on.

[paulbatum]

You could file a new issue in https://github.com/Azure/azure-functions-host requesting this feature.

Thinking about it a little more, I am starting to have an idea about why this setting doesn't work in Azure. Lets say you deploy a function app with two different folders, each with a different set of functions in them, and you are updating this app setting to switch between them. We would need to make sure that every time you change this app setting, our scale infrastructure discovers which set of functions are active. I don't think we have a reliable way to make sure that happens today. There is an explicit 'synctriggers' ARM action you can call, but customers changing this setting that don't call this action would sometimes find that their function does not scale as expected.

Please include this observation in the issue, if you file it.

[ggailey777]

The linked PR removes the AzureWebJobsScriptRoot setting. We can add this back if 1) it's needed for Linux containers or 2) the proposed feature is added.

[yubozhao]

We should remove this setting in the generated Dockerfile. It really confused users(like me) to think we can change the ENV to some other directory.