Support resolving metadata tokens in MetadataLoadContext

[reflectronic]

When using MetadataLoadContext, Module.{ResolveType,ResolveMember,ResolveMethod,ResolveField,ResolveSignature,ResolveString} all throw NotSupportedException.

This is inconvenient for advanced reflection scenarios. For example, if you are scanning IL code (perhaps retrieved using MethodBody.GetILAsByteArray), these methods are the only way to resolve MemberRefs and TypeRefs used in IL.

I do not think there is a technical reason that prevents these methods from working. If everything looks OK with this idea then I am happy to implement these.

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When using MetadataLoadContext, Module.{ResolveType,ResolveMember,ResolveMethod,ResolveField,ResolveSignature,ResolveString} all throw NotSupportedException.

This is inconvenient for advanced reflection scenarios. For example, if you are scanning IL code (perhaps retrieved using MethodBody.GetILAsByteArray), these methods are the only way to resolve MemberRefs and TypeRefs used in IL.

I do not think there is a technical reason that prevents these methods from working. If everything looks OK with this idea then I am happy to implement these.

Author:	reflectronic
Assignees:	-
Labels:	area-System.Reflection
Milestone:	-

[steveharter]

I do not think there is a technical reason that prevents these methods from working.

Thoughts @buyaa-n @jkotas @AaronRobinsonMSFT?

MLC does do internal resolution of some of those here: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.MetadataLoadContext/src/System/Reflection/TypeLoading/General/Ecma/EcmaResolver.cs

[AaronRobinsonMSFT]

I do not think there is a technical reason that prevents these methods from working.

Thoughts @buyaa-n @jkotas @AaronRobinsonMSFT?

I don't see anything wrong with this. There are going to be tricky parts, for example if EnC is involved. However, for assemblies defined with RefEmit or for statically loaded assemblies this seems like a reasonable feature.

[jkotas]

It should be very straightforward to implement these methods. @reflectronic Are you interested in submitting a PR?

[reflectronic]

EnC/S.R.E/etc. don't matter for MLC, right? It just loads assembly files from disk using S.R.M, there's no runtime magic involved. The APIs already exist and work for RuntimeModule, just not on EcmaModule.

And I can see why Ati chose not to implement them; the logic is complicated and the layering of MLC doesn't lend itself to these APIs. FieldDef/MethodDef are admittedly easy, but MemberRef is harder because the signature matching needs to be implemented over the reflection object model (taking into account modifiers and so on). Internally, there is a deliberate separation between EcmaXyz classes, which get to access the metadata reader directly, and RoXyz classes, which never expose or access raw metadata at all. This abstraction makes it hard to get the right information to the right place.

I already have some code written for this, but I'm not really happy with how it looks, so I'll see if I can refactor it and put up a PR. I don't know if I am overthinking it or if there's something we can change to make it easier.

[AaronRobinsonMSFT]

It just loads assembly files from disk using S.R.M, there's no runtime magic involved.

Files on disk can have EnC delta tables and since MLC also accepts a byte[] this could be an in-memory version. However, those are likely unnecessary to support. Without those tables/parts, as Jan stated, this should be straight forward.

[jkotas]

The existing MetadataLoadContext code deals with the token resolution internally. The fix for this issue should just wire-up the existing internal token resolution to the public APIs. I would not worry too much about following all the existing abstractions. It is ok for this fix to cut corners around the abstractions.

The fix for this issue should not be improving the internal token resolution to handle EnC data formats, etc. Improvements like this should be tracked by new issue and fixed by separate PRs.

[reflectronic]

Right, I agree that for TypeRef it is very easy because MLC has the code to resolve them. To my knowledge, it does not have the code to generally resolve MemberRefs, because that never comes up in reflection. This is the harder part.

There is this bit in custom attribute parsing:

runtime/src/libraries/System.Reflection.MetadataLoadContext/src/System/Reflection/TypeLoading/CustomAttributes/Ecma/EcmaCustomAttributeData.cs

Lines 69 to 81 in bced584

	case HandleKind.MemberReference:
	{
	TypeContext typeContext = default;
	MemberReference mr = ((MemberReferenceHandle)ctorHandle).GetMemberReference(Reader);
	MethodSignature<RoType> sig = mr.DecodeMethodSignature(_module, typeContext);
	Type[] parameterTypes = sig.ParameterTypes.ToArray();
	Type declaringType = mr.Parent.ResolveTypeDefRefOrSpec(_module, typeContext);
	const BindingFlags bf = BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.ExactBinding;
	ConstructorInfo? ci = declaringType.GetConstructor(bf, null, parameterTypes, null);
	if (ci == null)
	throw new MissingMethodException(SR.Format(SR.MissingCustomAttributeConstructor, declaringType));
	return ci;
	}

But this approach is not suitable for general signature matching. For example, it does not work for methods overloaded by return type (it's not relevant here since constructors always return void), and it doesn't handle custom modifiers (I think this is an existing bug?). Please prove me wrong if you know of suitable code elsewhere in MLC!

I agree that handling EnC tables is a separate feature. MLC ignores them entirely right now, it would be weird to handle them just for this.

[jkotas]

You are right - MemberRefs would need work.