Azure function rewriting environment problem

[petrkasnal]

Is there an existing issue for this?

• [x] I have searched the existing issues

Describe the bug

For Aspire - 9.1.0-preview.1.24561.5, I am experiencing a problem regarding poor loading of environments settings for Azure Function. I wrote about it here and was directed to create a new bug.

The problem occurred in previous versions as well. I have in AzureFunctionsTest.Functions local.settings.json with empty values and in AzureFunctionsTest.AppHost added connection strings to appsettings with filled values.

I then register the connection strings in Aspire program.cs and then add them as with refrence to the Azure Function. However, if I use debug to look at the values loaded in configuration in program.cs in Azure Function, sometimes they are all filled, sometimes they are all empty, and most often it varies.

I have prepared a repository - https://github.com/petrkasnal/AspireLocalSettingsProblem

Aspire

var messaging = builder.AddConnectionString("Messaging");
var messaging2 = builder.AddConnectionString("Messaging2");
var messaging3 = builder.AddConnectionString("Messaging3");
var messaging4 = builder.AddConnectionString("Messaging4");
var messaging5 = builder.AddConnectionString("Messaging5");
var messaging6 = builder.AddConnectionString("Messaging6");

builder.AddAzureFunctionsProject<Projects.AzureFunctionsTest_Functions>("funcapp")
    .WithReference(messaging)
    .WithReference(messaging2)
    .WithReference(messaging3)
    .WithReference(messaging4)
    .WithReference(messaging5)
    .WithReference(messaging6);

Aspire - local.settings

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "ServiceBusConnection__fullyQualifiedNamespace": ""
  },
  "ConnectionStrings": {
    "Messaging": "",
    "Messaging2": "",
    "Messaging3": "",
    "Messaging4": "",
    "Messaging5": "",
    "Messaging6": ""
  }
}

Function

var value = builder.Configuration.GetConnectionString("Messaging");
var value2 = builder.Configuration.GetConnectionString("Messaging2");
var value3 = builder.Configuration.GetConnectionString("Messaging3");
var value4 = builder.Configuration.GetConnectionString("Messaging4");
var value5 = builder.Configuration.GetConnectionString("Messaging5");
var value6 = builder.Configuration.GetConnectionString("Messaging6");

Function - appsettings.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Aspire.Hosting.Dcp": "Warning"
    }
  }, 
  "ConnectionStrings": {
    "Messaging": "test.servicebus.windows.net",
    "Messaging2": "test.servicebus.windows.net",
    "Messaging3": "test.servicebus.windows.net",
    "Messaging4": "test.servicebus.windows.net",
    "Messaging5": "test.servicebus.windows.net",
    "Messaging6": "test.servicebus.windows.net"
  }
}

Results - Its totally randoml:

Expected Behavior

I would expect the same behavior as the API, where only the values set in Aspire are loaded.

Steps To Reproduce

Open repository - https://github.com/petrkasnal/AspireLocalSettingsProblem Start Aspire application Set breakpoint to AzureFunctionsTest.Functions - Program.cs Run it a few times to see that the values go differently

Exceptions (if any)

No response

.NET Version info

9.0.0-rc.2.24473.5

Anything else?

No response

[captainsafia]

@petrkasnal Thanks for filling a separate issue for this!

So, I think the gist of what you are trying to do is wire up a pre-provisioned Azure Service Bus instance to your Azure Functions project in Aspire?

If so, there's some additional wiring up that you have to do to get it working correctly. The crux of the issue deals with the fact that the key name that the WithReference method uses by default to inject the connection string value (ConnectionStrings_{connectionName}) does not play nicely with the Azure Functions host. The Azure Functions host expects any value that lives in configuration with this key format to be a connection string, not a fully qualified namespace as shown here.

That's why in Aspire we have resources that implement the IResourceWithAzureFunctionsConfig interface to dictate what the environment variable that should be used is.

That means when you use AddConnectionString to preconfigure values, you should use WithEnvironment to inject the resource instead of WithReference (only for Azure Functions projects).

For your case, something like this should work:

builder.AddAzureFunctionsProject<Projects.AzureFunctionsTest_Functions>("funcapp")
    .WithEnvironment("Messaging__fullyQualifiedNamespace", await messaging.Resource.GetConnectionStringAsync());

[davidfowl]

You can simplify that code.

builder.AddAzureFunctionsProject<Projects.AzureFunctionsTest_Functions>("funcapp")
    .WithEnvironment("Messaging__fullyQualifiedNamespace", messaging);

It's important as that will work in both local and deployment scenarios.

[petrkasnal]

I'm sorry, I was confusing the connection string. It's not that it doesn't work for ServiceBus/Messaging. It's that it doesn't work in general. I've updated the example repository. And let's say I have a connection string to an external API/database. In short, whatever.

builder.AddAzureFunctionsProject<Projects.AzureFunctionsTest_Functions>("funcapp")
    .WithReference(messaging)
    //.WithReference(externalApi) Same problem
//    .WithReference(externalApi2) Same problem
    .WithEnvironment("ConnectionStrings__ExternalApi", externalApi)
    .WithEnvironment("ConnectionStrings__ExternalApi2", externalApi2);

However same problem when using WithEnvrionment as well as WithReference. Just be careful every time you run it, it's different. Sometimes the value is taken from Aspire appsettings and sometimes from Azure Function from localsettings.

[captainsafia]

However same problem when using WithEnvrionment as well as WithReference. Just be careful every time you run it, it's different. Sometimes the value is taken from Aspire appsettings and sometimes from Azure Function from localsettings.

Can you remove the values in the Azure Functions localsettings.json? There's a chance that there might be an ordering issue with the way the values are resolved by the host when it is run.

When using Azure Functions with Aspire, you want Aspire to be the source-of-truth for configuration as much as possible.

[petrkasnal]

Yes of course if I remove the values from the localsettings it works fine. However, for the WebApi project it is overridden and works automatically.

[captainsafia]

However, for the WebApi project it is overridden and works automatically.

I assume the for your Web API project you're using appsettings.json? localsettings is unique to the Azure Functions host and it processes the values in that differently. The recommended pattern for config with this integration is to always go through Aspire. Is t here a reason you want the values in localsettings?

[petrkasnal]

For example, if I wanted to run a function independently. I mean without Aspire.

[captainsafia]

@petrkasnal I see. I believe if you want to use identity-based connections independent of Aspire, you'll need to use the format recommended in the Azure Functions guidance here, so you'll want to do something like:

{
  "Messaging2": {
    "fullyQualifiedNamespace": "test.servicebus.windows.net",
  }
}

[petrkasnal]

@captainsafia

Well, it's not about the messaging. As I wrote, I edited the repository and put in a different connection string. For example for external api or something.

[captainsafia]

OK, after trying a couple of permutations, it seems like this behavior reproduces most consistently in Visual Studio. I don't repro this when running in the CLI or in VS Code.

Because we launch the local Functions runtime differently in each of these environments, I suspect something is awry with the way that Visual Studio maps configuration in the local settings file into the environment the Functions host is launched in.

@phenning Anything you can glean from the behavior here?