How to modify IConfiguration natively injected in Azure Functions

Question

We need to add configuration providers to the native IConfiguration that is supplied to the Azure Functions natively. Currently we are completely re

Answer 1

A simpler solution would be to override the ConfigureAppConfiguration method in your FunctionStartup class (https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources).

The following example takes the one provided in the documentation a step further by adding user secrets.

public override void ConfigureAppConfiguration(IFunctionsConfigurationBuilder builder)
{
    FunctionsHostBuilderContext context = builder.GetContext();

    builder.ConfigurationBuilder
        .SetBasePath(context.ApplicationRootPath)
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: false)
        .AddJsonFile($"appsettings.{context.EnvironmentName}.json", optional: true, reloadOnChange: false)
        .AddUserSecrets(Assembly.GetExecutingAssembly(), true, true)
        .AddEnvironmentVariables();
}

By default, configuration files such as appsettings.json are not automatically copied to the Azure Function output folder. Be sure to review the documentation (https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources) for modifications to your .csproj file. Also note that due to the way the method appends the existing providers it is necessary to always end with .AddEnvironmentVariables().

A deeper discussion on configuration in an Azure Function can be found at Using ConfigurationBuilder in FunctionsStartup

Answer 2

There's a couple of comments about using a .NET Core Azure functions:

1. When running locally, local.settings.json is loaded for you by default by the framework.
2. You should avoid reading config values from appsettings.json or other files specially when running on the Consumption plan. Functions docs
3. In general, you should refrain from passing around the IConfiguration object. As @Dusty mentioned, the prefer method is to use the IOptions pattern.
4. If you're trying to read values from Azure Key Vault, you don't need to add the AddAzureKeyVault() since you can and should configure this in the azure portal by using Azure Key Vault References. Key Vault Docs. By doing this, the azure function configuration mechanism doesn't know/care where it's running, if you run locally, it will load from local.settings.json, if it's deployed, then it will get the values from the Azure App Configuration and if you need Azure Key Vault integration it's all done via Azure Key Vault references.
5. I think it's also key here that Azure functions configuration are not the same as a traditional .NET application that uses appsettings.json.
6. It can become cumbersome to configure the azure functions app since you need to add settings one by one. We solved that by using Azure App Configuration. You can hook it up to Azure Key Vault too.
7. Application Insights is added by Azure Functions automatically. Docs

That being said, you can still accomplish what you want even though it's not recommend by doing the following. Keep in mind that you can also add the key vault references in the following code by AddAzureKeyVault()

var configurationBuilder = new ConfigurationBuilder();
var descriptor = builder.Services.FirstOrDefault(d => d.ServiceType == typeof(IConfiguration));
if (descriptor?.ImplementationInstance is IConfiguration configRoot)
{
    configurationBuilder.AddConfiguration(configRoot);
}

// Conventions are different between Azure and Local Development and API
// https://github.com/Azure/Azure-Functions/issues/717
// Environment.CurrentDirectory doesn't cut it in the cloud.
// https://stackoverflow.com/questions/55616798/executioncontext-in-azure-function-iwebjobsstartup-implementation
var localRoot = Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot");
var actualRoot = $"{Environment.GetEnvironmentVariable("HOME")}/site/wwwroot";
var basePath = localRoot ?? actualRoot;
var configuration = configurationBuilder
    .SetBasePath(basePath)
    .AddJsonFile("local.settings.json", optional: true, reloadOnChange: false)
    .AddEnvironmentVariables()
    .Build();

builder.Services.Replace(ServiceDescriptor.Singleton(typeof(IConfiguration), configuration));

Let me know if you need more input/clarifications on this and I'll update my answer accordingly.

Answer 3

Option 1: Bring in the base configuration prior to other config providers

// ...

var baseConfig = builder.Services.BuildServiceProvider().GetService<IConfiguration>();

var configuration = new ConfigurationBuilder()
    .AddConfiguration(baseConfig)
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddAzureKeyVault(...)
    .AddJsonFile("local.settings.json", true, true)
    .AddEnvironmentVariables()
    .Build();

// ...

Option 2: Make your custom dependencies finer-grained and use IOptions<T>

Instead of replacing the injected instance of IConfiguration or using Option 1 above, make your downstream services dependent on an IOptions<T>. I think this is the better pattern, as you can break your config up into small segments based on your needs, and have your services take more targeted dependencies.

var configuration = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddAzureKeyVault(...)
            .AddJsonFile("local.settings.json", true, true)
            .AddEnvironmentVariables()
            .Build();

// don't re-bind IConfiguration
// builder.Services.AddSingleton<IConfiguration>(configuration);

// instead, bind sections specific to what services may need
builder.Services.Configure<MyDbConfig>(config.GetSection("DbConfig"));

In this scenario, MyDbConfig is just a POCO with properties to host your config. Your service class takes the dependency on IOptions<MyDbConfig>:

public class MyService : IMyService
{
    private MyDbConfig _dbConfig;
    public MyService(IOptions<MyDbConfig> myDbConfig)
    {
        _dbConfig = myDbConfig.Value;
    }
}

In JSON based configs, you would include "DbConfig" (or whatever argument[s] you supply to GetSection) as a top-level JSON object, with your config values as properties in that object:

{
    "DbConfig": { "SuperSecretValue": "abc123" }
}

In KeyVault, you use -- to indicate the nesting pattern, with a Secret Name like DbConfig--SuperSecretValue.