The Microsoft documentation states that
App settings can be read from environment variables both when developing locally and when running in Azure. When developing locally, app settings come from the Values collection in the local.settings.json file. In both environments, local and Azure, GetEnvironmentVariable("") retrieves the value of the named app setting. For instance, when you're running locally, "My Site Name" would be returned if your local.settings.json file contains { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.
The System.Configuration.ConfigurationManager.AppSettings property is an alternative API for getting app setting values, but we recommend that you use GetEnvironmentVariable as shown here.
It is not stated why it is the recommended way.
Or do I just accept this as a fact of life without knowing why?
AzureWebJobsStorage. The Azure Functions runtime uses this storage account connection string for normal operation. Some uses of this storage account include key management, timer trigger management, and Event Hubs checkpoints. The storage account must be a general-purpose one that supports blobs, queues, and tables.
To set environment variables when you start a container in the Azure portal, specify them in the Advanced page when you create the container. Under Environment variables, enter NumWords with a value of 5 for the first variable, and enter MinLength with a value of 8 for the second variable.
Does it have performance advantages?
I will say generally it does based on my test. GetEnvironmentVariable
is a little faster than ConfigurationManager
, on my pc(100k times) its average execution time is about 20μs shorter and on Azure(B1 app service plan, 10k times) is about 12μs shorter . It's a statistic conclusion as ConfigurationManager
can be faster sometimes.
Is there is an instance where reading from AppSettings would result in an empty value?
If values to be read are set as expected, there may be only one scenario that we get null by using ConfigurationManager
--In v2 function, where it's not useful any more.
Is it just for compatibility with different configuration formats (i.e., json, xml, etc)?
GetEnvironmentVariable
has no such ability and there's no requirement for format compatibility. It's by design that Azure functions get configuration from local.settings.json in local development, when function host starts, app settings in Values
are imported into environment variables of current process. So no format consideration.
To conclude, GetEnvironmentVariable
is
System.Configuration
to use ConfigurationManager
.ConnectionStrings
in local.settings.json).Of course we can still leverage ConfigurationManager
in v1 functions and we have to use it if we want to get ConnectionStrings
locally.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With