[Trimming] Fix startup crash when TypeMapAssemblyTarget attribute survives but target assembly is fully trimmed

[Copilot]

In trimmed CoreCLR apps, a TypeMapAssemblyTarget attribute could survive trimming even when its named assembly was fully trimmed (all its TypeMap entries were conditional on trim targets that were never marked). At runtime, TypeMapLazyDictionary unconditionally calls Assembly.Load for every surviving attribute, crashing with FileNotFoundException.

Changes

Fix (a) — ILLink TypeMapHandler.cs (primary fix)

• TypeMapAssemblyTarget attributes are now only marked when their target assembly is also marked (has at least one surviving TypeMap/TypeMapAssociation entry).
• Added _pendingAssemblyTargetsByAssembly: when a group is seen but the target assembly has no surviving entries yet, the attribute is deferred here rather than immediately marked.
• Added TriggerPendingAssemblyTargets(): called from MarkTypeMapAttribute whenever a TypeMap/TypeMapAssociation entry is marked, flushing any deferred assembly-target attributes for that assembly.
• If the target assembly can't be resolved in the linker input at all, the attribute is silently dropped (Assembly.Load would fail anyway).

Fix (c) — Defense-in-depth assemblynative.cpp

• AssemblyTargetProcessor::Process now calls spec.LoadAssembly(FILE_LOADED, /*fThrowOnFileNotFound=*/FALSE) and skips null results instead of throwing. Protects against dangling attributes reaching the runtime in edge cases or non-trimmed scenarios.

Test

• New test TypeMapAssemblyTargetRemovedWhenAllEntriesTrimmed with two dependency assemblies: a shared group-type assembly, and a conditional.dll with only conditional TypeMap entries (trim target never marked). Verifies the TypeMapAssemblyTarget attribute is removed from the main assembly after linking.

[AaronRobinsonMSFT]

@copilot No changes should be done to CoreCLR itself. This is entirely a trimming issue. When the trimmer decides to remove a type based on the typemap reference algorithm, it should also remove the typemap attributes that reference it.

[Copilot]

@copilot No changes should be done to CoreCLR itself. This is entirely a trimming issue. When the trimmer decides to remove a type based on the typemap reference algorithm, it should also remove the t...

Reverted all changes to assemblynative.cpp in commit $(git rev-parse --short HEAD). The fix is now purely in the ILLink trimmer (TypeMapHandler.cs): TypeMapAssemblyTarget attributes are only marked when their target assembly has at least one surviving TypeMap/TypeMapAssociation entry, so dangling attributes are removed at trim time rather than relying on any CoreCLR defense.

@copilot No changes should be done to CoreCLR itself. This is entirely a trimming issue. When the trimmer decides to remove a type based on the typemap reference algorithm, it should also remove the t...

Reverted all changes to assemblynative.cpp in commit 516910c2. The fix is now purely in the ILLink trimmer (TypeMapHandler.cs): TypeMapAssemblyTarget attributes are only marked when their target assembly has at least one surviving TypeMap/TypeMapAssociation entry, so dangling attributes are removed at trim time rather than relying on any CoreCLR defense.

[AaronRobinsonMSFT]

@copilot Please update the PR description to reflect the current changes in this PR.

[dotnet-policy-service]

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