Developers can use Reflection APIs to easily access attribute-based metadata concepts

[steveharter]

With various attributes being address to members and types, that information is cumbersome to access with reflection. These new APIs wrap access to that metadata and are intended to work both with runtime reflection and with MetadataLoadContext reflection.

Currently includes

• Expose top-level nullability information from reflection

Was prototyped, but not that much interest:

• Reflection support for Tuple and ValueTuple

[jkotas]

Do we also need more efficient low-level APIs to query custom attributes as part of this, to allow implementing these higher-level APIs efficiently on newer runtimes?

One has to enumerate all attributes and get a full name of each attribute today as you prototypes show: master...steveharter:ReflectionExt#diff-e4a922bf7ad13b0f5c1868bc798113844f672f9658fc0ac1b9c901e5893b6d61R25 . It looks pretty inefficient.

[steveharter]

On the performance, yes that was called out as will be poor.

I don't expect these methods to be called more than once for a given member, so perhaps it is OK. If they are called more than once, then currently higher-level caching would need to be used.

I believe the APIs would be called mostly by tooling and analyzers and not necessarily at run-time. If we need fast runtime support, some thoughts on caching:

• Add a static hashtable for each type of extension method (would still be slow)
• Add state to runtime types (would be more complicated, plus for each runtime and MetadataLoadContext)
• Add state to TypeInfo (may still require a hashtable for per-member state)
• Add "run-time attributes" that have the cached information (would be a new mechanism)
• ...?

[jkotas]

I don't expect these methods to be called more than once for a given member, so perhaps it is OK

Having an expensive APIs that are called just once for given member tends to be still a problem. Note that the real performance challenge for .NET runtime is startup, not steady state performance. Startup is where .NET is often much worse compared to alternatives.

I believe the APIs would be called mostly by tooling and analyzers and not necessarily at run-time. I

I do not think that these APIs are usable by analyzers. Analyzers do not use Reflection object model.

Are there concrete tools you have in mind outside analyzers for this?

[steveharter]

Are there concrete tools you have in mind outside analyzers for this?

In the original issue @terrajobst points out EF and MVC as known scenarios.

The EF scenarios would use the nullability APIs to do things like generate a model from code which is generally not performant-critical since these are developer\design-time scenarios, not runtime\production scenarios.

The MVC scenarios may use for design-time scenarios too, but @terrajobst also mentions "model binding" scenarios which may imply runtime behavior and thus need high performance. However, perhaps that could be handled by generated code, which is influenced at code-gen time by the nullability information, so it may just be non-runtime\production scenarios as well.

@terrajobst is my assumption correct -- that the known users of these APIs do not need to be performant since they are not run in production? If not, and the APIs are called from run-time production code, then yes we'll need some sort of caching or a better (new) way to represent that metadata to make it fast.

[danmoseley]

@steveharter what should tihs be parented by - #44655 ?

[steveharter]

@danmosemsft this issue could be combined with #44655; I originally planned on having 3 "team epic" issues including this one, #44655 and #44327. I wasn't sure on pros\cons of having separate vs together other than costing.

[danmoseley]

I think if a subset are cuttable together, and have much the same priority, it can make sense to keep them together in a separate issue. The purpose of the tree is to see what depends on what, see related work together, and cost and prioritize it in groups. Whatever we end up with, it's helpful to parent things somewhere.