[http-client-csharp] [Feature Request] Support CodeGenMember for methods

[ArcturusZhang]

Now CodeGenMember attribute only supports properties, could we make it to support methods?

Also when we use CodeGenMember attribute, we MUST rewrite EVERYTHING for that property. This is quite inconvenient - sometimes we only want to change its name. Could we introduce a new kind usage so that CodeGenMember could be added to the enclosing class, using the name of its member as the first argument? (Similar syntax like decorators in typespec) like this:

[CodeGenMember(nameof(Bar), "NewBar")]
public partial class Foo
{
}

For renaming methods, it could be something like

[CodeGenMember(nameof(GetAsync), new[] {typeof(string)}, "NewGetAsync"]
public partial class Foo
{
}

[github-actions]

🎯 Issue Triage

This is a feature request to extend the CodeGenMember attribute in the C# client emitter with two enhancements: (1) support for methods (currently only properties are supported), and (2) a lighter-weight renaming syntax applied at the class level so users don't need to rewrite the entire member just to rename it.

Category: Feature Request
Area: emitter:client:csharp

🔍 Analysis

Two distinct requests:

1. Method support for CodeGenMember: The attribute currently only handles properties. Extending it to methods would require handling method overloads, which is why the proposed syntax includes parameter types (e.g., new[] {typeof(string)}) to disambiguate.

2. Class-level rename shorthand: Instead of redeclaring a full property/method body, allow [CodeGenMember(nameof(Bar), "NewBar")] on the enclosing partial class to simply rename the generated member. This reduces the customization surface for name-only changes.

Affected components:

• packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Providers/ — ModelProvider, ClientProvider, FieldProvider, PropertyProvider
• The CodeGenMember attribute processing logic in the customization pipeline

Considerations:

• Method overload disambiguation via parameter type arrays adds complexity
• The class-level attribute syntax is a new usage pattern that needs careful design to avoid ambiguity with existing usages
• The two sub-features could be implemented independently

📝 Suggested next steps

• Evaluate the two sub-features separately — method support vs. class-level rename shorthand
• Design the class-level CodeGenMember syntax and define how it interacts with existing property-level usage
• For method renaming, define overload resolution strategy (parameter type array or signature string)
• Add unit tests covering method support and class-level rename scenarios

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

• #6100 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Agentic Triage