When developing our .NET applications, we use to rely on web.config orappsettings.json files to store our application configuration settings and/or connection strings.

Once we deploy our application to Azure App Service (let's say a web app), we can "override" that configuration by adding appsettings and/or connection strings to theConfiguration section with the same keys and different values. Since this section has precedence over the configuration files, the values in this section will be utilized.

What's the problem with this approach?

Apparently, there's no problem and if you do things correctly, there will probably never be a problem.

However, if you forget to specify a given app setting in theConfiguration section or if you mispell its key, then it is the value stored in the configuration file (web.config orappsettings.json) that will be utilized instead of the one from theConfiguration section.

I want a demo!

To illustrate that situation, let's assume that we have a web application that displays the value of an app setting. Nothing fancy here but it will suffice to illustrate the point.

When running the code on the local dev box, this looks like this (as you've may expected it):

Yes, I'm using Visual Studio for Mac which I like very much.

Now, let's deploy our web application to azure. Without any surprise, the message is still read from theappsettings.json file:

Okay. Now, let's add that app setting in the Configuration section of the web app with a different value. Then, the displayed value isn't coming from the appsettings.json file anymore but rather from theConfiguration section of the web app instance:

Okay. Now comes the (not so) fun part!
If we forget to define that app setting or if we mispell it in theConfiguration section of the web app instance, the value that will be shown is the one coming from the appsettings.json file (in this example, I purposingly "forgot" the H from the name of the app setting):

How can we avoid this problem?

There might be many ways to avoid such a tricky issue. The easiest one I found is to set the "Build action" property of yourappsettings.*.json files to "None" and set the "Copy to Output Directory" property of these files to "Never":

The screen capture above also illustrates what thecsproj will look like after updating these properties.

Thus, if the app setting is not defined in theConfiguration section of the web app instance, the obtained value will be null. Your code is probably already doing such a null check. In my case, I've decided to display an error message if this situation happens:

Please note that doing so still allows you to use theappsettings.*.json files when running the application on your local dev box. They simply won't be published to Azure anymore.

It is also important to note that if theappsettings.*.json files have been previously deployed to your Azure App Service instance, a new deployment (after updating the above properties) won't remove them. You'll have to find a way to remove them. You can, for example, use "App Service Editor" to manually delete them.

In conclusion...

Today, we saw that given the fact that App Configuration in Azure App Service has precedence over theweb.config/appsettings.json, it may introduce some unwanted and unnoticed side effects. We also discussed one way to address this situation.

Let's keep in touch

You can reach me onTwitter orLinkedIn.

See you soon !