Repository navigation
Proposal: Create TypeMapEntryAssembly ItemGroup to indicate assemblies that should be used as entry points for TypeMapHandler #121138
Description
Activity
Tagging subscribers to this area: @dotnet/illink
See info in area-owners.md if you want to be subscribed.How is this going to work when the app is not processed by trimmer or AOT compiler?
@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 throughAssembly.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.
@simonrozsival if we were to take an
Assemblyinstance, 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.
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 usedPresumably 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 toAssembly.GetEntryPoint(). Similarly, pipe through TypeMapEntryAssembly to ILLink/ILC and prefer that if it's set, otherwise use entrypoint assembly.Would that work?
Reacted by Šimon Rozsíval, Jan Kotas and Jeremy Koritzinsky@MichalStrehovsky yes, this seems like an elegant solution for Android and iOS.
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?
- added a commit that references this issue
on Dec 15, 2025 @jtschuster @simonrozsival do we still need this issue or was this superseded by #121513 and we can close?
@jtschuster @simonrozsival do we still need this issue or was this superseded by #121513 and we can close?
I've been working on typemap support for iOS, and #121513 seems to be enough for us at least.
- locked and limited conversation to collaborators
on Aug 22, 2026
Metadata
Metadata
Assignees
Type
Projects
- Status
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