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:

{
  <span class="hljs-attr">"PowerBI"</span>: {
    <span class="hljs-attr">"AccessKey"</span>: <span class="hljs-string">"sgse5sdyw5thisisnotreallythekey+qKp..."</span>,
    <span class="hljs-attr">"ApiUrl"</span>: <span class="hljs-string">"https://api.powerbi.com"</span>,
    <span class="hljs-attr">"WorkspaceCollection"</span>: <span class="hljs-string">"development"</span>,
    <span class="hljs-attr">"WorkspaceId"</span>: <span class="hljs-string">"9997004c-1799-4993-9c81-5b6fe999917"</span>
  },
  <span class="hljs-attr">"ConnectionStrings"</span>: {
    <span class="hljs-attr">"myDatabase"</span>: <span class="hljs-string">"Server=(localdb)\\ProjectsV12;Database=myData;..."</span>
  }
}

I bring these settings into my app in Startup.cs

<span class="hljs-function"><span class="hljs-keyword">public</span> <span class="hljs-title">Startup</span>(<span class="hljs-params">IHostingEnvironment env</span>)
</span>{
    <span class="hljs-keyword">var</span> builder = <span class="hljs-keyword">new</span> ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile(<span class="hljs-string">"appsettings.json"</span>, optional: <span class="hljs-literal">true</span>, reloadOnChange: <span class="hljs-literal">true</span>)
        .AddJsonFile(<span class="hljs-string">"powerbisettings.json"</span>, optional: <span class="hljs-literal">true</span>, reloadOnChange: <span class="hljs-literal">true</span>)
        .AddEnvironmentVariables();
    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: https://docs.asp.net/en/latest/intro.html

Options Class

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

<span class="hljs-keyword">namespace</span> <span class="hljs-title">myApp.Options</span>
{
    <span class="hljs-keyword">public</span> <span class="hljs-keyword">class</span> <span class="hljs-title">PowerBIOptions</span>
    {
        <span class="hljs-keyword">public</span> <span class="hljs-keyword">string</span> WorkspaceCollection { <span class="hljs-keyword">get</span>; <span class="hljs-keyword">set</span>; }
        <span class="hljs-keyword">public</span> <span class="hljs-keyword">string</span> WorkspaceId { <span class="hljs-keyword">get</span>; <span class="hljs-keyword">set</span>; }
        <span class="hljs-keyword">public</span> <span class="hljs-keyword">string</span> AccessKey { <span class="hljs-keyword">get</span>; <span class="hljs-keyword">set</span>; }
        <span class="hljs-keyword">public</span> <span class="hljs-keyword">string</span> ApiUrl { <span class="hljs-keyword">get</span>; <span class="hljs-keyword">set</span>; }
    }
}

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

services.AddOptions();
services.Configure<PowerBIOptions>(Configuration.GetSection(<span class="hljs-string">"PowerBI"</span>));

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.

<span class="hljs-keyword">var</span> connection = Configuration.GetConnectionString(<span class="hljs-string">"myDatabase"</span>);
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: https://docs.asp.net/en/latest/tutorials/publish-to-azure-webapp-using-vs.html)

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 Server=tcp:mydev.database.windows.net,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.

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.
SHARE THIS
Share on twitter
Share on facebook
Share on linkedin
Share on email
RELATED POSTS

Subscribe

Subscribe to CSG Pro. We’ll supply your inbox with the latest blog posts, training videos, and upcoming events.

Ready to wrangle your data?