- 
                Notifications
    You must be signed in to change notification settings 
- Fork 5.2k
          [mono] Fix GetCustomAttributes System.Reflection API with a custom attribute provider
          #94602
        
          New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
  
    [mono] Fix GetCustomAttributes System.Reflection API with a custom attribute provider
  
  #94602
              Conversation
| Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsDescriptionThis PR fixes issues when using  The problem comes from the fact that entry points of the  runtime/src/mono/System.Private.CoreLib/src/System/Reflection/CustomAttribute.cs Lines 159 to 165 in 952ac21 
 causing ArgumentNullExceptionChangesThis has been fixed by lifting up the check for the user-defined custom attribute provider and the call to the adequate overrides. It seems that such usage is not covered with our unit tests, however it is used in ASP.NET test suite (reported here: #93770 and here: #94437 (comment)) To verify the fix and to increase our test coverage I have added a unit test in this PR inspired by: https://github.com/dotnet/aspnetcore/blob/402e7fc10aa304775f50d318c8a4dafbf46dbfe0/src/Shared/PropertyAsParameterInfo.cs#L15 NOTE: It is possible I did not place the unit test in the right location. Fixes: #94488 
 | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am passing in typeof(Attribute) here to match CoreCLR implementation: 
runtime/src/coreclr/System.Private.CoreLib/src/System/Attribute.CoreCLR.cs
Lines 555 to 567 in c07cb44
| public static Attribute[] GetCustomAttributes(ParameterInfo element, bool inherit) | |
| { | |
| ArgumentNullException.ThrowIfNull(element); | |
| if (element.Member == null) | |
| throw new ArgumentException(SR.Argument_InvalidParameterInfo, nameof(element)); | |
| MemberInfo member = element.Member; | |
| if (member.MemberType == MemberTypes.Method && inherit) | |
| return InternalParamGetCustomAttributes(element, null, inherit); | |
| return (Attribute[])element.GetCustomAttributes(typeof(Attribute), inherit); | |
| } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice for net9 to unify more of Mono and CoreCLR's custom attribute logic because the Mono code feels very messy right now
| 
 I agree. Opened: #94659 for tracking. | 
| /azp run runtime-extra-platforms | 
| Azure Pipelines successfully started running 1 pipeline(s). | 
ad04942    to
    fe178fa      
    Compare
  
    | Failures are not related. | 
| /backport to release/6.0-staging | 
| Started backporting to release/6.0-staging: https://github.com/dotnet/runtime/actions/runs/6865787900 | 
| /backport to release/7.0-staging | 
| Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/6865796221 | 
| /backport to release/8.0-staging | 
| Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/6865801202 | 
| It will be good to have this back ported at least for .NET 8 | 
Description
This PR fixes issues when using
GetCustomAttributesAPI with a custom attribute provider with Mono.The problem comes from the fact that entry points of the
GetCustomAttributesAPI in the Mono implementation, do not check early if the custom attribute provider is derived from the base type, but rather call back to the custom override after some problematic "workarounds" are done like:runtime/src/mono/System.Private.CoreLib/src/System/Reflection/CustomAttribute.cs
Lines 159 to 165 in 952ac21
causing
ArgumentNullExceptionChanges
This has been fixed by lifting up the check for the user-defined custom attribute provider and the call to the adequate overrides.
It seems that such usage is not covered with our unit tests, however it is used in ASP.NET test suite (reported here: #93770 and here: #94437 (comment))
To verify the fix and to increase our test coverage I have added a unit test in this PR inspired by: https://github.com/dotnet/aspnetcore/blob/402e7fc10aa304775f50d318c8a4dafbf46dbfe0/src/Shared/PropertyAsParameterInfo.cs#L15
NOTE: It is possible I did not place the unit test in the right location.
Fixes: #94488