System.Reflection.MetadataLoadContext doesn't support function pointer types #43791
Description
To reproduce: run the attached project
Version: master
Expected result: works
Actual result:
Unhandled exception. System.NotSupportedException: Parsing function pointer types in signatures is not supported.
at System.Reflection.TypeLoading.Ecma.EcmaModule.GetFunctionPointerType(MethodSignature`1 signature)
at System.Reflection.Metadata.Ecma335.SignatureDecoder`2.DecodeType(BlobReader& blobReader, Boolean allowTypeSpecifications, Int32 typeCode)
at System.Reflection.Metadata.Ecma335.SignatureDecoder`2.DecodeMethodSignature(BlobReader& blobReader)
at System.Reflection.TypeLoading.Ecma.EcmaMethodDecoder.SpecializeMethodSig(IRoMethodBase roMethodBase)
at System.Reflection.TypeLoading.RoDefinitionMethod`1.ComputeMethodSig()
at System.Reflection.TypeLoading.RoMethod.get_MethodSig()
at System.Reflection.TypeLoading.RoMethod.get_ReturnParameter()
at System.Reflection.TypeLoading.RoMethod.get_ReturnType()
Activity
vargaz commentedon Oct 24, 2020
test.tar.gz
marek-safar commentedon Oct 24, 2020
Hmm how is Roslyn reading such metadata?
@jaredpar @MichalStrehovsky
MichalStrehovsky commentedon Oct 24, 2020
This looks like a bug in System.Reflection.MetadataLoadContext. It's a library built on top of System.Reflection.Metadata that provides additional abstractions over the metadata. Roslyn only uses S.R.Metadata, not this extra layer with the missing implementation.
steveharter commentedon Nov 12, 2020
It is apparently by design since it throws an explicit
NotSupportedExceptionwhen detecting a function pointer.This overlaps with #11354 where we don't return function pointer type from standard reflection either and need a way to represent that.
Doing a
typeof(delegate*<void>)(for example) returnsSystem.IntPtras the type, so it would be expected that MLC returnIntPtras the type. However, that doesn't allow inspection of the parameters or return type, and there is not an existing "function pointer" type in .NET that we can readily use instead.steveharter commentedon Nov 12, 2020
@vargaz @CoffeeFlux can you add more detail including the workaround you use, and the "blocking" label if you consider it blocking. Thanks
16 remaining items
lambdageek commentedon Jun 22, 2022
@steveharter Will the #69273 MetadataLoadContext work also happen in 7? Will that include also the .NET Framework version of MLC? If so, that will help us with this issue with the wasm tooling.
steveharter commentedon Jul 6, 2022
@lambdageek yes MetadataLoadContext will be updated along with the CoreClr runtime. The active PR is #71516.
It should be possible to use .NET framework with MetadataLoadContext function pointers although reflection will necessary to call the new APIs on Type. I'll provide an example once that PR is in.
jkotas commentedon Jul 11, 2022
We may want to provide extension methods so that it is not necessary to use reflection.
steveharter commentedon Jul 13, 2022
Moving to 8.0; we need to update the API and design based on feedback from #71516.