How to ImportReference on this generic type?

[ericsink]

My question is about the proper usage of ImportReference of a System.Type.

The particular System.Type here is the return type of this delegate from ASP.NET:

https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.components.web.virtualization.itemsproviderdelegate-1?view=aspnetcore-5.0

which is:

System.Threading.Tasks.ValueTask`1[Microsoft.AspNetCore.Components.Web.Virtualization.ItemsProviderResult`1[TItem]]

Suppose I have:

var m = the MethodInfo for the Invoke method of the delegate
var md = my ModuleDefinition

Now, if I do this:

var t = md.ImportReference(m.ReturnType);

Then I get this error.

System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at Mono.Cecil.ImportGenericContext.TypeParameter(String type, Int32 position)
   at Mono.Cecil.DefaultReflectionImporter.ImportGenericParameter(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportTypeSpecification(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportType(Type type, ImportGenericContext context, ImportGenericKind import_kind)
   at Mono.Cecil.DefaultReflectionImporter.ImportGenericInstance(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportTypeSpecification(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportType(Type type, ImportGenericContext context, ImportGenericKind import_kind)
   at Mono.Cecil.DefaultReflectionImporter.ImportGenericInstance(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportTypeSpecification(Type type, ImportGenericContext context)
   at Mono.Cecil.DefaultReflectionImporter.ImportType(Type type, ImportGenericContext context, ImportGenericKind import_kind)
   at Mono.Cecil.DefaultReflectionImporter.ImportReference(Type type, IGenericParameterProvider context)

Which seems to indicate that the problem here is the generic type argument, which is not surprising.

If I instead import the generic type definition, like this:

var t = md.ImportReference(m.ReturnType.GetGenericTypeDefinition());

Then I get no error, but I haven't really imported the same type.

I assume what I probably need to do is import the type definition, and then import the type arguments, and then put them back. Can you confirm that?

I'm pretty sure I can figure out how to do this, but I'm also curious if DefaultReflectionImporter should be able to do it. I'm looking at the IGenericParameterProvider argument for ImportReference(). Perhaps I am supposed to be providing one of these? If so, where would I get it?

Thanks!

[jbevain]

Hey Eric,

Because Cecil tries to maintain the identity of GenericParameters, I think it's trying to find where the GenericParameter TItem is defined. I think you need to use the overload of ImportReference that takes a generic context.

So you would do something like this?

var d = ImportReference(declaring_type);
var rt = ImportReference(returnType, d);

[ericsink]

Yeah I do briefly mention the probable need to use that overload, toward the end of my question.

Your reply does provide a clue or two. Apparently the IGenericParameterProvider comes from another call to ImportReference(), and apparently it should be the declaring type.

But in this case, I assume it needs to be the type that declares TItem. And that type is one nesting level down.

The top-level type for the return type is ValueTask<T>, and its type argument is ItemsProviderResult<TItem>. So if I am calling ImportReference on the top-level type, how would I provide the IGenericParameterProvider for the type that declares TItem, which is not at the same level?

I'm guessing perhaps DefaultReflectionImporter cannot handle this case, involving nesting of type arguments more than one level deep?

[ericsink]

Another tidbit:

If I instead import the method and then get the return type, no error:

var mi = md.ImportReference(m)
var tr = mi.ReturnType

I suppose this could even be a workaround, although it's unfortunate to import a method I don't need, and I'm mostly trying to understand how these ImportReference() methods are supposed to be used.

But I find it interesting that it seems to work. This suggests that under the hood, importing the method is providing more of the "context" that is necessary to sort out generic type arguments.

[jbevain]

Hey Eric,

Sorry if I skimmed through the question too fast before answering. I think none of what I'm writing here solves the question but hopefully should provide a bit of a context.

At the end of the day, ImportReference takes a metadata element (type, field, method) from another module, and create a reference to this metadata element for the module you're calling ImportReference on.

There are 2 series of ImportReference methods:

• one taking runtime reflection types (System.Type, System.Reflection.MethodInfo).
• one taking Cecil types.

The reflection based one is convenient but has a severe drawback: it creates references to the currently running runtime. Meaning if you're modifying an assembly for another runtime you'll get into troubles.

The Cecil based one is one I encourage people using because it gives you more control.

As I was writing above, Cecil tries to maintain generic parameter identity. Meaning that if you have an open generic instantiation, the GenericParameter you'll find in the .GenericArguments of the GenericInstance will be in the .ElementType.GenericParameters of the GenericInstance. In hindsight I'd not write it like this again.

To answer one of your concern, calling ImportReference doesn't create the metadata directly for the reference, it will be created on the fly when you save the module.

It's also possible that Cecil is doing weird stuff that would not be expected, I'd have to try and debug it.

I assume what I probably need to do is import the type definition, and then import the type arguments, and then put them back. Can you confirm that?

My initial thought is that I think Cecil should be able to create a reference given the right context. Now if Cecil's default importer doesn't work for you, at least you can always roll-out your own.

[ericsink]

No worries. Thanks for the additional info. It's all helpful.

The reflection based one is convenient but has a severe drawback: it creates references to the currently running runtime.

In my case, I am using reflection-based import, but I only use it on things I obtained from an assembly loaded with System.Reflection.MetadataLoadContext, which does end up giving me references to the desired assembly instead of the currently running runtime.

Now if Cecil's default importer doesn't work for you, at least you can always roll-out your own.

I've taken a few steps down that path with my own subclass of DefaultReflectionImporter, but I'm still climbing the learning curve. :-)

I'll continue digging, and I may post more discoveries here if I find some.

Thanks again.