The last article was dedicated to getting started on the options pattern for reading configurations in .NET applications. In this article, let’s have a look at how the configurations can be reloaded, even after the app has started. This time, we will use IOptionsMonitor interface for the demo.

Plan

• Create a sample .NET Core MVC web application for demonstrating the concept.
• A mail feature JSON object to be added in appsettings.json file, which is responsible for hypothetical mail feature in our demo application.
• Then create an options class for holding these Mail Feature related settings together.
• Then use IOptionsMonitor to access the settings.
• Once the application is up and running, change appsettings.json to see that modified configuration is available.

Does this plan sound logical ? Let’s get started then !

Boring Important Theory

Generally, when the application is applying configurations, it should set reloadOnChange parameter to true on AddJsonFile call.

This change is not required for .NET core web applications. This is because they use CreateDefaultBuilder method to create the IWebHostBuilder, which takes care of setting the reloadOnChange parameter to true.

But let’s say if you want to use custom logic for creating IWebHostBuilder, then you should remember to use appropriate overload of AddJsonFile. OR if you want to use appsettings.json file with console application, then also you will have to appropriately load the configurations.

Beware !!!

The reloadOnChange just updates the IConfiguration object.

If we use options pattern using Bind or Get, as explained in previous post, to populate the strongly typed object, then the strongly typed object would not be updated with new values.

This is because reading from IConfiguration only happens when you call Bind or Get. After this call, if the configuration changes, the strongly typed object would never know about it.

In order to make sure that configuration reload appropriately even after app has started, it is better to wrap the options object using

• IOptionsSnapshot which computes configurations for every request
• OR IOptionsMonitor which is singleton and also has one additional advantage, it can provide you notification everytime configuration is update.

Let’s Code!

As stated earlier, create a .NET Core web application (MVC) using Visual Studio or dotnet command line. Then go to appsettings.json file and add the new mail feature object

Below code shows the all the contents of modified file:

Options

Let’s create the Configurations directory in the web app and then add a class MailFeatureOptions. It should have read-write properties with same names as in our configuration section.

The code is shown in next code snippet.

Startup

Modify ConfigureServices method in Startup class and add below lines. The below lines read the configuration section and will enable dependency injection of IOptionsMonitor in any other class of this application.

The code is shown in next code snippet.

Home Controller

Inject the IOptionsMonitor<MailFeatureOptions> in the controller. Read the value from configuration in Index action and set it in ViewData. Then this value from ViewData can be shown on UI.

Run the app

Now if you run the application, you should be able to view the current settings as shown below.

Change the config

Now, our application is running, so go back to appsettings.json in Visual Studio and change something from the mail feature config section. Now, if you refresh the page, you should be able to see the updated value on UI.

Wrapping Up

So, we created the .NET web application, used IOptionsMonitor to demo how the settings are automatically reloaded, when you change appsettings, even if application has already started.

Although we used MVC application for demo, the same concept applies for any .NET application including Console applications, Web APIs, Razor Views app, etc.

I hope you found this post useful. Let me know your thoughts.