Best place to store environment variables for Azure Function

You should have a file called local.settings.json. Here is the azure website for Functions-Run-Local

It states

These settings can also be read in your code as environment variables. In C#, use System.Environment.GetEnvironmentVariable or ConfigurationManager.AppSettings. In JavaScript, use process.env. Settings specified as a system environment variable take precedence over values in the local.settings.json file.

example local.settings.json

{
  "IsEncrypted": false,   
  "Values": {
    "AzureWebJobsStorage": "<connection string>", 
    "AzureWebJobsDashboard": "<connection string>" 
  },
  "Host": {
    "LocalHttpPort": 7071, 
    "CORS": "*" 
  },
  "ConnectionStrings": {
    "SQLConnectionString": "Value"
  }
}

It says that you need to put the application settings under the Values property within the local.settings.json.

To retrieve I used ConfigurationManager.AppSettings["CustomSetting"] as it lets you retrieve connection strings.

I have just been playing around with this and discovered that you have to have a a string key and a string value. I got an error when I tried having a subsection (like you would in an appsettings.json). I had to have the local.settings.json look like this:

{
  "IsEncrypted": false,   
  "Values": {
    "AzureWebJobsStorage": "<connection string>", 
    "AzureWebJobsDashboard": "<connection string>" 
    "CustomSetting":"20"
  }
}

In Azure Functions 2, we moved to ASP.NET Core configuration, and ConfigurationManager is no longer supported. This remains true in 3.

I have seen many articles where people are spraining themselves getting ConfigurationBuilder setups working. The problem is that once you start doing DI, which was recently added, some annoying scenarios arise caused by not having access to a Context parameter (1). It is much cleaner to just use Environment.GetEnvironmentVariable.

This maps perfectly to the configuration model of Azure Functions: in dev, it picks up items in the local.settings.json > Values array, and in production it picks up your environment variables. It just works.

I see no downside other than it's different than what we do in MVC. But this is not MVC, it is Functions, and until MS brings these platforms into better alignment, we should open our minds to what is best in Functions rather than forcing a different paradigm to work here.

Your local.settings.json might look like this:

{
    "IsEncrypted": false,
    "Values": {
        "KeystoneDB": "[CONNECTION STRING HERE]"
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

And in production, you set the environment variables in the portal.

(1) There's no other clean way to satisfy ConfigurationBuilder().SetBasePath that I'm aware of. See: Get root directory of Azure Function App v2