When developing our .NET applications, we use to rely on web.config or appsettings.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 the Configuration 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 the Configuration section or if you mispell its key, then it is the value stored in the configuration file (web.config or appsettings.json) that will be utilized instead of the one from the Configuration 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 the appsettings.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 the Configuration 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 the Configuration 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 your appsettings.*.json files to "None" and set the "Copy to Output Directory" property of these files to "Never":
The screen capture above also illustrates what the csproj will look like after updating these properties.
Thus, if the app setting is not defined in the Configuration 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 the appsettings.*.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 the appsettings.*.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 the web.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 on Twitter or LinkedIn.
See you soon !
Top comments (2)
Consider using this: docs.microsoft.com/en-us/dotnet/ap...
This will automatically apply your appsettings to app service configuration on deployment.
Interesting. Thanks for sharing.