Add dot notation support for aspire config commands

[Copilot]

Summary

Enhances the aspire config set, get, and delete commands to support dot notation for creating and managing nested JSON configuration structures.

Changes

Before

aspire config set foo.bar baz
# Created: { "foo.bar": "baz" }  # Flat key with literal dots

After

aspire config set foo.bar baz
# Creates: { "foo": { "bar": "baz" } }  # Nested object structure

Key Features

• Nested object creation: aspire config set foo.bar.baz hello creates { "foo": { "bar": { "baz": "hello" } } }
• Primitive replacement: Setting foo.bar after foo exists as a string automatically converts it to an object
• Smart cleanup: Deleting nested values removes empty parent objects automatically
• Backward compatibility: Existing flat keys continue to work unchanged
• Proper retrieval: aspire config get foo.bar.baz correctly navigates nested structures
• Flattened listing: aspire config list shows nested keys with dot notation (e.g., foo.bar.baz=hello)

Implementation Details

ConfigurationService Enhancements

• SetNestedValue(): Parses dot-separated keys and creates nested JSON objects
• DeleteNestedValue(): Removes values and cleans up empty parent objects
• GetNestedValue(): Traverses nested paths for value retrieval
• FlattenJsonObject(): Recursively flattens JSON for list operations
• GetConfigurationAsync(): New method for single key lookups with dot notation support

Updated Commands

• GetCommand: Now uses ConfigurationService.GetConfigurationAsync() instead of flat IConfiguration lookup
• SetCommand: Automatically handles nested object creation and primitive replacement
• DeleteCommand: Includes smart cleanup of empty parent objects
• ListCommand: Displays all keys in flattened dot notation format

Examples

# Set nested values
aspire config set database.host localhost
aspire config set database.port 5432
aspire config set logging.level debug

# Results in:
{
  "database": {
    "host": "localhost", 
    "port": "5432"
  },
  "logging": {
    "level": "debug"
  }
}

# Retrieve nested values
aspire config get database.host    # Returns: localhost
aspire config get logging.level    # Returns: debug

# List shows flattened view
aspire config list
# Output:
# database.host=localhost
# database.port=5432
# logging.level=debug

# Delete with automatic cleanup
aspire config delete database.port
aspire config delete database.host
# The entire "database" object is removed since it becomes empty

Testing

• 81 tests pass including comprehensive new test suite
• Tests cover all scenarios: nested creation, primitive replacement, deletion cleanup, error handling
• Backward compatibility verified - all existing flat key functionality preserved
• Manual testing confirms real-world usage works as expected

Breaking Changes

None. This is a fully backward-compatible enhancement. Existing configurations and usage patterns continue to work unchanged.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[mitchdenny]

@copilot I now want you to extend the work you've done so far by implementing an IFeatureFlags interface. The IFeatureFlags interface is internal to the CLI and should look like the following:

internal interface IFeatureFlags
{
  bool IsFeatureEnabled(string featureFlag);
}

This service will read configuration keys with the form featureFlags.[featureFlag] with a default value of false. If the value is present and set to true then it is enabled. Modify the deploy command so that it is not enabled unless the deployCommandEnabled feature flag is set.

This shouldn't require changing any of the existing configuration code that you've already added so far in this PR, this would just be a new API injected into DI which uses IConfigurationService.

[Copilot]

@copilot I now want you to extend the work you've done so far by implementing an IFeatureFlags interface. The IFeatureFlags interface is internal to the CLI and should look like the following:

...

I've implemented the IFeatureFlags interface as requested. The interface provides a IsFeatureEnabled(string featureFlag) method that reads configuration keys with the pattern featureFlags.[featureFlag] and defaults to false if not set.

The deploy command is now controlled by the deployCommandEnabled feature flag and will only appear in the CLI when this flag is set to true. The implementation uses the existing IConfigurationService and doesn't require any changes to the previous dot notation configuration work.

Key features:

• IFeatureFlags interface with IsFeatureEnabled method
• Reads from featureFlags.deployCommandEnabled configuration key
• Deploy command conditionally registered in DI based on feature flag
• Comprehensive tests for all feature flag scenarios
• Backward compatible - all existing functionality preserved

(commit fadb1de)

[mitchdenny]

@copilot remove this file from the PR.

[Copilot]

Removed the .aspire/settings.json file from the PR as requested.

[mitchdenny]

@copilot use the success exit code constants here.

[Copilot]

Updated to use ExitCodeConstants.Success instead of hardcoded return 0;.

[mitchdenny]

@davidfowl this is ready to go.

@captainsafia as a heads up this PR introduces feature flagging. Currently as a proof point I've put the deploy command behind a feature flag. To enable it for local testing you will need to do this:

aspire config set --global featureFlags.deployCommandEnabled true