App Settings in ASP.NET Core and Azure

While building an ASP.NET Core app, I came across the question of how to override application settings after deploying to Azure. Here I will review how application settings are managed in ASP.NET Core and follow on through modifying those values after we deploy to Azure.

Options Pattern

In ASP.NET Core we no longer use web.config to store application settings. Rather, settings are stored in appsettings.json. Actually, you can name this file whatever you wish, and use other formats. You can also have any number of files to store you settings. For instance, you may wish to segregate settings for third party interfaces from your main application settings. For now we will keep it simple and just use appsettings.json.

In my case I am interfacing with Microsoft’s PowerBI in order to embed reports in my site. My appsettings.json file looks like this:

  "PowerBI": {
    "AccessKey": "sgse5sdyw5thisisnotreallythekey+qKp...",
    "ApiUrl": "",
    "WorkspaceCollection": "development",
    "WorkspaceId": "9997004c-1799-4993-9c81-5b6fe999917"
  "ConnectionStrings": {
    "myDatabase": "Server=(localdb)\\ProjectsV12;Database=myData;..."

I bring these settings into my app in Startup.cs

public Startup(IHostingEnvironment env)
    var builder = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
        .AddJsonFile("powerbisettings.json", optional: true, reloadOnChange: true)
    Configuration = builder.Build();

You may have seen this in other examples where it also optionally loads appsettings specific to an environment. Since I am going to set my production settings only in Azure, I am not using that feature.

If you are unfamiliar with the structure of ASP.NET Core applications, you may find this intro helpful:

Options Class

In order to use dependency injection and easily access my options, I created a PowerBIOptions class under an Options folder.

namespace myApp.Options
    public class PowerBIOptions
        public string WorkspaceCollection { get; set; }
        public string WorkspaceId { get; set; }
        public string AccessKey { get; set; }
        public string ApiUrl { get; set; }

In ConfigureServices (back in Startup.cs) I wire up the settings to the object


Connection Strings

Also in ConfigureServices, I can grab the connection string from the Configuration to set up my DbContext. Note that you must name your section “ConnectionStrings” in order for GetConnectionString to find it.

var connection = Configuration.GetConnectionString("myDatabase");
services.AddDbContext<myContext>(options => options.UseSqlServer(connection));

Override Settings in Azure Portal

After deploying your application to Azure you often will want to change connection strings and perhaps other settings that are specific to that deployment. (see here for comprehensive instructions on deploying to Azure:

For my application, I have a database on Azure and I will want to access production reports from PowerBI. In the past we could update connection strings via the Application Settings panel, Connection strings section, on the Azure Portal; and application settings were updated under the App settings section. In fact, there is no change for overriding the connection string.

myDatabase,1433;Initial Catalog=myData;...

Overriding application settings it is very similar but for one important note: since we have a hierarchical structure, we must convey that by placing a colon between the section name and the key name, as follows:

PowerBI:WorkspaceCollection production

After saving the settings, the site will reload, and my Azure site is ready to use.

The new .NET Core configuration options approach provides more flexibility than using web.config, but without being overly complex. That said, as with all new tech, training up some (brain) muscle memory is required. I’ve shown here how we can use the new options pattern and manipulate settings in the Azure deployed site.

Please feel free to provide feedback or ask questions in the comments below.

Share this:
Brian List
Brian List

Brian List is a Senior Software Engineer and Business Analyst with over 20 years of experience in developing applications and managing software projects, including analysis and solution design. Across a variety of team constructs, Brian plans, leads, coordinates, and conducts analyses of business processes and functional requirements. From preparing documentation to communicating and validating analyses, Brian uses his technical expertise to recommend solutions and improve business processes.

Ready to wrangle your data?