Interop Type Mapping

[AaronRobinsonMSFT]

Interop Type Mapping

Work items:

• API proposal - [API Proposal]: Type Mapping API #113362
• TypeMap implementation
  • CoreCLR - TypeMap API (Dynamic implementation) #113954
  • native AOT Implement Interop Type Map support in NativeAOT #116355
  • Tests - TypeMap API (Dynamic implementation) #113954
• Trimmer support - Implement trimming support for the Interop Type Map #116555
  • Respect attributes for type map generation - Implement trimming support for the Interop Type Map #116555
• AOT support Implement Interop Type Map support in NativeAOT #116355
  • Generate type map Implement Interop Type Map support in NativeAOT #116355

Background

When interop between languages/platforms involves the projection of types, some kind of type mapping logic must often exist. This mapping mechanism is used to determine what .NET type should be used to project a type from language X and vice versa.

The most common mechanism for this is the generation of a large look-up table at build time, which is then injected into the application or Assembly. If injected into the Assembly, there is typically some registration mechanism for the mapping data. Additional modifications and optimizations can be applied based on the user experience or scenarios constraints (that is, build time, execution environment limitations, etc).

At present, there are at least three (3) bespoke mechanisms for this in the .NET ecosystem:

• C#/WinRT - Built-in mappings, Generation of vtables for AOT.

• .NET For Android - Assembly Store doc, Assembly Store generator, unmanaged Assembly Store types.

• Objective-C - Registrar, Managed Static Registrar.

Related issue(s):

• Expand ILLink/ILC support for 'eliminate dead branches around typeof comparisons' to work on internal types too #110300

Proposal

The .NET ecosystem should provide an official API and process for handling type mapping in interop scenarios.

Priorties

1. Trimmer friendly - AOT compatible.
2. Usable from both managed and unmanaged environments.
3. Low impact to application start-up and/or Assembly load.
4. Be composable - handle multiple type mappings.

The below .NET APIs represents only part of the feature. The complete scenario would involve additional steps and tooling.

Provided by BCL (that is, NetCoreApp)

namespace System.Runtime.InteropServices;

/// <summary>
/// Base interface for target type universe.
/// </summary>
/// <remarks>
/// This interface should be inherited directly by a concrete type
/// universe class. APIs consuming <see cref="ITypeMapUniverse"/> as
/// generic parameters don't respect class inheritance.
/// </remarks>
public interface ITypeMapUniverse { }

/// <summary>
/// Type mapping between a string and a type.
/// </summary>
/// <typeparam name="TTypeUniverse">Type universe</typeparam>
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
public sealed class TypeMapAttribute<TTypeUniverse> : Attribute
    where TTypeUniverse : ITypeMapUniverse
{
    /// <summary>
    /// Create a mapping between a value and a <see cref="System.Type"/>.
    /// </summary>
    /// <param name="value">String representation of key</param>
    /// <param name="target">Type value</param>
    /// <remarks>
    /// This mapping is unconditionally inserted into the type map.
    /// </remarks>
    public TypeMapAttribute(string value, Type target)
    { }

    /// <summary>
    /// Create a mapping between a value and a <see cref="System.Type"/>.
    /// </summary>
    /// <param name="value">String representation of key</param>
    /// <param name="target">Type value</param>
    /// <param name="trimTarget">Type used by Trimmer to determine type map inclusion.</param>
    /// <remarks>
    /// This mapping is only included in the type map if the Trimmer observes a type check
    /// using the <see cref="System.Type"/> represented by <paramref name="trimTarget"/>.
    /// </remarks>
    [RequiresUnreferencedCode("Interop types may be removed by trimming")]
    public TypeMapAttribute(string value, Type target, Type trimTarget)
    { }
}

/// <summary>
/// Declare an assembly that should be inspected during type map building.
/// </summary>
/// <typeparam name="TTypeUniverse">Type universe</typeparam>
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = true)]
public sealed class TypeMapAssemblyTargetAttribute<TTypeUniverse> : Attribute
    where TTypeUniverse : ITypeMapUniverse
{
    /// <summary>
    /// Provide the assembly to look for type mapping attributes.
    /// </summary>
    /// <param name="assemblyName">Assembly to reference</param>
    public TypeMapAssemblyTargetAttribute(string assemblyName)
    { }
}

/// <summary>
/// Create a type association between a type and its proxy.
/// </summary>
/// <typeparam name="TTypeUniverse">Type universe</typeparam>
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = false)]
public sealed class TypeMapAssociationAttribute<TTypeUniverse> : Attribute
    where TTypeUniverse : ITypeMapUniverse
{
    /// <summary>
    /// Create an association between two types in the type map.
    /// </summary>
    /// <param name="source">Target type.</param>
    /// <param name="proxy">Type to associated with <paramref name="source"/>.</param>
    /// <remarks>
    /// This mapping will only exist in the type map if the Trimmer observes
    /// an allocation using the <see cref="System.Type"/> represented by <paramref name="source"/>.
    /// </remarks>
    public TypeMapAssociationAttribute(Type source, Type proxy)
    { }
}

/// <summary>
/// Entry type for interop type mapping logic.
/// </summary>
public static class TypeMapping
{
    /// <summary>
    /// Returns the External type type map generated for the current application.
    /// </summary>
    /// <typeparam name="TTypeUniverse">Type universe</typeparam>
    /// <param name="map">Requested type map</param>
    /// <returns>True if the map is returned, otherwise false.</returns>
    /// <remarks>
    /// Call sites are treated as an intrinsic by the Trimmer and implemented inline.
    /// </remarks>
    [RequiresUnreferencedCode("Interop types may be removed by trimming")]
    public static bool TryGetExternalTypeMapping<TTypeUniverse>([NotNullWhen(returnValue: true)] out IReadOnlyDictionary<string, Type>? map)
        where TTypeUniverse : ITypeMapUniverse;

    /// <summary>
    /// Returns the associated type type map generated for the current application.
    /// </summary>
    /// <typeparam name="TTypeUniverse">Type universe</typeparam>
    /// <param name="map">Requested type map</param>
    /// <returns>True if the map is returned, otherwise false.</returns>
    /// <remarks>
    /// Call sites are treated as an intrinsic by the Trimmer and implemented inline.
    /// </remarks>
    [RequiresUnreferencedCode("Interop types may be removed by trimming")]
    public static bool TryGetTypeProxyMapping<TTypeUniverse>([NotNullWhen(returnValue: true)] out IReadOnlyDictionary<Type, Type>? map)
        where TTypeUniverse : ITypeMapUniverse;
}

Given the above types the following would take place.

1. Types involved in unmanaged-to-managed interop operations would be referenced in a
   TypeMapAttribute assembly attribute that declared the external type system name, a target
   type, and optionally a "trim-target" type use by the Trimmer to determine if the target
   type should be included in the map. If the trim-target type is used in a type check, then
   the entry will be inserted into the map. If the TypeMapAttribute constructor that doesn't
   take a trim-target is used, the entry will be inserted unconditionally.

The target type would have interop specific "capabilities" (for example, create an instance).

2. Types used in a managed-to-unmanaged interop operation would use TypeMapAssociationAttribute
   to define a conditional link between the source and proxy type. In other words, if the
   source is kept, so is the proxy type. If Trimmer observes an explicit allocation of the source
   type, the entry will be inserted into the map.

3. During application build, source would be generated and injected into the application
   that defines appropriate TypeMapAssemblyTargetAttribute instances. This attribute would help the
   Trimmer know other assemblies to examine for TypeMapAttribute and TypeMapAssociationAttribute
   instances. These linked assemblies could also be used in the non-Trimmed scenario whereby we
   avoid creating the map at build-time and create a dynamic map at run-time instead.

4. The Trimmer will build two maps based on the above attributes from the application reference
   closure.

   (a) Using TypeMapAttribute a map from string to target Type. If a trim-target Type
   was provided, the Trimmer will determine if it is used in a type check. If it was used in
   a type check, the mapping will be included. If the trim-target type is not provided, the mapping
   will be included unconditionally.

   (b) Using TypeMapAssociationAttribute a map from Type to Type (source to proxy).
   The map will only contain an entry if the Trimmer determines the source type was explicitly
   allocated.

   Note Conflicting key/value mappings in the same type universe would be reconciled by the
   application re-defining the mapping entry that will be in the respective map. If a conflict
   is still present, the build should fail.

   Note The emitted map format is a readonly binary blob that will be stored in the application
   assembly. The format of the binary blob is an implementation detail that will be passed to
   an internal type contained with CoreLib.

5. The Trimmer will consider calls to TypeMapping.GetExternalTypeMapping<> and
   TypeMapping.GetTypeProxyMapping<> as intrinsic operations and replaced inline with the appropriate
   map instantiation (for example, Java via JavaTypeUniverse).

   IReadOnlyDictionary<string, Type> externalToType;
   TypeMapping.TryGetExternalTypeMapping<JavaTypeUniverse>(out externalToType);
   // The above will be replaced by the Trimmer with an instantiation of the appropriate map.
   // The "StaticTypeMap" being an internal type and an implementation detail provided by CoreLib.
   // Replaced with:
   //     IReadOnlyDictionary<string, Type> externalToType;
   //     externalToType = new StaticTypeMap(s_javaTypeUniverseMapBlob);

Example usage

Provided by .NET for Android runtime

// Type used to express specific type universe.
public sealed class JavaTypeUniverse : ITypeMapUniverse { }

// Java capability to enable type instance creation.
public interface IJavaCreateInstance
{
    object Create(ref JniObjectReference reference, JniObjectReferenceOptions options);
}

// Java capability implementation for object creation.
public class JavaObjectTypeMapAttribute<[DynamicallyAccessedMembers (DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.NonPublicConstructors)] T> : Attribute, IJavaCreateInstance
    where T : JavaObject
{
    public object Create(ref JniObjectReference reference, JniObjectReferenceOptions options)
    {
        // Create instance using T.
    }
}

// Java capability implementation for string creation.
public class JavaStringTypeAttribute : Attribute, IJavaCreateInstance
{
    public object Create(ref JniObjectReference reference, JniObjectReferenceOptions options)
    {
        IntPtr ptr = /* Extract the underlying string pointer from reference. */
        string str = Marshal.PtrToStringUni(ptr);
        return str;
    }
}

// -- Alternative attribute design
// This would expose the direct as a Type instead of as a generic parameter. It would reduce
// type loading costs and could be the single attribute for all "capabilities".
public class JavaObjectTypeMapAttribute : Attribute
{
    public JavaObjectTypeMapAttribute([DynamicallyAccessedMembers (DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.NonPublicConstructors)] Type type)
    { }

    public [DynamicallyAccessedMembers (DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.NonPublicConstructors)] Type TargetType { get; }
}

.NET for Android projection library

// Dependent association between typeof(string) => typeof(StringProxy).
[assembly: TypeMapAssociation<JavaTypeUniverse>(typeof(string), typeof(StringProxy))]

// Map string name of Java type to typeof(StringProxy), using typeof(string) to indicate
// if the entry should be included or not.
[assembly: TypeMap<JavaTypeUniverse>("java/lang/String", typeof(StringProxy), typeof(string))]

[JavaStringType]
public class StringProxy
{ }

User application

// Application reference for assembly to be used in type map generation.
[assembly: TypeMapAssemblyTarget<JavaTypeUniverse>("Application.SideCar.dll")]

// User defined type
[JavaObjectTypeMap<MyJavaClass>]
public class MyJavaClass : JavaObject
{ }

var inst = new ClassFromNuGet();

Generated Application.SideCar.dll

A sidecar assembly could always be generated to handle the following:

• Specify assembly type map targets (for example, .NET for Android runtime)
• Specify type mappings for types defined in the application.
• Generate proxies and mappings for types in Nugets to support older TFMs.

// Application reference for assembly to be used in type map generation.
[assembly: TypeMapAssemblyTarget<JavaTypeUniverse>("Android.Runtime.dll")]

[assembly: TypeMap<JavaTypeUniverse>("app/MyJavaClass", typeof(MyJavaClass), typeof(MyJavaClass))]

[assembly: TypeMap<JavaTypeUniverse>("lib/classFromNuget", typeof(ClassFromNuGetProxy), typeof(ClassFromNuGet))]

[JavaObjectTypeMap<ClassFromNuGet>]
internal class ClassFromNuGetProxy
{ }

Interop runtime (for example, .NET for Android) usage example.

// Stored by the interop runtime in some global static
static IReadOnlyDictionary<string, Type> s_JavaTypeMap;
TypeMapping.TryGetExternalTypeMapping<JavaTypeUniverse>(out s_JavaTypeMap);

...

string javaTypeName = /* Get Java type name from jniHandle */
s_JavaTypeMap.TryGetValue(javaTypeName, out Type? projection);
Debug.Assert(projection != null); // Assuming map contains type.

var creator = (IJavaCreateInstance)projection.GetCustomAttribute(typeof(JavaObjectTypeMapAttribute<>));
var objectRef = new JniObjectReference(jniHandle, JniObjectReferenceType.Local);
JavaObject mcw = (JavaObject)creator.Create(ref objectRef, JniObjectReferenceOptions.None);

Previous proposal

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate | AttributeTargets.Interface, Inherited = false)]
public sealed class TypeMappingAttribute : Attribute
{
    public TypeMappingAttribute(string mapping);
}

The above attribute would be searched in all assemblies passed to a tool/MSBuild Task/etc and the result would be a binary blob. This binary blob could be in one of several forms (a) a .cs file that defines a static ReadOnlySpan<byte>, (b) a binary file that could be embedded in a .NET assembly as a resource, or perhaps another option.

Question Are there security concerns with binary blobs being written to disk?

Question: The trimmer must run prior to binary blob generation since it wouldn't be trimmable. How does this impact the workflow?

Type mapping scenarios and trimmer:

Dynamic: No special tooling has run over the whole app. The type mappings are per-assembly and registered at runtime. Tooling can be used to generate or optimize the per-assembly mapping. This should handle plugins where a new assembly with additional mappings shows up in flight.

IL trimming: The IL trimmer should not treat the types involved in the mapping as roots - if the type is not otherwise referenced by the app, it should be removed from the mapping. IL trimmer (or some other tool) generates the per-app mapping blob that is consumed at runtime. It may be easiest to make this a IL trimmer feature. This scenario does not handle plugins.

AOT: It is similar to IL trimming case, but the exact format of the blob may need to be different - both to make it more efficient and to avoid dependency on metadata tokens that expect the IL trimming implementation is going to have.

This API would be based on the generated static data of type mappings being generated using a static hashing approach for the data. From the .NET side, it could be implemented through FrozenDictionary<TKey, TValue> and an instantiated from the generated data. A static ReadOnlySpan<byte> field inserted into the application or Assembly would integration seamless, but an embedded resource is also workable. This concept is similar to existing technologies in C, such as gperf or C Minimal Perfect Hashing Library. Size and performance should be measured using different approaches.

The API shape would be a mapping from a TKey, likely a string, to an internal type, conceptually containing the following:

public struct TypeMapValue
{
    public TBD LookUpData;
    public int Index;
}

The above type contains a field for the discovery of the type, not presently loaded, and the second represents an index into an array that contains the loaded type to use. The strawman example below helps illustrate the workflow.

TypeMapping<RuntimeTypeHandle> s_XtoNETMap = new (
    s_generated_XToNET,
    (TBD data) =>
    {
        // User loads System.Type based on data.
        return type.TypeHandle;
    });

TypeMapping<IntPtr> s_NETToXMap = new (
    s_generated_NETToX,
    (TBD data) =>
    {
        // User loads type in X based on data.
    });

public sealed unsafe class TypeMapping<TType>
    where TType : unmanaged
{
    private readonly FrozenDictionary<Key, TypeMapValue> _lookUp;
    private readonly TType[] _loadedType;
    private readonly delegate* <ReadOnlySpan<byte>, Key> _hashFunction;
    private readonly Func<TBD, TType> _typeLoad;

    public TypeMapping(ReadOnlySpan<byte> generatedTypeMap, Func<TBD, TType> typeLoad)
    {
        _lookUp = ParseData(generatedTypeMap, out HashFunction hash, out int count);
        _loadedType = new TType[count];
        _hashFunction = GetHashFunction(hash);
        _typeLoad = typeLoad;
    }

    public TType this[ReadOnlySpan<byte> key] => LookUp(key);

    private TType LookUp(ReadOnlySpan<byte> key)
    {
        // Verify the type is actually "known".
        if (!_lookUp.TryGetValue(_hashFunction(key), out TypeMapValue v))
            throw new Exception("Invalid type look-up");

        // Check if the type is loaded.
        ref TType tgt = ref _loadedType[v.Index];

        // Defer to the user if the type isn't loaded.
        if (default(TType).Equals(tgt))
            tgt = _typeLoad(v.LookUpData);

        return tgt;
    }
}

[AaronRobinsonMSFT]

/cc @jkotas @Sergio0694 @MichalStrehovsky @stephentoub @jonpryor @rolfbjarne @agocke @stephen-hawley

[stephentoub]

it could be implemented through FrozenDictionary<TKey, TValue> and an instantiated from the generated data

Is the intent that the whole implementation would be source generated, using the FD just for its API surface area? This was in the road map for FD, but we held off on making the necessary APIs public/protected (right now implementations need to be in the same assembly). If this is a requirement, we'll need to do the due diligence as part of this to confirm the abstract APIs that need to be exposed to enable this.

FD also currently lives in the System.Collections.Immutable library, which ships in both the shared framework and as a separate nuget package. Is that an appropriate location?

[jkotas]

The trimmer must run prior to binary blob generation since it wouldn't be trimmable. How does this impact the workflow?

There are a few different scenario:

• Dynamic: No special tooling has run over the whole app. The type mappings are per-assembly and registered at runtime. Source generator can be used to generate or optimize the per-assembly mapping. This should handle plugins where a new assembly with additional mappings shows up in flight.

• IL trimming: The IL trimmer should not treat the types involved in the mapping as roots - if the type is not otherwise referenced by the app, it should be removed from the mapping. IL trimmer (or some other tool) generates the per-app mapping blob that is consumed at runtime. It may be easiest to make this a IL linker feature. This scenario does not handle plugins.

• Native AOT: It is similar to IL trimming case, but the exact format of the blob may need to be different - both to make it more efficient and to avoid dependency on metadata tokens that I expect the IL trimming implementation is going to have.

Perfect Hash Function

Nit: Perfect hash functions tend to waste space. I am not sure whether we want to go there. Regular hash vs. perfect hash is small implementation detail that is not important for the overall design.

[rolfbjarne]

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate, Inherited = false)]

We map Objective-C protocols to interfaces, so I think AttributeTargets.Interface should be added here.

Priorties

1. Trimmer friendly - AOT compatible.
2. Usable from both managed and unmanaged environments.
3. Low impact to application start-up and/or Assembly load.
4. Be composable - handle multiple type mappings.

One thing that drove the current design for iOS was to use as little allocated (dirty / writable) memory as possible, because in some cases (in particular app extensions on iOS), the platform poses rather strict memory limits and will terminate the process if those limits are broken.

This is why in some cases we've used statically allocated lists for our data structures (in C - which means they don't require any allocations at startup, it all lives in read-only memory the OS can page out whenever needed and it doesn't count towards the memory limits) + binary search over those lists (we can sort them at build time). The number of entries in the arrays (low thousands at the very upper end) didn't make the binary search significantly slower than a dictionary lookup.

I'm not advocating for this particular solution, but if we could find an implementation where the data can be mmap'ed into the process as read-only memory (and not copied around afterwards), I think that would be great (and also performant on all other platforms as well).

[jkotas]

TBD

To figure out these details, it may be useful to work on CsWinRT and/or Objective-C interop patch that shows how this API would be consumed.

[rolfbjarne]

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate, Inherited = false)]
public sealed class TypeMappingAttribute : Attribute
{
    public TypeMappingAttribute(string mapping);
}

Actually a few more thoughts:

1. I might want to allow adding this attribute on existing types I don't control. For instance, I might want to map System.DateTime to NSDate.
2. I might want to map a managed type to more than one native type (once for Objective-C, once for Swift for instance).

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Enum | AttributeTargets.Delegate | AttributeTargets.Interface, Inherited = false)]
public sealed class TypeMappingAttribute : Attribute
{
    public TypeMappingAttribute(string mapping);
	public TypeMappingAttribute(string mapping, string nativeContext);
}

[TypeMapping ("OSObjCType", "Objective-C")]
[TypeMapping ("OSSwiftType", "Swift")]
public class ImportantType {}

[AttributeUsage(AttributeTargets.Assembly, Inherited = false)]
public sealed class ExternalTypeMappingAttribute : Attribute
{
    public ExternalTypeMappingAttribute(Type type, string mapping);
    public ExternalTypeMappingAttribute(Type type, string mapping, string nativeContext);
}

[assembly: ExternalTypeMapping (typeof (System.DateTime), "NSDate", "Objective-C")]
[assembly: ExternalTypeMapping (typeof (System.DateTime), "Date", "Swift")]

[Sergio0694]

"To figure out these details, it may be useful to work on CsWinRT and/or Objective-C interop patch that shows how this API would be consumed."

Would love to work together on this! (also cc. @manodasanW, of course). I'm reading through the proposal and it's not immediately obvious to me how exactly we'd get CsWinRT to switch to this new API surface and what would the effect be in practice. Perhaps we should schedule a call once everyone is back from vacation? 🙂

[Sergio0694]

One of our main concerns for Native AOT WinRT components in Windows is the binary size impact of using any WinRT interop at all, because the second we bring CsWinRT in, we end up rooting pretty much the entire reflection stack due to it using GetCustomAttribute<T> to lookup the generated vtable types on projected types (and I remember @MichalStrehovsky saying that as soon as you use that API, you root everything). We want to use WinRT because the ABI is way nicer for consumption for both C# and C++ (and Rust), but the binary size delta for a minimal component doing the same exact thing, between exposing a flat C API and a WinRT one, is quite significant 🥲

Is it in scope for this proposal to make it possible for CsWinRT to potentially switch to this and stop having to lookup attributes? Would there be performance concerns in case you have lots of types (eg. the base Windows SDK projections has hundreds and hundreds of projected types, if not thousands) to using this new API to retrieve vtable info for a type, vs. just using GetCustomAttribute on the type itself directly?

[jkotas]

I might want to allow adding this attribute on existing types I don't control.
I might want to map a managed type to more than one native type

Given that we need to reference external types, it may be simpler to only support the detached type mapping (ExternalTypeMapping in your example). The type mappings are expected to be generated, so they do not need to be convenient to write.

Attribute is just one of the possible ways to encode the information. A few alternative ways to encode the information:

• Long constant string: new TypeMapping("... long string with all type mappings ..."). The trimmer and native AOT compilers would recognize the TypeMapping constructor as an intrinsic and convert the long string into a pre-initialized hashtable.

• Method with specific pattern: TypeMapping CreateTypeMapping() { var m = new TypeMapping(); m.Add(typeof(...), ...); m.Add(typeof(...), ....); return t; }. Again, the trimmer and native AOT compilers would recognize this an intrinsic. (The special method can only contain calls to the specific and it cannot have any control flow.)

Is it in scope for this proposal to make it possible for CsWinRT to potentially switch to this and stop having to lookup attributes?

I think so - in trimmed or NAOT compiled scenarios at least.

[Sergio0694]

"I think so - in trimmed or NAOT compiled scenarios at least."

If that's the case then it might be worth also mentioning our other (primary) approach to generating vtable for types today in CsWinRT, both for projections and for user types. The two Aaron linked are just two approaches we use for either built-in custom type mappings (eg. say System.Numerics.Vector2 maps to Windows.Foundation.Numerics.Vector2), and for external types you might try to marshal (and for generic instantiations, we have that scenario too because of WinRT).

But for everything else, we use [WinRTExposedType]. This is added to all projections and user types (that's why they have to be partial), and have a type details pointing to some CsWinRT-generated type implementing IWinRTExposedTypeDetails. Then when you try to marshal one of these types, CsWinRT basically does obj.GetType().GetCustomAttribute<WinRTExposedType>() and then gets that exposed type, activates it, and invokes GetExposedInterfaces() to get the vtable entries to pass to ComWrappers.

We basically do something like this, when marshalling:

• Does the type have the attribute? If so, use that
• Is the type in the authored dictionary?
  • If so, get the ABI type from there and then get the attribute from it to get the vtable
• Is the type in the mapping of built-in custom type mappings? If so, get the entries from there
• Is the type in one of the generated global lookup tables for vtables? If so, use that
• Otherwise:
  • If on NAOT, throw
  • If not, do some unsafe reflection nonsense

All the logic I outlined here is more or less all in this method.

It would be nice if we could somehow use this new system to streamline all these possible approaches into a single, better one 🙂