Fix visibility checks when generating proxies based on internal interfaces#804
Fix visibility checks when generating proxies based on internal interfaces#804AArnott merged 2 commits intomicrosoft:mainfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## main #804 +/- ##
==========================================
- Coverage 91.89% 91.81% -0.09%
==========================================
Files 61 61
Lines 5367 5375 +8
==========================================
+ Hits 4932 4935 +3
- Misses 435 440 +5
Continue to review full report at Codecov.
|
| } | ||
|
|
||
| [Fact] | ||
| public void Tomas_Internal() |
There was a problem hiding this comment.
Is it possible to update the test name to describe the scenario better?
There was a problem hiding this comment.
Isn't my name self-explanatory? ;)
| { | ||
| for (TypeInfo? t = startingPoint.GetTypeInfo(); t is not null && t != typeof(object).GetTypeInfo(); t = t.BaseType?.GetTypeInfo()) | ||
| { | ||
| yield return t; |
There was a problem hiding this comment.
Do we have to recurse into interfaces implemented by these base types or do we only care about the interfaces declared directly by the original starting point?
There was a problem hiding this comment.
You know, I copied this code from another place in the library without thinking. This code will never be hit because proxies are always based on interfaces, not classes. I'll delete.
.NET Reflection doesn't report members as part of a derived interface. One must ask each interface up the type hierarchy for its members. In #789, an internal interface was defined in the local assembly and declared no members, so we thought no skip visibility attribute was necessary. Once we add the type hierarchy traversal, the additional assembly is discovered and the skip visibility attribute added, allowing the new test to pass.
Fixes #789