Implement type-safe feature flag system for Aspire CLI

[Copilot]

Description

Replaces string-based feature flag lookups with strongly-typed classes. Previously, each callsite specified both the feature name as a string and its default value, creating potential for inconsistency and typos.

Changes

• New type system: IFeatureFlag interface defines ConfigurationKey and DefaultValue properties
• Feature flag classes: 10 concrete implementations (e.g., UpdateNotificationsEnabledFeature, ExecCommandEnabledFeature)
• Type-safe API: Added Enabled<TFeatureFlag>() generic method to IFeatures
• Performance: Static cache for feature flag instances to avoid allocations
• Bug fix: Invalid configuration values now correctly fall back to default (previously returned false)

Before:

if (features.IsFeatureEnabled(KnownFeatures.UpdateNotificationsEnabled, defaultValue: true))

After:

if (features.Enabled<UpdateNotificationsEnabledFeature>())

Updated 14 callsites across DotNetSdkInstaller, DotNetCliRunner, RunCommand, UpdateCommand, PackagingService, and other components.

Legacy IsFeatureEnabled(string, bool) method retained for backward compatibility.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
  • No
• Does the change require an update in our Aspire docs?
  • Yes
  • No

Original prompt

The Aspire CLI has an IFeatures interface that works in conjunction with the configuration system to enable developers to build features that are defaulted to on or off to allow for gradual delivery of functionality.

There are two problems with the current system. The first problem is the system relies on string keys and even though we have a KnownFeatureFlags class for capturing these its still fairly loosely typed. THe other issue is that each callsite needs to define what its interpretation of the default should be.

instead of doing this implement a new IFeatureFlag type and create an implementation of IFeatureFlag for each of our known feature flags. The interface should container the configurationkey name and also the defaultstate.

Then in the callsites where we check whether a feature flag is enabled we should call: featuers.Enabled<TypeOfFeature>(). this would return a boolean with the defaulting logic implemented internally to the IFeatures implementation which factors in the default value and the configured value.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.