Access App Settings in Azure Functions

Why App Settings Matter for Azure Functions

Tim begins by stating how vital application settings are when building anything beyond the most basic .NET apps. The need to access app settings in Azure Function environments is even more pronounced—given that Azure Functions runtime expects configuration values to be fetched from managed stores such as environment variables, JSON-based local.settings.json, or Azure App Configuration.

“One common feature developers end up wanting is access to a settings file,” Tim explains at 0:17.

Whether for an API key, a connection string, or a feature flag, configuration flexibility and security are paramount—especially when deploying to cloud platforms like Microsoft Azure.

Create the Foundation with Visual Studio

At 1:24, Tim sets up a console project using Visual Studio, naming it SettingsDemoApp. While Azure developers would normally initialize a Functions project using the Azure Functions Core Tools, Tim’s method of scaffolding and organizing the code translates seamlessly. The project file setup and code structure are key foundations—whether you’re in a console environment or building an isolated Azure Functions app with the isolated worker model.

Install the Required NuGet Packages

From 2:33, Tim walks through installing four essential NuGet packages:

• Microsoft.Extensions.Configuration

• Microsoft.Extensions.Configuration.Json

• Microsoft.Extensions.Configuration.Binder

• Microsoft.Extensions.Configuration.UserSecrets

This mirrors the app configuration system used by Azure Functions, which relies on the same packages behind the scenes. Tim emphasizes the value of modularity:

“This is actually the opposite of bloated,” he notes, as .NET Core avoids unnecessary payloads by letting developers opt in via NuGet.

For a typical function app, these packages are either pre-referenced or easily added to support custom logic for configuration settings, dependency injection, or advanced use cases like supporting Key Vault and Azure App Configuration.

Add and Configure a JSON Settings File

At 6:12, Tim creates a new file named appsettings.json, mimicking the structure you'd see in local.settings.json for Azure Functions development. He populates it with key-value pairs like:

{
  "User": {
    "FirstName": "Tim",
    "LastName": "Corey"
  },
  "StarterCountValue": 5
}

In functions locally, developers use local.settings.json in nearly the same format to read values into their application logic via injected IConfiguration. Tim also highlights a key step: setting the file’s Copy to Output Directory to “Copy if newer”—crucial for ensuring your configuration is available at runtime.

Manually Build the Configuration Pipeline

Tim proceeds to write the code that sets up a configuration pipeline manually using:

var builder = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);

Though Azure Functions runtime handles this pipeline automatically, Tim’s breakdown clarifies how functions projects pull in values from different sources. His use of .AddJsonFile() mirrors how developers configure local.settings.json in their Azure app, with reloadOnChange introducing the concept of dynamically refresh configuration settings during development.

Read Values with Type Safety

Tim shows how to read settings using the GetValue() method at 11:00:

int count = config.GetValue<int>("StarterCountValue");

And for nested settings, he uses:

string firstName = config.GetValue<string>("User:FirstName");

When working with Azure Functions, these same syntax patterns apply. Tim’s use of colon-delimited keys ("User:FirstName") has a direct mapping in environment variables using double underscore (__) syntax:

User__FirstName=Tim

This is especially useful when deploying to Azure App Service or configuring via the Azure portal, where you can override settings at runtime using application settings or environment-based overrides.

Handle Secrets Securely with UserSecrets

At 15:00, Tim introduces the secrets.json pattern via User Secrets, used for storing sensitive data like API keys or connection strings without exposing them in source control. He shows how to attach a User Secrets store to your project using this line:

builder.AddUserSecrets<Program>();

He emphasizes that ordering matters—User Secrets override earlier configuration sources, reinforcing the principle of last one wins. While Azure Functions doesn't use secrets.json directly, in a production cloud environment you'd use Azure Key Vault, optionally with managed identity authentication, to achieve the same secure overrides.

Tim notes that secrets in local development are a stand-in for whatever secure system you're using in production:

“This secrets.json is a stand-in for whatever secure system you’re using to store your real values—whether that’s Key Vault or environment settings.”

Run and Validate Configurations

After setting up both appsettings.json and secrets.json, Tim runs the example and validates that secrets override base values. This directly reflects how Azure Functions handle overrides from multiple sources: local.settings.json, Azure App Configuration, environment variables, or Key Vault.

Whether using Azure Functions Core Tools via the command line, or deploying through Visual Studio, the loading order and layering of app configuration behave exactly as Tim outlines.

Best Practices for Configuration Management

Tim closes by recommending keeping config values that don’t change often—like feature flags, frequency settings, or CORS configurations—in your JSON file, and placing sensitive data like connection strings and secrets in a secure store.

This aligns with modern best practices for Azure Functions where:

• Developers use local.settings.json for functions locally

• Teams use the Azure portal for application settings

• Secrets go to Key Vault

• Values from Azure App Configuration store help separate settings from code

These sources integrate with the runtime using dependency injection, without touching application binaries.

Final Thoughts

Though Tim's video is about console apps, every technique he teaches seamlessly extends to Azure Functions apps—from creating config files, reading keys, using managed identity, to loading configuration via dependency injection. Whether deploying with Visual Studio, managing your azure account, or looking to find complete code examples, his insights map directly to real-world cloud practices.