For .NET Functions, please use consistent config files and access as ASP.NET Core.
This would mean removing local.settings.json and replacing it with the standard config files in ASP.NET Core, such as appsettings.json and appsettings.Developer.json.
I know you guys want to protect developers from themselves by not using local.settings.json in PROD and not checking the file in, but it would be a lot simpler if you just copied the mature and well-used patterns already established in ASP.NET.
This is something we've wanted to do for a while. We're triaging so we can discuss how this will be surfaced.
@fabiocav any status update on this?
The documentation and information around this really bad with no clear or concise guidance, one thing you read "we are dropping support for "appsettings.json" in azure functions from @lindydonna in this closed ticket 122,. And this ticket talks about adding support for it and 3189, talks about switching to it. #fail
Azure functions handling appsettings unconventionally has been a great source of headache for us recently. Whatever the original reason for it was, I think support for appsettings.json files should be added as a priority, especially since there isn't any clear documentation on how to follow this unconventional pattern and publish your local.settings.json values easily into your function app as part of your CD pipeline.
@ahmedelnably could we track documentation improvements to address what @SaebAmini mentioned above?
In the meantime, for anyone who wants ASP.NET config now, take a look at my project and NuGet package. This will let you use the patterns you are used to.
I wouldn't be too happy for that announcement @MisinformedDNA. As mentioned by fabio, hooking up your own IConfiguraion to use an appsettings file is currently trivial. The real challenge and issue to be tackled is the platform as a whole supporting file-based settings with no nasty surprises, as opposed to environment variables.
24 days ago, you wanted this to be a priority. Not you don't care?
I think support for appsettings.json files should be added as a priority
Yes, there may be lots they can do in the future, but it's a step in the right direction.
I think you're missing my point. Yes, _proper_ support should be added as a priority.
Reading a file into IConfiguraion currently takes 3 lines of code, which isn't what I was referring to by support.
I actually think adding appsettings at the surface without proper platform support would be dangerous.
I'm reading #4761 as "we are adding _proper_ support".
Most helpful comment
Azure functions handling appsettings unconventionally has been a great source of headache for us recently. Whatever the original reason for it was, I think support for appsettings.json files should be added as a priority, especially since there isn't any clear documentation on how to follow this unconventional pattern and publish your local.settings.json values easily into your function app as part of your CD pipeline.