At first, I’m creating an Azure App Configuration. For the sample app, I’m using the free tier. The free tier is limited to 1000 requests per day and returns a 429 result afterwards, and a maximum of 10 MB for the configuration storage and no SLA. With the production environment a switch to the Standard tier should be done which is about $ 1,20 per day which includes 1 GB storage and 200,000 requests a day.

After the resource is created, configurations can be added using the Configuration explorer. A simple key-value configuration I’m adding is using the key app1:configuration1 and a value. Using colons with the key, a hierarchy of configuration values can be created.

With the Access keys section, the connection string needs to be retrieved – this string is used to access the Azure App Configuration from .NET. A connection string for read-only keys is enough for the application accessing the configuration values. Write access is not needed in that scenario.

Using the Configuration with .NET Applications

With an ASP.NET Core Web application, the Host class is used by default to access configuration values. By default multiple providers are used: a JSON configuration provider to read the configuration from the file appsettings.json, another JSON configuration provider that accesses the file appsettings.{environment}.json, a configuration provider accessing environmental variables, and a configuration provider using command-line arguments.

The connection string to the Azure App Configuration shouldn’t be put in the configuration file that’s stored with the source code repository. Instead, user secrets can be used during development time. The user secretes configuration provider is added to a .NET application if user secrets are used. User secrets are stored in the user profile – so every developer working in a team on this project needs to configure the user secrets as well.

#.net core #asp.net core #azure #configuration #dotnet #dotnetcore