Azure Functions SDK 2.0 settings in accessed in C# code

How to access Azure Function App’s settings from C#?

Different versions of Azure Functions have different ways to access the Azure Function settings. This is another little thing, that I always forget – so better document it somewhere!

So, this post describes, how you can access the function’s Application/Environmental settings/variables from your C# code.

Accessing the settings in Azure Functions SDK 1.x

The 1.x generation of Azure Functions SDK uses the very traditional ConfigurationManager for accessing the Environmental variables or Application Settings. An example:

var clientId = System.Configuration.ConfigurationManager.AppSettings["ClientId"];
var clientSecret = System.Configuration.ConfigurationManager.AppSettings["ClientSecret"];
var aadDomain = System.Configuration.ConfigurationManager.AppSettings["AADDomain"];

Nice and easy! ConfigurationManager is the good-old way of getting your hands on the settings. It exploses AppSettings, which is just a NameValueCollection – with a key (or “name”), you get back a string-typed value.

Accessing the settings in Azure Functions SDK 2.x

For the second generation of Azure Functions, the logic changes a bit. Not quite as straightforward, but more flexible. ConfigurationManager is not used anymore. Instead, you’re supposed to use ConfigurationBuilder. Check out the code example below!

var config = new ConfigurationBuilder()
 .SetBasePath(context.FunctionAppDirectory)
 .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
 .AddEnvironmentVariables()
 .Build();
 
var clientId = config["ClientId"];
var clientSecret = config["ClientSecret"];
var aadDomain = config["AADDomain"];

This piece of code fetches the configuration keys from a file called “local.settings.json”. This file is typically added to your Visual Studio Azure Functions project when it was first created. However, if you’re jumpin on a project that was created by someone else, they might’ve .gitignore’d the configuration file (as they probably should), so you didn’t get the file.

You’ll also need to add a reference to Microsoft.Extensions.Configuration and a new parameter “ExecutionContext context” to your function – see below:

using Microsoft.Extensions.Configuration;
 
...
 
namespace YourNamespace
{
    public static class YourClass
    {
 
        ...
 
        [FunctionName("FunctionName")]
        public static async Task RunAsync([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]HttpRequest req, TraceWriter log, ExecutionContext context)
        {
           ...

You might also need to add a NuGet package for Microsoft.Extensions.Configuration – should be easy enough!

Adding Microsoft.Extensions.Configuration Nuget package
Adding Microsoft.Extensions.Configuration NuGet package

If you get error for .SetBasePath(), .AddJsonFile() or .AddEnvironmentVariables(), just add more NuGet packages until the issue is resolved. Your error might be something like this:

Error CS1061

‘IConfigurationBuilder’ does not contain a definition for ‘AddEnvironmentVariables’ and no accessible extension method ‘AddEnvironmentVariables’ accepting a first argument of type ‘IConfigurationBuilder’ could be found (are you missing a using directive or an assembly reference?) DelegatedFunction

There are a lot of NuGet packages to help you out! Start with these:

  • SetBasePath() requires:
    • Microsoft.Extensions.Configuration.Abstractions
  • AddJsonFile() requires:
    • Microsoft.Extensions.Configuration.FileExtensions
    • Microsoft.Extensions.Configuration.Json
  • AddEnvironmentVariables() requires: 
    • Extensions.Configuration.EnvironmentVariables and possibly
    • Microsoft.Extensions.Configuration.UserSecrets

This rathare granular approach to configurations might optimizing the size and performance of the resulting software package, but it does make parts of the development cycle just a bit frustrating 🙂

Where are these configuration keys stored in?

An example of a configuration file (“local.settings.json”) containing these values is below:

{
 "IsEncrypted": false,
 "Values": {
  "AzureWebJobsStorage": "",
  "AzureWebJobsDashboard": "",
  "ClientID": "[your value here]", // "Application ID" from Azure AD app registration!
  "ClientSecret": "[your value here]",
  "AADDomain": "[your value here]"
 }
}

Does this look familiar? It might – that’s how application settings are accessed in ASP.NET Core. Unlike the 1.x version, 2.0 is using ASP.NET Core Configuration.

See more info

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!