ConfigBinderMtg.md

ConfigurationBinder source generator

Phase 1: Implement core binding functionality

Similar to fast-path JSON deserialization.

Current status Feature branch:

• core infra & generation implemented
• based on David's prototype which generates to global namespace, making compiler choose source-gen'd methods over framework methods
• testing mechanism same as JSON (sharing tests with reflection-based implementation)
  • first check-in aim to generate valid C# for existing reflection-based tests (i.e. throwing NotSupportedException in some cases)

Core source generated logic to bind to user config types

• primarily POCOs and collections
• likely going to have divergence with reflection-based implementation
  • member visibility (I believe there's discussion on letting source generators bypass visibility checks; Jan)
  • first check-in won't support everything supported with reflection (dotnet/runtime#79527)
• implementation details we want to abandon
  • TypeConverter with IParseable as replacement

Side note: do we want to stop evolving reflection-based implementation?

• alternative is duplicating logic in src-gen and reflection code bases
• do we want all customers to move to generator?
• we aren't doing (probably can't do) this for JSON codebase

Phase 2.1: User gesture + generated source integration

How do users invoke the source generator and consume its output?

Default value parameter substitution

• change user code to use newly generated methods
• changed stance from .NET 6.0 + JSON source gen discussions: we don't want to change user code
  • what has changed?
• status/timeline?

Phase 2.2: e2e design/API review of the above work

Other considerations

Non-disruptive rollout to customers

• Should this be a preview feature?
• binding functionality will be incremental
• there will be divergences with reflection-based implementation

Relation to other source generators

• e.g. Options validation generator
• relative priority
• Source sharing?