I've been trying to find out how configuration is dealt with in a Function App. There's mention of App Settings in the portal but not clearly how to access these from code.
There's nothing clearly discussing configuration in .json files, if that's supported or not. There's nothing about using the ASP.NET Core configuration paradigms which are familiar to C# developers, whether the runtime will have made the host's Application Settings (environment variables) available via IConfiguration.
It doesn't state anything about how to set different configuration per environment, either. Whether Application Settings values should be set by the CICD pipeline during deployment.
And I guess then it needs to discuss familiar configuration paradigms for other languages/frameworks, too.
As I type this, I see in the screenshot of the portal a message saying "Application Settings are exposed as environment variables...". This is great but it needs reiterating the documentation in words that can be indexed by Google.
Also, this is misleading. Maybe.
> Connection strings, environment variables, and other application settings are defined separately for each function app.
From my understanding, there's only a set of Application Settings*, and they are actually all environment variables. It's worded as if there are three different types of settings I can set. Moreover, Application Settings would be clearer if they were simply called Environment Variables. This is especially confusing for C# developers as we're used to Application Settings as being a file-based system.
Finally, there's the local.settings.json
which has Values
which I think mimic those set in the portal, so are also just environment variables really. It also has a ConnectionStrings
object but its for compatibility with .NET SDKs, I think.
> Don't use this collection for the connection strings used by your function bindings.
*I assume this maps to the Connection Strings section in the portal and so I assume you're not supposed to use this unless for compatibility reasons.
It's all very confusing. But I appreciate that Functions have to support v1 and v2, and a million different programming languages and all the flux in ASP.NET, too, so documenting all this must be a really tough job.
I wonder if it would be better to clearly separate the Azure hosting, deployment, performance, scale and management as one shared set of docs, and all the development side as self-contained sets of docs for each language, with their own How-to guides and Concepts, Tutorials etc. so each page doesn't have to go on for miles, getting into tangles about the differences between each language.
Thanks for listening.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hi @lukepuplett - Thank you for your feedback! We have assigned this issue to the author to review further and take the right course of action.
I agree with @lukepuplett. I just fell into this trap. The nuances between the ASP.Net Core configuration paradigms should be clearly spelled out. In my instance, I was trying to add a configuration setting for local development and after banging my head for about an hour, I realized that I need to place my settings inside the "Values" section in local.settings.json - I was attempting to place my settings outside the Values section.
+1
I agree, this is such crap, why can the documentation not state on how to handle this properly? Can the documentation not be updated? @mike-urnun-msft
Looks like we've added a section that links to how to use environment variables from code. Let us know if there's anything missing. Thanks!
Most helpful comment
I agree with @lukepuplett. I just fell into this trap. The nuances between the ASP.Net Core configuration paradigms should be clearly spelled out. In my instance, I was trying to add a configuration setting for local development and after banging my head for about an hour, I realized that I need to place my settings inside the "Values" section in local.settings.json - I was attempting to place my settings outside the Values section.