Azure / Azure/azure-functions-dotnet-worker

FunctionsApplication.CreateBuilder and ConfigureFunctionsWebApplication Behavior vs. Documentation

Open
#3,010 0 comments 0 reactions 1 assignee Claimed by @RohitRanjanMS View on GitHub
Needs: Triage (Functions)
Dominant language
C#
Stars
466
Forks
215
Avg merge
3d 10h
Merged PRs (30d)
7

Description

Hello,

I am sorry for not using a template, but did not feel this aligned with a predefined category.

I am configuring a Function App created from Visual Studio template for NET 9.0 dotnet-isolated. Adding snapshot of the default packages configured with the setup:

![Image](https://github.com/user-attachments/assets/43bf9e80-2c13-43e1-a628-cc0a3adce611)

![Image](https://github.com/user-attachments/assets/a5a05d75-2232-4ad7-9d3b-898ef6671029)

I feel like I am once again re-litigating? or opening discussion and feedback on the expected behavior of the ConnectionStrings capability within local.settings.json - both in terms of expectations based on ASP NET Core implementations and an HTTP Function App utilizing the ConfigureFunctionsWebApplication.

Per the documentation:
- https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide?tabs=ihostapplicationbuilder%2Cwindows#start-up-and-configuration
- https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.host.createdefaultbuilder?view=net-9.0-pp

The direct text states that the ConfigureFunctionsWebApplication implements a default configuration that includes IHost.CreateDefaultBuilder - which in turn states behaviors related to sources of IConfiguration. Notably, in a 'Development' context the ingestion of .settings files as well as user secrets.

For the functions app template, using ConfigureFunctionsWebApplication, despite documentation guidance, this is simply not the case. There is notable special handling for the local.settings.json that is incongruent with the IHost.CreateDefaultBuilder and contrary to the documented inclusion of those behaviors. Furthermore, the delineation of local vs. development is unique to this stack setting it further apart from what appears to be the process model the FunctionsWebApplication was built around.

In terms of 'bugs' - there are (2) items that I believe need to be addressed:

1. The documentation is not accurate to tested behavior. It is clear that IHost.CreateDefaultBuilder is not implemented within the chain of ConfigureFunctionsWebApplication(). Or other options override the default behaviors; such that, the documentation is simply inaccurate.

2. ConnectionStrings in local.settings.json are not added to IConfiguration - even in the specialty Function Apps only handling case - where by things like scaffold-dbcontext do not work within this model and cannot access named configuration.

There are workaround available in customizing your IHost with the function app; however, online and otherwise this has been raised as a frequent source of confusion. I submit this issue for review to improve documentation - or possibly review the indented behavior of this method, as it does not operate as expected.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.