Configuring a Server-side Blazor app with Azure App Configuration

[xSicKxBot]

Configuring a Server-side Blazor app with Azure App Configuration

July 1st, 2019

With .NET Core 3.0 Preview 6, we added authentication & authorization support to server-side Blazor apps. It only takes a matter of seconds to wire up an app to Azure Active Directory with support for single or multiple organizations. Once the project is created, it contains all the configuration elements in its

Code:

appsettings.json

to function. This is great, but in a team environment – or in a distributed topology – configuration files lead to all sorts of problems. In this post, we’ll take a look at how we can extract those configuration values out of JSON files and into an Azure App Configuration instance, where they can be used by other teammates or apps.

Setting up Multi-org Authentication

In the .NET Core 3.0 Preview 6 blog post we explored how to use the Individual User Accounts option in the authentication dialog to set up a Blazor app with ASP.NET Identity, so we won’t go into too much detail. Essentially, you click the Change link during project creation.

In this example I’ll be using an Azure Active Directory application to allow anyone with a Microsoft account to log into the app, so I’ll select Work or School Accounts and then select Cloud – Multiple Organizations in the Change Authentication dialog.

Once the project is created, my

Code:

AzureAD

configuration node contains the 3 key pieces of information my app’s code will need to authenticate against Azure Active Directory; my tenant URL, the client ID for the AAD app Visual Studio created for me during the project’s creation, and the callback URI so users can get back to my app once they’ve authenticated.

Whilst this is conveniently placed here in my

Code:

appsettings.json

file, it’d be more convenient if I didn’t need any local configuration files. Having a centralized configuration-management solution would be easier to manage, as well as give me the ability to keep my config out of source control, should there come a point when things like connection strings need to be shared amongst developers.

Azure App Configuration

Azure App Configuration is a cloud-based solution for managing all of your configuration values. Once I have an Azure App Configuration instance set up in my subscription, adding the configuration settings is simple. By default, they’re hidden from view, but I can click Show Values or select an individual setting for editing or viewing.

Convenient .NET Core IConfiguration Integration

The Azure App Configuration team has shipped a NuGet package containing extensions to ASP.NET and .NET Core that enable developers the ability of using the service, but without needing to change all your code that already makes use of

Code:

IConfiguration

. To start with, install the

Code:

Microsoft.Extensions.Configuration.AzureAppConfiguration

NuGet package.

You’ll need to copy the connection string from the Azure Portal to enable connectivity between your app and Azure App Configuration.

Once that value has been copied, you can use it with either

Code:

dotnet user-secrets

to configure your app, or using a debug-time environment variable. Though it seems like we’ve created yet one more configuration value to track, think about it this way: this is the only value you’ll have to set using an environment variable; all your other configuration can be set via Azure App Configuration in the portal.

Using the Azure App Configuration Provider for .NET Core

Once the NuGet package is installed, the code to instruct my .NET Core code to use Azure App Configuration whenever it reads any configuration values from

Code:

IConfiguration

is simple. In

Code:

Program.cs

I’ll call the

Code:

ConfigureAppConfiguration

middleware method, then use the

Code:

AddAzureAppConfiguration

extension method to get the connection string from my

Code:

ASPNETCORE_AzureAppConfigConnectionString

environment variable. If the environment variable isn’t set, the call will noop and the other configuration providers will do the work.

This is great, because I won’t even need to change existing – or in this case, template-generated code – I just tell my app to use Azure App Configuration and I’m off to the races. The full update to

Code:

Program.cs

is shown below.

Code:

// using Microsoft.Extensions.Configuration.AzureAppConfiguration; public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration((hostingContext, config) => { config.AddAzureAppConfiguration(options => { var azureAppConfigConnectionString = hostingContext.Configuration["AzureAppConfigConnectionString"]; options.Connect(azureAppConfigConnectionString); }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });

When I run the app, it first reaches out to Azure App Configuration to get all the settings it needs to run and then works as if it were configured locally using

Code:

appsettings.json

. As long as my teammates or other services needing these values have the connection string to the Azure App Configuration instance holding the settings for the app, they’re good.

Now, I can remove the configuration values entirely from the

Code:

appsettings.json

file. If I want to control the logging behavior using Azure App Configuration, I could move these left-over settings out, too. Even though I’ll be using Azure App Configuration as, the other providers are still there.

Dynamic Re-loading

Log levels are a good example of how the Azure App Configuration service can enable dynamic reloading of configuration settings you might need to tweak frequently. By moving my logging configuration into Azure App Configuration, I can change the log level right in the portal. In

Code:

Program.cs

, I can use the

Code:

Watch

method to specify which configuration settings I’ll want to reload when they change.

Code:

public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureAppConfiguration((hostingContext, config) => { config.AddAzureAppConfiguration(options => { var azureAppConfigConnectionString = hostingContext.Configuration["AzureAppConfigConnectionString"]; options.Connect(azureAppConfigConnectionString) .Watch("Logging:LogLevel:Default") .Watch("Logging:LogLevel:Microsoft") .Watch("Logging:LogLevel:Microsoft.Hosting.Lifetime"); }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });

The default load-time is 30 seconds, but now, should I need to turn up the volume on my logs to get a better view of what’s happening in my site, I don’t need to re-deploy or even stop my site. Simply changing the values in the portal will be enough – 30 seconds later the values will be re-loaded from Azure App Configuration and my logging will be more verbose.

Configuration Source Ordering

The

Code:

JsonConfigurationSource

configuration sources – those which load settings from

Code:

appsettings.json

and

Code:

appsettings.{Environment}.json

– are loaded during the call to

Code:

CreateDefaultBuilder

. So, by the time I call

Code:

AddAzureAppConfiguration

to load in the

Code:

AzureAppConfigurationSource

, the JSON file providers are already in the configuration sources list.

The importance of ordering is evident here; should I want to override the configuration values coming from Azure App Configuration with my local

Code:

appsettings.json

or

Code:

appsettings.Development.json

files, I’d need to re-order the providers in the call to

Code:

ConfigureAppConfiguration

. Otherwise, the JSON file values will be loaded first, then the last source (the one that will “win”) will be the Azure App Configuration source.

Try it Out

Any multi-node or microservice-based application topology benefits from centralized configuration, and teams benefit from it by not having to keep track of so many configuration settings, environment variables, and so on. Take a look over the Azure App Configuration documentation. You’ll see that there are a multitude of other features, like Feature Flags and dark deployment support. Then, create an instance and try wiring your existing ASP.NET Code up to read configuration values from the cloud.

Brady Gaster

Senior Program Manager, ASP.NET Core

Follow    https://devblogs.microsoft.com/aspnet/au...-com/feed/