What is the correct way to import a framework type that is forwarded?

[Zastai]

I was trying to add a reference to List<T> for use in a method.

ModuleDefinition md;
...
var listType = md.ImportDotNetType(typeof(List<>));

with

    [NotNull]
    public static TypeReference ImportDotNetType([NotNull] this ModuleDefinition md, [NotNull] Type t) {
      var ns = t.Namespace;
      var name = t.Name;
      return md.ImportReference(new TypeReference(ns, name, md, md.TypeSystem.CoreLibrary, t.IsValueType));
    }

This works perfectly fine for net472 assemblies. In a netstandard2.1 assembly, the code looks fine in ILSpy (with [netstandard]System.Collections.Generic.List`1 being shown in IL).

However, at runtime, this results in Could not load type 'System.Collections.Generic.List`1' from assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

So it looks like my import is not resolving correctly; netstandard forwards the type to System.Collections but the code is apparently expecting to find it in System.Runtime instead.

What am I missing in order for this to resolve correctly?

I have now worked around it by subclassing List<T> in my own library, so I avoid the issue (and the generics), but I'd still like to know how to make this work in the "normal" way.

[ltrzesniewski]

That's strange. netstandard should forward List<T> to System.Collections, which should forward it to System.Private.CoreLib. System.Runtime shouldn't be involved at all.

TypeSystem.CoreLibrary is System.Runtime for .NET Core assemblies though, so Cecil could have detected your assembly as a .NET Core assembly, but that conflicts with ILSpy showing you reference netstandard.

I suggest you provide a minimal repro demonstrating the issue.

[Zastai]

Hmm - tried to make a minimal case, with 4 projects:

1. an empty classlib,
2. a classlib with a simple Foo.Bar class containing a Xyzzy method returning a List<string>,
3. a processor that uses Mono.Cecil to create such a Foo.Bar class (to be run on the empty classlib), and
4. a loader that loads the result and uses reflection to invoke the Xyzzy method.

But that just works. So I'd have to dig into the specifics of what I was doing to see where I deviated from this simple case. I doubt I'll have time to devote to that anytime soon, especially with a viable workaround available.