[mobile] [WIP] .NET 11 mobile runtime pack and workload updates

[kotlarmilos]

Description

Work in progress.

In eng/Subsets.props, clear _BuildMonoRuntimePack for TargetsAppleMobile or android, and trim MonoCrossAOTTargetOS to browser+wasi, so the build no longer produces the Mono mobile runtime packs or the mobile AOT-cross packs. WebAssembly Mono packs continue to be produced. Flows into the VMR (src/runtime/eng/Subsets.props) via codeflow.

This PR's own change is eng/Subsets.props only; the validation pins are inherited from the runtime stage-1 branch (PR #129293) and reverted there.

Validation pipelines (must pass): runtime PR build produces no Microsoft.NETCore.App.Runtime.Mono. packs; wasm packs still produced.

[github-actions]

Note

This review was generated by Copilot.

🤖 Copilot Code Review — PR #129295

Holistic Assessment

Motivation: The PR is part of a broader effort to remove Mono mobile runtime packs and workloads from .NET 11 (with mobile moving to CoreCLR/NativeAOT). The motivation is clear and aligned with the linked stage-1 PR (#129293) removing test legs.

Approach: The approach is correct — clearing _BuildMonoRuntimePack via an empty element after all setters leverages MSBuild last-writer-wins semantics, and trimming MonoCrossAOTTargetOS to browser+wasi removes the cross-AOT packs cleanly.

Summary: ⚠️ Needs Human Review. The change is logically sound and accomplishes its stated goal. However, there is a minor inconsistency with the file's existing conventions that a maintainer should decide on, and the WIP/draft status means this is expected to evolve.

---

Detailed Findings

💡 Style Inconsistency — TargetOS == 'android' vs TargetsAndroid

The new condition at line 716 uses '$(TargetOS)' == 'android':

<PropertyGroup Condition="'$(TargetsAppleMobile)' == 'true' or '$(TargetOS)' == 'android'">

Every other reference to the Android target in this file uses the $(TargetsAndroid) convenience property (lines 32, 73, 74, 100, 111). While functionally equivalent — TargetsAndroid is defined as true when TargetOS == 'android' in eng/RuntimeIdentifier.props — using $(TargetsAndroid) would be consistent with the file's existing convention:

<PropertyGroup Condition="'$(TargetsAppleMobile)' == 'true' or '$(TargetsAndroid)' == 'true'">

This is non-blocking but worth harmonizing for readability.

✅ Correct MSBuild Semantics — Property Clearing

The empty element <_BuildMonoRuntimePack></_BuildMonoRuntimePack> correctly clears the property using MSBuild's last-writer-wins semantics. Its placement after all three possible setters (lines 699, 707, 713) ensures it is effective in all build configurations (standard, VMR non-source-build, and VMR source-build).

✅ Cross-AOT Trimming Is Complete

The MonoCrossAOTTargetOS reduction from android+browser+wasi (plus the macOS conditional expansion for tvos+ios+maccatalyst) to just browser+wasi correctly removes all mobile AOT cross-compiler targets while preserving WebAssembly support.

💡 Missing Comment — Clarifying Intent

Consider adding a brief XML comment explaining why the Mono runtime pack is disabled for these targets, e.g.:

<!-- .NET 11: Mobile platforms no longer use Mono runtime packs (moved to CoreCLR/NativeAOT) -->
<PropertyGroup Condition="'$(TargetsAppleMobile)' == 'true' or '$(TargetsAndroid)' == 'true'">

This would help future readers understand the intent without having to trace PR history.

✅ No Unintended Side Effects on WASM

The clearing only fires for Apple Mobile and Android. Browser/WASI targets are not matched by TargetsAppleMobile or TargetOS == 'android', so WASM Mono runtime packs will continue to be produced as expected.

⚠️ Draft/WIP Status — Validation Pending

The PR description states validation pipelines must confirm no Microsoft.NETCore.App.Runtime.Mono.* mobile packs are produced while WASM packs remain. As a draft PR, this validation is presumably still in progress. A maintainer should confirm CI results before merging.

Generated by Code Review for issue #129295 · ● 3M · ◷

[dotnet-policy-service]

Tagging subscribers to this area: @akoeplinger, @matouskozak, @simonrozsival
See info in area-owners.md if you want to be subscribed.