Question: dotnet-isoltated host configuration

[ilmax]

Hello, I'm trying to use ServiceBus bindings with a managed identity connection, so I have one appsettings.{environment}.json for each environment and my connection configurations looks like:

"ServiceBus__fullyQualifiedNamespace": "{sb-namespace}.servicebus.windows.net"

In my Program.cs I add my configuration sources this way:

var host = new HostBuilder()
    .ConfigureAppConfiguration((context, config) =>
    {
        config
            .AddJsonFile("appsettings.json", optional: false, reloadOnChange: false)
            .AddJsonFile($"appsettings.{context.HostingEnvironment.EnvironmentName}.json", optional: false, reloadOnChange: false)
            .AddEnvironmentVariables();
    })
// Rest of code omitted

and the function can be as simple as:

    public class Function1
    {
        [Function("Function1")]
        public void Run([ServiceBusTrigger(QueueName, Connection = "ServiceBus")] string message)
        {
        }
    }

But running the application result in the following error:

The listener for function 'Functions.Function1' was unable to start. [2023-07-27T14:10:20.649Z] The listener for function 'Functions.Function1' was unable to start. Microsoft.Azure.WebJobs.Extensions.ServiceBus: Service Bus account connection string 'ServiceBus' does not exist. Make sure that it is a defined App Setting.

To my understanding, and going through this issue, it looks like the configuration is just added to the process running my function and not to the host, while it's the host that needs to connect to e.g. the ASB in this case.

So I wanted to ask: What are the default configuration sources for the dotnet-isolated process host? Is it configured anywhere? Do we have any hook to add additional configuration sources?

Is there any way I can make my scenario working? I'm about to migrate several webjobs to azure function and since the in-process model will not be supported in the future according to this blog post, I'd like to migrate to the isolated model but I'm stuck here.

P.S. I know I can add the configuration to the local.settings.json and this will work, but it doesn't support the .{environment}.json that's quite handy to connect to another environment and it only works locally since by default the file is not included in the published artifacts.

[shieldsjared]

Also running into this exact same issue and have been fumbling to find a solution that promotes a good workflow. We also dont use local.settings.json because its not manageable in situation with multiple projects where appsettings.json is the preference.

[jviau]

@ilmax you need to configure your service bus connection strings in host.json.

In dotnet isolated, we run in a two process model. The functions host and the worker. The worker is what you are building. The functions host is a part of the functions tool chain. appsettings.json and its per-environment variations are only loaded for the worker process, not for the host. Any config you set there will not apply to the host.

Also, configuration property naming depends on where you are setting it. When set via an environment variable, you use double underscore to separate sections, hence ServiceBus__fullyQualifiedNamespace. When setting the same in host.json or appsettings.json, you use either : or JSON structure to delineate sections. So it would be either:

{
  "ServiceBus:fullyQualifiedNamespace": "<value>"
}

OR

{
  "ServiceBus": {
    "fullyQualifiedNamespace": "<value>"
  }
}

note that this does NOT apply to local.settings.json. This follows environment naming rules, because it is specially bootstrapped as environment variables as part of the func tool chain. (I may be wrong here, try both ways if you are using local.settings.json and see which one works).

[ilmax]

@jviau thanks for the response, but I still think this is an area that can and should be improved. I think it would be nice to support the same model that asp.net core support i.e. reading it from the appsettings.json and appsettings.{env}.JSON

This will make it easier to migrate to the out of process model and use a widely known pattern

[jviau]

@ilmax these two things are not equivalent. AspNetCore is a single-process model, Functions is two processes. Functions needs a way to declare configuration separately for host and worker. We do not want other configuration from appsettings.json adversely impacting the host process. This is not to say this behavior will never change, but we do not have plans to change it at this time.

Let me know if setting the configuration in host.json or as an environment variable addresses your issue.

[ilmax]

@jviau I'm well aware of how the out of process model works and I can workaround this issue but the UX for triggers or bindings usability in the new out of process model is unfortunate to say at least.

A couple of issues I see are:

1. It's not immediately obvious why it's not picking up the connection string configured in the worker configuration, the exception message has to better at indicating what went wrong and how to fix it
2. host.json is not a common place where we put application configuration so it will not be used for that moreover if you need the connection in your worker code you also need to duplicate it
3. host.json doesn't support a configuration per environment approach
4. environment variables means you have to put the configuration elsewhere (e.g. IaC) and makes it difficult to debug locally and connect to a different environment by changing the AZURE_FUNCTIONS_ENVIRONMENT in the launchSettings.json

Last point is especially important for me, since it quickly allows developers to locally debug in different environments with a single change. This requires all the configuration/connections to be available in the source code and makes the environment variable approach impractical.

As you can see there're some disadvantages of the out of process model, some can be alleviated easily (better error message) some not.
I would like to configure the connections in the configuration like I was doing in the In-Process model so azure function could do something like:

• Allow me to configure the host configuration before trying to resolve connections or
• Delegate resolving the connection to the worker

[jviau]

Thank you for the feedback. We will take it into consideration when/if we re-evaluate the configuration model for dotnet-isolated. This is not something we have planned for the immediate term, but we may circle back to it eventually.

I am going to consider your original question answered and close this.

[dfaivre]

@jviau - for whatever it's worth, our team also would like a more streamlined app config loading experience at the host level in the new isolated C# model: MicrosoftDocs/azure-docs#95950 (comment)