Please help me understand the reasons for limitations of local.settings.json and the best practices around it

[IanKemp]

I have local.settings.json with the following defined:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "StorageQueue__ConnectionString": "<elided>"
    }
}

The reasons are:

1. Our deployment process pushes the content of local.settings.json to Azure and [I want my settings to be compatible between Windows and Linux hosts]().
2. I cannot use the following, proper hierarchical configuration:

   {
   "IsEncrypted": false,
   "Values": {
       "AzureWebJobsStorage": "UseDevelopmentStorage=true",
       "FUNCTIONS_WORKER_RUNTIME": "dotnet",
       "StorageQueue": {
           "ConnectionString": "<elided>"
       }
   }
   }

because it is explicitly unsupported by the local.settings.json schema and apparently the host, as this causes host startup to fail with Can't determine project language from files and Missing value for AzureWebJobsStorage in local.settings.json.

However if I use the first snippet (with StorageQueue__ConnectionString), the queue trigger that I have bound via the following:

[QueueTrigger("queuename", Connection = "StorageQueue__ConnectionString")]

causes the host to fail on startup with:

Warning: Cannot find value named 'StorageQueue__ConnectionString' in local.settings.json that matches 'connection' property set on 'queueTrigger'...
...
Microsoft.Azure.WebJobs.Host: Error indexing method '<queue-trigger-function-name>'. Microsoft.Azure.WebJobs.Extensions.Storage: Storage account connection string 'AzureWebJobsStorageQueue__ConnectionString' does not exist. Make sure that it is a defined App Setting.
...
Function '<queue-trigger-function-name>' failed indexing and will be disabled.

The same happens if I change my queue trigger to:

[QueueTrigger("queuename", Connection = "StorageQueue:ConnectionString")]

At the end of the day, therefore, the only combination that works is using : as the hierarchy separator. But that does not take into account non-Windows systems, to my mind. Yes, I know we could update our deployment process to substitute __ for : when pushing to Azure, but I would rather avoid touching said process as far as possible.

The most obvious solution would be to use appsettings.json as well as local.settings.json because the former isn't subject to the completely arbitrary limits of the latter's schema, which (I assume) would allow me to use proper hierarchical config without caring about separators - but #122 says that using both together is no longer supported... but https://github.com/Azure/azure-functions-host/issues/4761 says it is.

But when I try to use appsettings.json by overriding FunctionsStartup.ConfigureAppConfiguration (as per https://github.com/Azure/azure-functions-dotnet-extensions/pull/33), the host behaves as if the file doesn't exist - I get the same Warning: Cannot find value named 'StorageQueue__ConnectionString' in local.settings.json that matches 'connection' property set on 'queueTrigger' message as above. (Yes, I have ensured the file is copied to the output dir on build.)

Basically, it's a very tangled mess and I'm trying to get some clear guidance here. Please can you advise:

• Does the Azure Functions local host (func.exe) properly support appsettings.json?
• If the answer to the above is "yes", what am I doing wrong/why is this not working as I expect?
• If the answer to the first question "yes", why should I use local.settings.json at all when I could just use appsettings.json? Can I simply pretend that the local.settings.json that's generated on project creation does not exist, and add all my nested configuration hierarchies in appsettings.json instead?

[IanKemp]

Bump.

[apawast]

@IanKemp thanks for opening this issue! Local host does no support appsettings.json. We have added this to the backlog but at this time this issue is not of the highest priority. We will keep this issue open and monitor to see if it gains traction from users.

[ranouf]

Good to know, it tooks hours to understand why.

Strangely, I'm able to have information from AppSettings using IOptions but it failed each time I use to customize the TimeTrigger occurence like %MyOccurence%.

I hope, this will be fix one day, it's useful, and there will be consistency with web api and azure web job, which give the job easier for dev :)