You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Simplify reflection of classes generated by annotations framework #1760
I'm using reflection to find the class generated by the annotation framework.
Whilst the approach is easily reproducible because the class name is "{Class}_{Method}_Generated" and the method is Method, it would be easier if the generated class was decorated with a attribute (possibly one coming from the BCL) that can be used to quickly find the generated class given the original class/function.
Additionally, it would be great if the generated class had the method with a fixed name like Handle or whatever.
Using a marking attribute and maybe even some interface with a single Handle method would make the process easier and less relying on internal implementation.
Use Case
I'm working on a tool to improve development experience when working with Annotations Lambda
What attribute do you suggest putting on the generated handler? I don't want something that users could get confused an attempt to use themselves in their code. If we can agree on attribute I don't see any reason we couldn't add the feature, would you be interested in contributing a PR?
I didn't do any research regarding the best attribute type.
I remember both EF and WCF decorating their generated code with GeneratedCodeAttribute but this attribute takes a tool name and version. I don't remember on top of my mind if you use it already, but it would be semantically incorrect anyway.
Another option would be to use something from the ComponentModel namespace but they seem to carry some special meaning for the runtime, so I'm highly skeptical about using any of these.
The only option seems to be the creation of a ad-hoc attribute and then use reflection to extract its values without having the attribute type definition available (although I'm not sure about whether a type defined in the Annotation assembly is not available down the line).
Regarding working on the pull request, I would need some guidance or at least some docs to understand the code generation process. I saw there are both cs and tt files that seem somehow related to the issue.
PS: I would assume changing the name of the generated method to a fixed value is too big of a breaking change?
We have also had some discussion of reworking the generator function name because the generated name can exceed the limit that can fit in the Function Handler property. So it would be good to have add this to move away from assuming the function's generated name.
Possibly, we haven't figured out the approach how we want to handle the issue. One approach is still generate the current format and a new format so anybody reference the current format would still work. If we do it that way then I think we would move the GenerateCodeAttribute to the new method. To be clear we would generate the current formatted version and then have it call the new format so there would be little extra code generated.
Activity
normj commentedon Jun 14, 2024
What attribute do you suggest putting on the generated handler? I don't want something that users could get confused an attempt to use themselves in their code. If we can agree on attribute I don't see any reason we couldn't add the feature, would you be interested in contributing a PR?
Kralizek commentedon Jun 15, 2024
I didn't do any research regarding the best attribute type.
I remember both EF and WCF decorating their generated code with
GeneratedCodeAttributebut this attribute takes a tool name and version. I don't remember on top of my mind if you use it already, but it would be semantically incorrect anyway.Another option would be to use something from the
ComponentModelnamespace but they seem to carry some special meaning for the runtime, so I'm highly skeptical about using any of these.The only option seems to be the creation of a ad-hoc attribute and then use reflection to extract its values without having the attribute type definition available (although I'm not sure about whether a type defined in the Annotation assembly is not available down the line).
Regarding working on the pull request, I would need some guidance or at least some docs to understand the code generation process. I saw there are both
csandttfiles that seem somehow related to the issue.PS: I would assume changing the name of the generated method to a fixed value is too big of a breaking change?
Kralizek commentedon Sep 10, 2024
@normj I got some time to look at this. Do you have the time to finalize the discussion bullets above?
normj commentedon Sep 13, 2024
I like idea of using
GeneratedCodeAttributewith a tool name of the package nameAmazon.Lambda.Annotations. There is also already logic that is accessible in thettfiles to get ahold of the version as well. https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Annotations.SourceGenerator/Templates/LambdaFunctionTemplate.tt#L84We have also had some discussion of reworking the generator function name because the generated name can exceed the limit that can fit in the Function Handler property. So it would be good to have add this to move away from assuming the function's generated name.
Kralizek commentedon Sep 13, 2024
Would you consider changing the name of the generated method a breaking change worth of a major semver hop?
normj commentedon Sep 13, 2024
Possibly, we haven't figured out the approach how we want to handle the issue. One approach is still generate the current format and a new format so anybody reference the current format would still work. If we do it that way then I think we would move the
GenerateCodeAttributeto the new method. To be clear we would generate the current formatted version and then have it call the new format so there would be little extra code generated.