Configuration with `__` (two underscores) or `:` not consistent

[mdekrey]

I believe there is an inconsistency in configuration variables when running a netstandard2.0 library. I use hierarchical configuration via Microsoft.Extensions.Configuration, such as:

{
  "Storage": {
    "Processing": "--my connection string--"
  }
}

When translated to environment variables, such as provided by the app settings in the azure portal, I can achieve this by using __:

Application Setting Key: Storage__Processing
Value: --my connection string--

This gets translated to a : in the IConfiguration object, or I can access by the "Storage" section.

For Azure Functions, however, when debugging locally, the __ in my local.settings.json file does get swapped to a :. As a result, my QueueTrigger needs to be set to Storage:Processing for local debugging. When running on the Azure cloud, the __ does not get translated as expected for an environment variable; I must provide Storage__Processing for production.

Investigative information

Please provide the following:

• Timestamp: Between 2018-02-03T13:56:38 and 2018-02-03T13:59:38
• Function App version (1.0 or 2.0-beta): 2.0-beta
• Function App name: functionapptyjpt3z5zrhzw
• Function name(s) (as appropriate): FetchAsset
• Invocation ID: N/A
• Region: South Central US

Repro steps

Provide the steps required to reproduce the problem:

1. Set up a precompiled netstandard2.0 azure functions application via Visual Studio.
2. Add a function using a connection string (such as a queue trigger) where the connection string has a __ (two underscores) in it, such as Storage__Processing.
3. Make sure the connection string is in the ConnectionStrings section of the local.settings.json.
4. Set up a function using the same connection string, but reference it using a : in the C# attribute, such as Connection = "Storage:Processing".
5. Test the functions locally. Observe the output in the console window.
6. Publish to Azure with a "Connection String" set as Storage__Processing with a type of "Custom" and test.
7. Attempt to trigger the function by enqueuing a message. Observe the logs.

Expected behavior

Provide a description of the expected behavior.

1. At least one of the local functions should run successfully.
2. The same function should run successfully in the cloud. (I am unopinionated as to which, but I would prefer it was Storage:Processing to be consistent with the rest of .Net Core's configuration. It could also be both, if you wanted to be resilient.)

Actual behavior

Provide a description of the actual behavior observed.

1. Storage:Processing runs locally.
2. Storage__Processing runs in the cloud.

Known workarounds

Provide a description of any known workarounds.

1. Do not use hierarchical configuration settings for azure functions.

Related information

Provide any related information

• C#, netstandard 2.0
• Microsoft.Azure.WebJobs version: 3.0.0-beta4
• I can provide a repro library, but have not built the simple case in a spot where it can be shared

Edited

Removed information about the "connection strings" name difference. I haven't done enough investigation on that, and it should be a different issue anyway if it is a problem.

[APErebus]

I've just run into this issue as well. It's come up for us as we deploying the function into a docker container that's running on a Linux App Service plan and as such the recommendation is the use the double underscore __ to delimit the hierarchy.

I'd be interested in hearing what other people have done here. Our work around is to use a single underscore _ rather than the double underscore __

[zihotki]

I can confirm that even using .Net 8 and isolated process the function runtime doesn't translate the settings coming from the App Configuration. It does translate the settings coming from the environment variables.

That contradicts the official guidance - https://learn.microsoft.com/en-gb/azure/azure-functions/functions-app-settings#app-setting-considerations

So for anybody stumbled and looking for quick answers:

• if you use Azure App Configuration - use semicolon : as a section delimiter
• if you use Azure Key Vault - use double dash -- as a delimiter
• if you pass settings via environment variables - use double underscore __ as a delimiter

This approach works both for web and for functions.