Before you get too excited by the title of this post, it’s not good news. Yet. I’ve been looking for a decent workflow to solve this problem and am turning up blanks, which means there’s only one thing left: I’ll have to define one.
Right off the bat, there seems to be a lot of confusion at the moment around application settings in Azure Functions, mostly due to the rate of change in the Azure ecosystem. Even more so because the configuration model for Azure Functions is handled rather differently to App Service applications. I haven’t dug deep enough in to the architecture to understand why, but am guessing there’s a fairly fundamental reason for this.
For clarification:
- appsettings.json is not used for deployed functions. This was only ever used for local development and has since been renamed to local.settings.json
- web.config is not used. Refer to the folder structure for a Functions application
- host.json can not be used to store application settings
The problem I’m trying to solve here is to find a clean way of managing an Azure Functions app’s application settings over time. For an App Service application, you can simply add an entry to appsettings.json, configure any overrides for your deployment environments and off you go. With Functions there’s no such luck. On day one, you can create a neat little ARM template to handle your infrastructure setup, including app settings, but what happens when you want to add one later? I’ve seen a few different solutions which basically all come down to hacks.
As a last resort, tonight I did a final search in the Azure Functions GitHub repository tickets and found a ticket detailing the issue that I assume many people are having. Well by the looks of it we’ll have an answer tomorrow at 20:00 CEST! Here’s a direct link to the live stream.
Update: From the webcast, the bottom line is that there are plans to enhance the process, but for now keep using the CLI. Great.