Proposal: Create TypeMapEntryAssembly ItemGroup to indicate assemblies that should be used as entry points for TypeMapHandler

[jtschuster]

IOS and Android are trimmed as libraries and have no EntryPointAssembly in the trimmer that the TypeMapHandler can use as the root for marking TypeMap attributes and types. ILLink and ILC need to provide a way for library apps to set the entrypoint assembly (or assemblies) for type mapping. Following the example of the UnmanagedEntryPointsAssembly item group for ILC, it seems natural to create a new TypeMapEntryAssembly item group to indicate the entrypoints for the TypeMap handling.

See #120271 for additional context and conversation.

Open questions:

Can there be multiple TypeMapAssemblyItems? If so, can there for both Exe and Library projects, or just Library?

I think it makes sense to allow multiple, especially since there is an API that allows setting and resetting the entry assembly. This also aligns with UnmanagedEntryPointsAssembly

What are the defaults? Are the implicitly set in MSBuild and explicitly passed to ILLink, or implicitly set in ILLink? Do we assume the entrypoint assembly for exe applications if no TypeMapEntryAssembly is explicitly provided to the ILLink process, or do we require it to be passed explicitly? Do we assume the IntermediateAssembly is a TypeMapEntryAssembly for Library apps too?

I think it makes sense to infer the items in MSBuild, but should be passed explicitly to ILLink. I believe this also generally aligns with UnmanagedEntryPointsAssembly. For Exe applications, the IntermediateAssembly will be added to TypeMapEntryAssembly by default. For Libraries it would need to be done manually or by setting a property (for example, SetTypeMapEntryAssembly) to true.

cc @dotnet/illink @dotnet/ilc-contrib @simonrozsival

[dotnet-policy-service]

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

[jkotas]

How is this going to work when the app is not processed by trimmer or AOT compiler?

[simonrozsival]

@jkotas @jtschuster I think it would make sense to also have TypeMapping.GetOrCreateExternalTypeMapping<T>(Assembly typeMapEntryAssembly) that would give the caller the option to explicitly state which assembly should be used instead of needing to change the global state through Assembly.SetEntryAssembly. That would also be needed for the case without trimming.

I don't see a use-case for multiple type map assemblies at the moment. I don't think we would at least use it for Android or iOS.

[jkoritzinsky]

@simonrozsival if we were to take an Assembly instance, we wouldn't be able to efficiently traverse the type map entries at trim time unless we also have a mechanism to specify which assemblies are "valid" type map entry assemblies (like this proposal here). The two proposals combined (an API to say "build a type map from here" and a build time input to say "preserve type maps starting from here") could work.

There would be an open question though of "if the same type map is accessible from two type map entry points, should be maps be merged?" I think the answer would have to be yes, but that would be confusing.

[MichalStrehovsky]

I think it would make sense to also have TypeMapping.GetOrCreateExternalTypeMapping<T>(Assembly typeMapEntryAssembly) that would give the caller the option to explicitly state which assembly should be used

Presumably this API would return distinct mappings from the API that doesn't take a parameter and one could generate all sorts of mapping subsets by specifying different assemblies. It would require a bit of a rewrite how this is implemented (that assumes only one mapping (for each universe) per app) and presumably would make the lookups slower (multiple hashtable lookups for each assembly instead of one global hashtable). Unless we really need this power, I wouldn't go there.

If we can keep this simple and only have one assembly that can be specified using an MSBuild property and this value would get used for trimming/AOT and preserved as an AppContext switch so that we can use it instead of Assembly.GetEntryAssembly at runtime, it would be the best.

Something like:

<ItemGroup>
    <RuntimeHostConfigurationOption Include="System.Runtime.InteropServices.TypeMappingEntryAssembly"
        Value="$(TypeMapEntryAssembly)"
        Condition="$(TypeMapEntryAssembly) != ''" />
</ItemGroup>

And then use AppContext.GetValue("System.Runtime.InteropServices.TypeMappingEntryAssembly") at runtime and prefer that to Assembly.GetEntryPoint(). Similarly, pipe through TypeMapEntryAssembly to ILLink/ILC and prefer that if it's set, otherwise use entrypoint assembly.

Would that work?

[simonrozsival]

@MichalStrehovsky yes, this seems like an elegant solution for Android and iOS.

[Sergio0694]

Double checking: this would not affect libraries published as NAOT components, right? i.e. WinRT components.

Is this something that would impact us in the hosted WinRT component scenario? That is, managed .dll for the component that's run with CoreCLR bootstrapped from a native host. Or would that also be fine given this scenario wouldn't have any trimming?