[libs][mono] Prevent static constructor from referencing Internal.Runtime.Augments.DynamicDelegateAugments in build scenarios without linking

[ivanpovazan]

This PR fixes a regression introduced with unifying the System.Linq.Expressions library build in #88723 when targeting iOS-like platforms without linking (no trimming) with Mono.

The regression was noticed in libraries tests failures on tvos-arm64 reported here: #90494 which are configured not to perform any trimming during the app build.

The tests are failing due to the fact that DynamicDelegateLightup as a type is not trimmed away during library build time (as it previously was before unification), and since the trimming is disabled during app (libraries tests) build time ends up in the final executable. This further cause a problem at runtime because Mono tries to initialise a type which references a type/method which is only implemented by NativeAOT: Internal.Runtime.Augments.DynamicDelegateAugments https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/System.Private.CoreLib/src/Internal/Runtime/Augments/DynamicDelegateAugments.cs

This has been fixed by guarding a reference to the private API that only NativeAOT implements preventing static constructor to throw TypeInitializationException

---

Fixes #90494

[ghost]

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

Issue Details

---

This PR fixes a regression introduced with unifying the System.Linq.Expressions library in #88723 when targeting iOS-like platforms without linking (no trimming) with Mono.

The regression was noticed in libraries tests failures on tvos-arm64 reported here: #90494 which are configured not to perform any trimming during the app build.

The tests are failing due to the fact that DynamicDelegateLightup as a type is not trimmed away during library build time, and since the trimming is disable during app build time ends up in the final executable. This further cause a problem at runtime because Mono tries to initialise a type which references a type/method which is only implemented by NativeAOT: Internal.Runtime.Augments.DynamicDelegateAugments https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/System.Private.CoreLib/src/Internal/Runtime/Augments/DynamicDelegateAugments.cs

This has been fixed by guarding a reference to the private API that only NativeAOT implements preventing static constructor to throw TypeInitializationException

---

Fixes #90494

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	area-System.Linq.Expressions
Milestone:	-

[ivanpovazan]

/cc: @rolfbjarne @SamMonoRT @vargaz

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

It would be great if we could get this fix in before RC1 snap.

[jkotas]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[eerhardt]

The tests are failing due to the fact that DynamicDelegateLightup as a type is not trimmed away during library build time (as it previously was before unification), and since the trimming is disabled during app (libraries tests) build time ends up in the final executable. This further cause a problem at runtime because Mono tries to initialise a type which references a type/method which is only implemented by NativeAOT: Internal.Runtime.Augments.DynamicDelegateAugments

This is the same situation on CoreCLR. Is the difference here that CoreCLR won't run the DynamicDelegateLightup static constructor, but Mono will?

[jkotas]

This is the same situation on CoreCLR. Is the difference here that CoreCLR won't run the DynamicDelegateLightup static constructor, but Mono will?

I assume that it is the case. There are situations where Mono runs beforefieldinit static constructors even when the field is not accessed. It is tracked by #88066 and related bugs.

[ivanpovazan]

The CI build shows that the regression has been fixed.
The failures are not related.

---

Thanks everyone for your help, feedback and suggestions.

Taking into account the RC1 snap deadline and the amount of time required for runtime-extra-platforms pipeline to finish, I will keep the current state as-is. Nevertheless, I have opened a follow-up issue: #90548 to address suggestions for refactoring and simplification from @jkotas and @eerhardt