Skip to content

Drop Mono support for mobile targets at .NET 11 GA #5553

Closed as not planned
Closed as not planned

Description

@jamescrosswell

Background

.NET 11 makes CoreCLR the default runtime for Android, iOS and MacCatalyst. Mono is not removed in the pre-releases: <UseMonoRuntime>true</UseMonoRuntime> is documented as an opt-back in .NET MAUI moves to CoreCLR in .NET 11.

Our reading is that this escape hatch exists for the .NET 11 pre-release period, and that dropping Mono for mobile is still planned for .NET 11 GA. Raised by @dartasen in #5529 (comment) and discussed in #5529 (comment).

So #5529 keeps Mono coverage for the pre-releases. This issue is the reminder to remove it at GA.

Current state on the preview 7 SDK

UseMonoRuntime=true alone fails on mobile TFMs:

error NETSDK1242: Building Android projects with the Mono runtime is not supported in .NET 11.0
and later. Use the CoreCLR runtime or target .NET 10.0.

The SDK's own _DisableCheckForUnsupportedMonoMobileRuntime=true turns that check off, and the Mono runtime packs still ship, so the result is a genuine Mono build — verified on the device test app:

  • net11.0-android37.0 → libmonosgen-2.0.so, libmonodroid.so, no libcoreclr.so
  • net11.0-ios26.5 → libmonosgen-2.0.dylib and libxamarin-dotnet.dylib (not the -coreclr variant), no libcoreclr.dylib

The gating target is _CheckForUnsupportedMonoMobileRuntime in Microsoft.NET.TargetFrameworkInference.targets, covering android, ios, tvos and maccatalyst for TFM >= 11.0.

What to do at .NET 11 GA

Confirm Mono is actually gone for mobile, then:

  • integration-test/android.Tests.ps1 — drop the mono cases and the _DisableCheckForUnsupportedMonoMobileRuntime injection
  • integration-test/ios.Tests.ps1 — same
  • test/Sentry.Android.AssemblyReader.Tests/Sentry.Android.AssemblyReader.Tests.csproj — the Mono AOT APK variants (_TestAPK 5-8) are already net10.0-android only; drop them entirely if Mono is gone, rather than widening them
  • test/Sentry.Android.AssemblyReader.Tests/AndroidAssemblyReaderTests.cs — the NET11_0_OR_GREATER AOT skip
  • Update CONTRIBUTING.md if the mobile runtime story is worth recording for next year's upgrade

If instead Mono survives into .NET 11 GA and only the _Disable... property goes away, the fix is smaller: delete that property from the two integration test scripts and keep the Mono cases.

Related

Activity

  1. added this to the 7.0.0 milestone on Sep 9, 2026
  2. linear-code commented on Sep 9, 2026

    @linear-code
  3. changed the title [-]Drop Mono support for mobile targets at .NET 11 GA[/-] [+][Maybe???] Drop Mono support for mobile targets at .NET 11 GA[/+] on Sep 9, 2026
  4. changed the title [-][Maybe???] Drop Mono support for mobile targets at .NET 11 GA[/-] [+]Drop Mono support for mobile targets at .NET 11 GA[/+] on Sep 10, 2026
  5. jamescrosswell commented on Sep 10, 2026

    @jamescrosswell
    CollaboratorAuthor

    Closing: this was filed on the reading that UseMonoRuntime was a supported opt-back for the .NET 11 pre-releases, with Mono dropping at GA. Microsoft have since confirmed that isn't the case — Mono is not officially supported on .NET 11 for mobile at all, so there is no pre-release Mono coverage to remove later.

    The follow-up post is explicit:

    As of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI mobile apps

    and the build property to select Mono "has been removed entirely" — https://devblogs.microsoft.com/dotnet/coreclr-progress-and-mono-timeline-dotnet-maui/

    #5529 therefore tests Mono only where it is supported (net10.0 and below) and CoreCLR only on net11.0, which is the state it was already in before this issue was filed. Nothing left to do at GA.

    One correction worth carrying forward, since it was found while investigating this: Android assembly store v4 is not a CoreCLR artifact. A Mono net11 APK reports store version 0x80010004 (64-bit | aarch64 | v4) — the same version a CoreCLR build reports, the differing nibble being the ABI. v4 is a .NET 11 Android workload change, independent of runtime, so runtime choice is not a workaround for #5454.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    .NETPull requests that update .net codeTask

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions