ConfigurationManager.AppSettings does not list values that are in my app.config file

If I add watch to it, its only got the keys for the two "Values" items in the local.settings.json. Those "values" items aren't even labeled as AppSettings! How is is that remotely intuitive?

I dont **want** to ever use a json file for configuration - I fell for that fad a few years ago and regretted it. Json is for data, and it doesnt support comments to add directions or guidance for each config setting. It was suggested to me recently (in an issue I logged in the wrong repo) that I should just do this...

``` json
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true", //storage settings
"AzureWebJobsDashboard": "UseDevelopmentStorage=true" //dashboard
}
}
```
... which is not legal. Trying to bake in that kind of thing as a feature is how MSIE became so _loved_ by web devs.

The AZ portal doesnt support comments either and I don't want to have to hand key _all of the existing appSettings values my function or its dependencies need_ into the AZ portal.

There are .net configuration points that are not appSettings and not connectionStrings. How are we supposed to configure WCF client bindings in a json format? Surely the recommendation is not to hard code them. In addition to WCF, protected configuration (probably not relevant to this), connection strings, assembly binding redirects (both very relevant to this), and a few other things all seem to be unusable in an azure function due to this design choice.

Why should we be coerced into using a different configuration subsystem in the first place? There is/was nothing wrong with using XML. Why reinvent the wheel with json and not give us the chance to opt-out?

Start by reviewing the ConfigurationManager.AppSettings entry point and how the Azure Functions host reads local.settings.json. The issue names no source file or test; completion would require deciding and validating how broader .NET configuration, including appSettings and WCF bindings, should be supported.

Written by the indexing model from the issue text.