Azure Functions SDK 2.0 settings in accessed in C# code

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

This post was most recently updated on January 10th, 2020.

Reading Time: 6 minutes.

This post describes, how you can access the function’s Application/Environmental settings/variables from your C# code. Different versions of Azure Functions have different ways to access the Azure Function settings. This has been another little thing, that I always forget – so better document it somewhere!

How to get application settings in different runtime versions of Azure Functions?

This has changed between different versions of Azure Functions runtime – so I’m describing what works for your functions using v1 runtime, what works for v2, and of course what works for the function app regardless of the runtime version.

Note, that a lot of the examples below are not specific to Azure Functions – they show how to access app.config or local.settings.json values in C# regardless of the exact implementation, whether it’s a webjob, ASP.NET application, .NET Console program or something else. This post is written from Azure Functions’ view point, though.

Accessing the settings in Azure Functions Runtime Version 1

The 1.x generation of Azure Functions SDK uses the very traditional ConfigurationManager for accessing the Environmental variables or Application Settings. This example below shows how you can, for example, fetch the client id, client secret and Azure AD domain information for use later in the code:

// C# ConfigurationManager example for Azure Functions v1 runtime
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.

In a production workload, you might want to consider using Azure Key Vault instead of the app settings – but that’s a topic for another article!

Accessing the settings in Azure Functions Runtime Version 2

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!

// C# ConfigurationBuilder example for Azure Functions v2 runtime
var config = new ConfigurationBuilder()
 .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
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
        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

Note: If you get an error for .SetBasePath(), .AddJsonFile() or .AddEnvironmentVariables(), basically just add more NuGet packages until the issue is resolved. Sounds confusing, but the different configuration options are now pretty granular – so you’ll need a few packages. I have a list of them just below…

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?)

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:
    • Microsoft.Extensions.Configuration.EnvironmentVariables and possibly
    • Microsoft.Extensions.Configuration.UserSecrets

This rather 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 :)

Accessing the settings in Azure Functions Runtime Versions 1 & 2 for .NET Core < 2.0

While you look at the model for managing the configurations in V2, you might think it looks like a bit of an overkill. That’s ok – if you only need to get application settings, there’s a couple of shortcuts you can take!

Remember the good old GetEnvironmentVariable() ? The one we’ve been using since.. Well, I suppose since .NET Framework 1.1!

Guess what? It still works!

So, if the only thing you need the configuration for is application settings, just run this to return value for key “ClientId”:

// C# Environment Variables example for Azure Functions v1 or v2 runtime
// This works all the way up to but not including .NET Core 2.0
var clientId = Environment.GetEnvironmentVariable("ClientId");
var clientSecret = Environment.GetEnvironmentVariable("ClientSecret");
var aadDomain = Environment.GetEnvironmentVariable("AADDomain");

Interestingly enough, the GetEnvironmentVariable() doesn’t seem to work in .NET Core 2.0 anymore, though.

In case you’re not developing an Azure Function (but rather a Web App or something), you could use the handy “Microsoft.Extensions.Configuration” parameter injected to the Startup method, and you henceforth you can access the application settings like this:

// C# Injected Configuration object example for Azure Functions v2 runtime
// This works for .NET Core 1.x and later!
public class Startup
        public Startup(IConfiguration configuration)
            Configuration = configuration;
        public IConfiguration Configuration { get; }
        public void ConfigureServices(IServiceCollection services)
           var clientId = Configuration["Values:ClientId"];
           // The rest of the implementation omitted ...

… but for an Azure Function, you don’t have it available as is. Instead, you need to work around the architecture a bit…

Accessing the settings in Azure Functions Runtime Versions 2 for .NET Core > 2.0

Okay – so you could go through the whole hullabaloo with gazillion NuGet packages… Or you could try to replicate what you have for Web App projects, because it’s way more neat!

Pretty straightforward, and arguably even better than the GetEnvironmentVariable()!

Where are these configuration keys stored in?

Okay – back to basics for a second. Where do these different methods get their values from? Where do you need to look at, if you’re not getting what you’re expecting?

For Azure Functions app settings, they’re stored either locally in a configuration file, or when deployed, in the Azure (Function) App Service’s application settings (Platform Features > Configuration > Application settings).

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

A couple of great links for further reading below:


Leave a Reply

4 Comment threads
6 Thread replies
Most reacted comment
Hottest comment thread
6 Comment authors
ThanzeelCesarmmJim OwnbySoma S Yarlagadda Recent comment authors
newest oldest most voted
Notify of
Kuttikrishnan P
Kuttikrishnan P

Hi Antti, This is an awesome article and thanks for the detailed steps.

I have tried creating an azure function V2 using core and EF core.There I am using the Starp.cs file and inside that I am doing all my Startup activity like , setting the DBContext , Setting all the dependency .
But inside this I am not able to get the context (“Execution Context”) .It always returns me “null” value . The execution context i wanted to use to set the BasePath of the configuration. But the same is always null in the Startp.cs.

var configuration = new ConfigurationBuilder()
.AddJsonFile(“local.settings.json”, true, reloadOnChange: true)

So please let me know how can make the above code to work.

Appreciate your Support .


Jim Ownby
Jim Ownby

I know this is a bit late for this but you have a typo referencing the NuGet package “Microsoft.Extensions.Configuration.EnvironmentVariables”.


i have tried accessing the nested properties in the file but i dont understad how i can access them after i deploy to azure becouse the is only for local developmet

im using azure function v2,
.netcore 2.2


I don’t understand why we can’t use a static method for reading configuration. What’s the need for this flexibility ? An environment configuration is static by definition. Reading configuration was a trivial task and now it needs new software design in some cases. This is a another very poor .net core decision in my opinion.