Umbraco 9 and Configurations

With the upgrade from umbraco 8 to umbraco 9 the way of dealing with configurations and settings changed as the .NET Framework got replaced by .NET Core.

So today I wanna share my point of view on the changes coming along with it.

In .NET Core you no longer need to write your own config handler and add the config sections in the web.config file, instead you now got different ways of setting your configurations:

• Settings files, e.g. the appsettings.json which can also have subfiles based on the different environments like appsettings.Development.json
• Environment variables
• Azure Key Vault and Azure App Configurations
• In-memory .NET objects

Seems like a lot of different ways to achieve all your needs? Most of the times yes, but sadly not always.

Those approaches can quickly reach it limits when you have a lot of settings, have generic settings or if you want the user to change some of those on the fly.

Another problem you can get is when you have settings within your nuget package - if you write your settings to a json file the developer installing the nuget will have to add some code to the start up process in order to register your settings.

You can quickly encounter all those problems when dealing with a CMS like Umbraco. As more and more developers had to deal with them it lead to a long discussion among the community on how to solve those problems.

Several approaches were discussed, e.g. saving settings that will be changed on the fly in the database.

How ever none of those approaches were really solving all or most of the problems. Thats when the idea popped up if it wouldn't be a good idea if Umbraco creates its own way to deal with settings.

Sadly, at least for me, this idea was thrown away quite fast as Umbraco is a newcomer friendly CMS which want every developer to be able to start developing very fast without having to learn to much Umbraco specific stuff.

The final outcome of the whole discussion was that we will have to use the .NET Core ways of handling configurations.

For me this was a rather unsatisfying end to the discussion. In my opinion a CMS can and should have its own ways of dealing with problems not fully solved by the underlying framework.

Having an additional way of adding configurations to the vanilla Microsoft encouraged ways would be great and help package creators a lot.

How am I dealing with this?

With all that beeing said I had to overcome most of these problems while migrating our internal packages from Umbraco 8 to 9, most of them were no problem but we have one package with about a hundred different settings - some of them even beeing generic and split up in 3 different files.

So there I was trying to solve the problem how to move them to Umbraco 9, none of the ways to handle configuration stated at the beginning were fullfilling my needs of flexibility, accessibility and extendability to the degree I needed it.

Luckily I am not only a decent Umbraco developer but also a decent Sitecore developer, and as such I know how easy it is to create your own settings there - just create a .config file within the App_Config folder and set your settings within the XML, then you access it anywhere in the code by writting "Settings.GetValue("key")".

What Sitecore does there is just getting all the .config files from the App_Config folder and creating one giant XML file in the background at application start, from these file Sitecore can read all your settings.

After thinking a while I decided that that was an approach that could also work in Umbraco and .Net Core, so thats what I went with and created a package which reads all .json files in a directory and gets all the settings within.

Accessing those settings is just as easy as in Sitecore, I just need to write "Settings.GetValue("key")".

The point I am trying to make with this blog is that a world class cms should not be limited by best practice, but by fulfilling the needs of the developers and users.

If you have any questions, feel free to contact me