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