{"id":95974,"date":"2019-07-01T17:01:11","date_gmt":"2019-07-01T17:01:11","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/aspnet\/?p=22289"},"modified":"2019-07-01T17:01:11","modified_gmt":"2019-07-01T17:01:11","slug":"configuring-a-server-side-blazor-app-with-azure-app-configuration","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2019\/07\/01\/configuring-a-server-side-blazor-app-with-azure-app-configuration\/","title":{"rendered":"Configuring a Server-side Blazor app with Azure App Configuration"},"content":{"rendered":"
\n
\n
\"Avatar\"<\/div>\n<\/div>\n<\/div>\n
\n

July 1st, 2019<\/p>\n<\/p><\/div>\n

<\/p>\n

With .NET Core 3.0 Preview 6<\/a>, 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 appsettings.json<\/code> to function. This is great, but in a team environment \u2013 or in a distributed topology \u2013 configuration files lead to all sorts of problems. In this post, we\u2019ll 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.<\/p>\n

Setting up Multi-org Authentication<\/h2>\n

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

\"Click<\/p>\n

In this example I\u2019ll be using an Azure Active Directory application to allow anyone<\/em> with a Microsoft account to log into the app, so I\u2019ll select Work or School Accounts<\/strong> and then select Cloud \u2013 Multiple Organizations<\/strong> in the Change Authentication dialog.<\/p>\n

\"The<\/p>\n

Once the project is created, my AzureAD<\/code> configuration node contains the 3 key pieces of information my app\u2019s 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\u2019s creation, and the callback URI so users can get back to my app once they\u2019ve authenticated.<\/p>\n

\"The<\/p>\n

Whilst this is conveniently placed here in my appsettings.json<\/code> file, it\u2019d be more convenient if I didn\u2019t 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.<\/p>\n

Azure App Configuration<\/h2>\n

Azure App Configuration<\/a> 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\u2019re hidden from view, but I can click Show Values<\/strong> or select an individual setting for editing or viewing.<\/p>\n

\"The<\/p>\n

Convenient .NET Core IConfiguration Integration<\/h3>\n

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 IConfiguration<\/code>. To start with, install the Microsoft.Extensions.Configuration.AzureAppConfiguration<\/code> NuGet package<\/a>.<\/p>\n

\"Adding<\/p>\n

You\u2019ll need to copy the connection string from the Azure Portal to enable connectivity between your app and Azure App Configuration.<\/p>\n

\"Copying<\/p>\n

Once that value has been copied, you can use it with either dotnet user-secrets<\/code> to configure your app, or using a debug-time environment variable. Though it seems like we\u2019ve created yet one more configuration value to track, think about it this way: this is the only<\/strong> value you\u2019ll have to set using an environment variable; all your other configuration can be set via Azure App Configuration in the portal.<\/p>\n

\"Setting<\/p>\n

Using the Azure App Configuration Provider for .NET Core<\/h3>\n

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 IConfiguration<\/code> is simple. In Program.cs<\/code> I\u2019ll call the ConfigureAppConfiguration<\/code> middleware method, then use the AddAzureAppConfiguration<\/code> extension method to get the connection string from my ASPNETCORE_AzureAppConfigConnectionString<\/code> environment variable. If the environment variable isn\u2019t set, the call will noop and the other configuration providers will do the work.<\/p>\n

This is great<\/strong>, because I won\u2019t even need to change existing \u2013 or in this case, template-generated code \u2013 I just tell my app to use Azure App Configuration and I\u2019m off to the races. The full update to Program.cs<\/code> is shown below.<\/p>\n

\/\/ 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>(); });\n<\/code><\/pre>\n
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 appsettings.json<\/code>. 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\u2019re good.<\/p>\n
\"Running<\/p>\n
Now, I can remove the configuration values entirely from the appsettings.json<\/code> 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\u2019ll be using Azure App Configuration as, the other providers are still there.<\/p>\n
\"The<\/p>\n
Dynamic Re-loading<\/h2>\n
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 Program.cs<\/code>, I can use the Watch<\/code> method to specify which configuration settings I\u2019ll want to reload when they change.<\/p>\n
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>(); });\n<\/code><\/pre>\n
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\u2019s happening in my site, I don\u2019t need to re-deploy or even stop my site. Simply changing the values in the portal will be enough \u2013 30 seconds later the values will be re-loaded from Azure App Configuration and my logging will be more verbose.<\/p>\n
\"Changing<\/p>\n
Configuration Source Ordering<\/h3>\n
The JsonConfigurationSource<\/code> configuration sources \u2013 those which load settings from appsettings.json<\/code> and appsettings.{Environment}.json<\/code> \u2013 are loaded during the call to CreateDefaultBuilder<\/code>. So, by the time I call AddAzureAppConfiguration<\/code> to load in the AzureAppConfigurationSource<\/code>, the JSON file providers are already in the configuration sources list.<\/p>\n
The importance of ordering is evident here; should I want to override the configuration values coming from Azure App Configuration with my local appsettings.json<\/code> or appsettings.Development.json<\/code> files, I\u2019d need to re-order the providers in the call to ConfigureAppConfiguration<\/code>. Otherwise, the JSON file values will be loaded first, then the last source (the one that will \u201cwin\u201d) will be the Azure App Configuration source.<\/p>\n
Try it Out<\/h2>\n
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\u2019ll 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.<\/p>\n
\n
\"Avatar\"<\/div>\n
\n
 Brady Gaster<\/a><\/h5>\n
Senior Program Manager, ASP.NET Core<\/p>\n
Follow <\/strong>   <\/i><\/a><\/i><\/a><\/a><\/p>\n<\/p><\/div>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":95975,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[67,54,120],"class_list":["post-95974","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-microsoft-webdev","tag-aspnetcore","tag-azure","tag-blazor"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/95974","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=95974"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/95974\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/95975"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=95974"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=95974"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=95974"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}