How to read configuration settings before initializing a Host in ASP .NET Core?

Question

Before initializing the application Host I need to read some settings from the application's configuration to setup some other things.

In ASP .NET Core 2.x to read settings before initializing the application Host I used to do the following:

public static void Main(string[] args)
{
    //...

    var configuration = new ConfigurationBuilder()
        .AddEnvironmentVariables()
        .AddCommandLine(args)
        .AddJsonFile("appsettings.json")
        .Build();

    //Do something useful with the configuration...

    var host = WebHost.CreateDefaultBuilder()
        .UseStartup<Startup>()
        .UseConfiguration(configuration)
        .Build();

    //...
}

In ASP .NET Core 3.x WebHost has been deprecated in favor of .NET Generic Host.
.NET Generic Host has only .ConfigureHostConfiguration() and .ConfigureAppConfiguration() that do not take a built configuration as parameter, but instead accept only a delegate used to setup the configuration.

For HTTP workloads you can still use the method .UseConfiguration() has it is exposed by IWebHostBuilder and do essentially the same as before:

public static void Main(string[] args)
{
    //...

    var configuration = new ConfigurationBuilder()
        .AddEnvironmentVariables()
        .AddCommandLine(args)
        .AddJsonFile("appsettings.json")
        .Build();

    //Do something useful with the configuration...

    var host = Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>()
                .UseConfiguration(configuration);
        })
        .Build();

    //...
}

But this only works for HTTP workloads and not for Worker Services.

To get the configuration before setting up the Host I've come up with the following approach:

public static void Main(string[] args)
{
    //...

    var configuration = ConfigureConfigurationBuilder(args)
        .Build();

    //Do something useful with the configuration...

    var host = Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration(builder => ConfigureConfigurationBuilder(args, builder))
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        })
        .Build();

    //...
}

public static IConfigurationBuilder ConfigureConfigurationBuilder(string[] args, IConfigurationBuilder configurationBuilder = null)
{
    configurationBuilder ??= new ConfigurationBuilder();

    configurationBuilder
        .AddEnvironmentVariables()
        .AddCommandLine(args)
        .AddJsonFile("appsettings.json");

    return configurationBuilder;
}

Essentially I've wrote a method that setups a ConfigurationBuilder and returns it, so that I can reuse the same configuration. This works in practice, but I build the same configuration twice.

Is there a simpler/more correct way (that works for HTTP workloads and non-HTTP workloads) to build and reuse the configuration before setting up the Host ?

Answer 1

You can clear the default sources added by CreateDefaultBuilder then add a pre-built IConfiguration with the AddConfiguration extension method.

public static void Main(string[] args)
{
    //...

    var configuration = new ConfigurationBuilder()
        .AddEnvironmentVariables()
        .AddCommandLine(args)
        .AddJsonFile("appsettings.json")
        .Build();

    //Do something useful with the configuration...

    var host = Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration(builder =>
        {
            builder.Sources.Clear();
            builder.AddConfiguration(configuration);
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        })
        .Build();

    //...
}

Answer 2

The answer by UncleDave is certainly the best and most correct way to do this, but if you want to use the default configuration without recreating the logic yourself, it is not easy to get access to the IConfiguration and the IWebHostBuilder in the same place.

In order to do this, you can take advantage of the fact that the concrete Configuration is built before other services such as the web host are built. You can use ConfigureAppConfiguration() to access the config then use it to continue building the IWebHostBuilder.

For example:

public static async Task Main(string[] args)
{
    var hostBuilder = Host.CreateDefaultBuilder(args);
    var builder = hostBuilder
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();

            // make sure to put this at the end of this method
            webBuilder.ConfigureAppConfiguration(configBuilder =>
            {
                // compile a temporary configuration instance
                var configuration = configBuilder.Build();

                // Check config values as you would normally
                var myConfig = new MyConfig();
                configuration.Bind("MyConfigSection", myConfig);
                if (myConfig.UseSentryLogging)
                {
                    // configure the web host based on config
                    webBuilder.UseSentry();
                }
            });
        });

    var host = builder.Build();
    await host.RunWithTasksAsync();
}

If you are configuring other services which can affect where configuration is read from, then you may find you need to store a reference to the IWebHostBuilder and call ConfigureAppConfiguration on the IHostBuilder instead. Make sure you call ConfigureAppConfiguration last so that the other configuration setup can take place first and you access it correctly:

public static async Task Main(string[] args)
{
    // we store the reference to the webHostBuilder so we can access it outside of ConfigureWebHost
    IWebHostBuilder _webBuilder = null;

    var hostBuilder = Host.CreateDefaultBuilder(args);
    var builder = hostBuilder
        .ConfigureWebHostDefaults(webBuilder =>
        {
            // store the builder for later
            _webBuilder = webBuilder;
            webBuilder.UseStartup<Startup>();
        })
        .ReadConfigFromSomewhereElse()
        .ConfigureAppConfiguration(configBuilder =>
        {
            // compile a temporary configuration instance
            var configuration = configBuilder.Build();

            // Check config values as you would normally
            var myConfig = new MyConfig();
            configuration.Bind("MyConfigSection", myConfig);
            if (myConfig.UseSentryLogging)
            {
                // configure the web host based on config
                _webBuilder.UseSentry();
            }
        });

    var host = builder.Build();
    await host.RunWithTasksAsync();
}

Note this is a little bit of a hack and so may not work in all cases.

Answer 3

The right question is, do you really need a configuration for your configuration? You can use another file, and bind it directly with entity

configuration.GetSection("entity").Bind(entity);

If I didn't understand what you mean, all I know is that the setup you will need it for dependency injection, or you can't use it, so instead of using this, you can use Extensions for your service collection to do what you want with your configuration, and you get the setup in your container.

Answer 4

You can also do something like this. In my own case I needed the "Configuration" in the Program.cs, to pass it to my extension method. The extension method was in "MyExtension.cs" class, and in this class I used the namespace Microsoft.Extensions.DependencyInjection.

In your Program.cs you can use hostContext to retrieve the Configuration:

     using Scheduler.Job;
        
        IHost host = Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                // Retrieve the appsettings configuration
                IConfiguration configuration = hostContext.Configuration;
        
                // Add my extension method and pass the configuration to be binded
                services.AddMyExtensionsMethod(configuration);
        
                services.AddHostedService<MyTimerService>();
            })
            .Build();
        
        await host.RunAsync();

Here the content of MyExtensions.cs, where I will bind the appsettings using a model, and I will add my scoped service:

    // I extended the DI namespace to use AddMyExtensionsMethod in Program.cs
    namespace Microsoft.Extensions.DependencyInjection
    {
        public static class MyExtensions
        {
            // I show only ONE public method to the services in Program.cs, and inside MyExtensions class I add all the private methods with services I need in DI. In this way I add a layer separation        
            public static IServiceCollection AddMyExtensionsMethod(this IServiceCollection services, IConfiguration configuration)
            {
                return services.AddProviders(configuration);
            }
    
            // Here I bind the appsettings configuration with my appsettings ConfigurationModel (a class that represent the appsettings.json object that I need), to pass it in DI
            private static IServiceCollection AddMyProviders(this IServiceCollection services, IConfiguration configuration)
            {
                // Bind the appsettings on my ConfigurationModel
                ConfigurationModel config = configuration.Get<ConfigurationModel>();
    
                // Add my service as scoped
                services.AddScoped<IProviderPluto>(x => new ProviderPluto(config,  x.GetRequiredService<ILogger<PostCallerProvider>>()));
    
                return services;
            }
        }
    }

Answer 5

By default ConfigureAppConfiguration() will load appsettings.json according to the documentation Default builder settings.

Alternatively, if you can't access your configuration or you are getting System.NullReferenceException: 'Object reference not set to an instance ofan object.' error, it means the IHostBuilder can't see the json file in it base path.

Check or change the appsettings.json file properties as seen in the image below:

1. Set "Build Action" to "Content"
2. Set "Copy to Output Directory" to "Copy if newer"