Allow for hierarchical configuration in Aspire Components

[eerhardt]

When using "named" or "keyed DI" components, the settings/configuration should be configured hierarchically, so common settings can be set at Aspire:Abc and each named section can provide settings specific to it. The named settings override the common settings.

For example:

{
  "Aspire": {
    "Abc": {
      "MySetting": true,

      "named_one": {
        // inherits MySetting=true
      },
      "named_two": {
        "MySetting": false
      }
    }
  }
}

Similarly for Azure, the ClientOptions can be configured hierarchically as well, so common Azure options can be configured for all Azure components. And each component can override the shared settings.

{
  "Aspire": {
    "Azure": {
      // These ClientOptions apply to all Azure components
      "ClientOptions": {
        "RetryOptions": {
          "MaxRetries": 2,
          "Delay": "00:00:01"
        }
      },

      "Messaging:ServiceBus": {
        "Namespace": "aspire-servicebus.servicebus.windows.net",

        // These ClientOptions apply to the ServiceBus component and override the above options
        "ClientOptions": {
          "RetryOptions": {
            "MaxRetries": 3
          }
        }
      }
    }
  }
}

Note that the Azure SDK is planning on adding some IConfiguration integration. We should ensure the Aspire configuration story lines up well with the work they are doing.

When this is implemented, please update the https://github.com/dotnet/aspire/blob/main/src/Components/README.md with the information so all component authors add support.

cc @tg-msft @schaabs

[pedershk]

Is Keyed DI (i.,e. multiple named instances) now supported in .NET Aspire Components? I noticed components are added as Singletons to DI when using the component. Are they stored with the name, making multiple additions of same service type possible in a single AppDomain?

[davidfowl]

Yes it's supported. Aspire components have AddKeyed* overloads that support providing a name.