Parameters with multiple values

[diegomgarcia]

Is there a way to setup the parameter with multiple values like this?

appsettings.json

"Parameters": {
    "ApiSettings": {
      "BaseUrl": "https://api.myurl.com",
      "SomeOther": "value"
    },
    "SystemSettings": {
      "AdminUrl": "https://admin.myurl.com"
    }
  }

AppHost.Program.cs

  var apiSettings = builder.AddParameter("SystemSettings"); 
  var systemSettings = builder.AddParameter("SystemSettings"); 
  
  builder.AddProject<Projects.SomeProject>().WithEnvironment("ApiSettings", apiSettings).WithEnvironment("SystemSettings", systemSettings); 

I was expecting that we could use it like that, and it would automatically expand to each individual environment like:
ApiSettings_BaseUrl
ApiSettings_SomeOther
SystemSettings_AdminUrl

However, it doesn't seem to work like that.

[davidfowl]

Doesn’t work. Parameters are single values. What would you expect to happen during deployment? Would you be prompted for many values?

You should be able to build this using the a custom resource that internally uses parameters (parameter set?).

We’re currently missing a way to explicitly set the parameter value outside of configuration at runtime (cc @mitchdenny @eerhardt), but you could imagine reading the entire config section, and storing a parameter for each value under it.

Then there would be a WithReference overload that took a parameter set and set environment variables for each value in the set.

[diegomgarcia]

I think for deployment it should be expanded to environment variables as well automatically without prompting, usually when I'm deploying to k8s for instance I just deploy that way:

          env:
            - name: ApiSettings__BaseUrl
              value: "https://api.myurl.com"
            - name: ApiSettings__SomeOther
              value: "value"

And in the dotnet code of the microservice itself I use it this way:

private readonly IConfiguration _configuration; //Get from DI Container.

var baseUrl = _configuration["ApiSettings:BaseUrl"];

I will take a look on the custom resource to see how it works and how can I use it, thanks for the hint.

[diegomgarcia]

To work that way, I've written the follow extension:

public static class ResourceBuilderExtensions
{
    public static IResourceBuilder<T> WithEnvironments<T>(
        this IResourceBuilder<T> builder, 
        string rootKey) where T : IResourceWithEnvironment
    {
        // Fetch the targeted configuration section using builder's application configuration
        var targetedConfiguration = builder.ApplicationBuilder.Configuration.GetSection(rootKey);
            
        // Prepare a dictionary to hold the configuration values
        var configValues = new Dictionary<string, string>();
        LoadConfigurationSectionsAsKeyValuePairs(targetedConfiguration.GetChildren(), configValues, rootKey);

        // For each configuration setting, call WithEnvironment to set it
        foreach (var configValue in configValues)
        {
            builder = builder.WithEnvironment(context =>
            {
                context.EnvironmentVariables[configValue.Key] = configValue.Value;
            });
        }

        return builder;
    }

    private static void LoadConfigurationSectionsAsKeyValuePairs(IEnumerable<IConfigurationSection> sections, IDictionary<string, string> keyValuePairs, string prefix)
    {
        foreach (var section in sections)
        {
            var key = string.IsNullOrEmpty(prefix) ? section.Key : $"{prefix}__{section.Key}";

            // If the section has a value, it's a leaf node, add it to the dictionary
            if (section.Value != null)
                keyValuePairs[key] = section.Value;
            else
                // If the section has children, recursively process them
                LoadConfigurationSectionsAsKeyValuePairs(section.GetChildren(), keyValuePairs, key);
        }
    }
}

That way you can declare the appsettings like that:

"YourSettings": {
  "YourSubSetting": "some value"
}

Register on apphost like that

builder.AddProject<Projects.SomeProject>().WithEnvironments("YourSettings");

And use in your project as usual:

private readonly IConfiguration _configuration; //Get from DI Container.

var baseUrl = _configuration["YourSettings:YourSubSetting"];

This way we can handle multiple levels :)

[mitchdenny]

ParameterResource is much more about key configuration values that you want to change during deployment time. It is especially useful for secret values because with the secret: true flag deployment tools can handle it specially (e.g. in the Azure context - use KeyVaults to store it).

This scenario is a little bit different it feels more like a bulk settings inheritance scenario. Its not something that we have explicit support for today but your solution seems to work OK. The question is whether this is something that we should bring into .NET Aspire.

To a certain extent this overlaps with what we do in ServiceDefaults (which people sometimes forget about :P)

[diegomgarcia]

I've seem the way it was used with the secret: true in the documentation, but It wasn't clear for me that this was more specific for changing during the deployment time. It's stills not fully clear for me all the benefits of using it when not specific to secrets to be stored in the key vault or just to load it from the appsettings a single value. Can you give me some sample scenarios @mitchdenny ?

I think it should be good to have an extension like that available direct through aspire like the AddEnvironment, for me this keep the things more organized. Could I be missing something? Or overcomplicating?

[mitchdenny]

Looking at your scenario it seems like you have a micro-service that needs some settings. The example you gave was this:

{
  "ApiSettings": {
    "BaseUrl": "https://api.myurl.com",
    "SomeOther": "value"
  }
}

Is the endpoint represented by BaseUrl part of the same Aspire-based application? If so, it isn't necessary to keep track of this value. One of the benefits of Aspire is it helps you wire up endpoints. For example:

var builder = DistributedApplication.CreateBuilder(args);
var api = builder.AddProject<Projects.MyApi>("myapi");
var web = builder.AddProject<Projects.MyWeb>("myweb")
                 .WithReference(api);

In the scenario above you don't need to keep track of the BaseUrl, Aspire will do that for you when you F5 your project and at deployment time the deployment tool will take care of injecting this service discovery configuration.

If your API is external from your aspire application then it just becomes a deployment time parameter, and you would do something like this:

var builder = DistributedApplication.CreateBuilder(args);
var api = builder.AddParameter("api");
var web = builder.AddProject<Projects.MyWeb>("myweb")
                 .WithEnvironment("ApiSettings__BaseUrl", api);

That works OK for one setting, but what I'm picking up from this conversation is that you have MANY such values. You could repeat the above process adding a parameter for each one and calling WithEnvironment many times. I'm curious on a per environment basis how many settings like this you change?

[diegomgarcia]

Thanks @mitchdenny, In that case it was actually just a representation from what I want to simplify. I actually already use the service discovery same way you mention, but I have for instance several microservices that use some shared settings like JWT Settings that is shared between the Auth Service and the Api Gateway Service, also we have some other external urls that we use to call integrations an other things that we let the address on the appsettings to be easily changed if needed.

I've opted to simplify our local dev process centralizing the settings on the appsettings from AppHost itself this way we can manage this in a single place so basically what I do is to separate it something like this on the appsettings:

EmailServiceSettings: {
  ... the settings
},
AuthServiceSettings: {
  ... the settings
}
etc

[davidfowl]

As this is written at deployment time (if you deploy) the manifest will just use whatever values you have at runtime. If you want it to noop then you can check the execution context for the mode .

[diegomgarcia]

I think that in this case the extension should in fact just work as the AddEnvironment works but supporting expanding all childs to simplify the configuration process. It's a little bit cumbersome to keep it writing AddEnvironment("Key", "Value") several times for different services.

[davidfowl]

That is the case. When you deploy the values will be in the manifest. Parameters create a “slot” that can differ between environments. The developer analogy is a constant string vs a variable. You wrote a method that sets some strings, to declare a variable that can be substituted during deployment you need a parameter.

https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/external-parameters

[diegomgarcia]

Got it, thanks @davidfowl that was clear for me now.