CODEWITHSUNDEEP
visual-studioazureasp.net-coreappsettings
Valuator
Valuator

Reputation: 3627

How are configuration settings being loaded for ASP.NET Core on Azure?

I have an appsettings.json file with some default settings in it, just a localdb SQL Server connection string and some logging settings. I then have an appsettings.Staging.json file that contains some seed data for the database, and no Connection String. I do not have an appsettings.Production.json file.

When I publish my ASP.NET Core project to Azure, my profile is configured to use an Azure database connection string at runtime as the DefaultConnection. When I publish, an appsettings.production.json file is created on the Azure server that contains the Azure SQL connection string as well as the rest of the settings I had in my appsettings.json file, however the database is created and seeded based on values that are in my appsettings.Staging.json file.

The ASPNETCORE_ENVIRONMENT variable on the server is set to "Staging":

> echo %ASPNETCORE_ENVIRONMENT%
D:\home\site\wwwroot
Staging

When I run my application, it uses the Azure SQL server database, whose connection string only exists in appsettings.production.json.

So my question is: Why is the Connection String from the Production config being used when the ASPNETCORE_ENVIRONMENT variable is set to Staging? And how can it be clearly using settings from both the Production and Staging config files? ASP.NET Core loads configurations like this:

config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
      .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

So I don't see how it can be using settings from anything outside of appsettings.json and appsettings.Staging.json.

Upvotes: 1

Views: 938

Answers (1)

poke
poke

Reputation: 388283

The default WebHostBuilder that is being created with CreateDefaultBuilder in ASP.NET Core 2 comes with a lot of good defaults. One of those is the application configuration:

config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
      .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

if (env.IsDevelopment())
{
    var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
    if (appAssembly != null)
    {
        config.AddUserSecrets(appAssembly, optional: true);
    }
}

config.AddEnvironmentVariables();

if (args != null)
{
    config.AddCommandLine(args);
}

So it will first add the appsettings.json and the appsettings.{environmentName}.json files. Then, if the current environment is a development environment it will also load the user secrets. Then, it will add the environment variables, and finally it will add command line arguments if any were supplied when the application was started.

The way this is set up, environment variables are added to be able to overwrite configuration within JSON files. This is especially made so that for production environments, configuration secrets will not be visible within configuration files but can be specified more secretly as environment variables when the process launches.

Especially for Azure, this is usually the way Azure SQL databases are configured. So in your case, it’s very likely that it’s not the production configuration from the JSON files is being read but instead that Azure provides the connection string via an environment variable.

Upvotes: 2

Related Questions