Add OpenHarmony (HarmonyOS) support to the .NET runtime
- Dominant language
- C#
- Stars
- 18.3k
- Forks
- 5.6k
- PR merge metrics
- PR metrics pending
Description
## Summary
.NET currently supports Android (`linux-bionic`) and the Apple mobile platforms (`ios-*`, `tvos-*`, `maccatalyst-*`), but not OpenHarmony / HarmonyOS. OpenHarmony is an open-source operating system for phones, tablets, and IoT devices, and HarmonyOS NEXT is the commercial distribution built on it. Adding .NET support would allow C#/.NET applications and libraries to run on this platform.
This issue tracks the overall porting effort. The work is split into a series of PRs so each piece can be reviewed independently.
## Scope
1. **Runtime sandbox fixes** — OpenHarmony app sandboxes differ from a plain Linux environment in ways that break .NET at startup or at runtime:
- `/tmp` is mounted read-only; shared-memory files must honor `TMPDIR`.
- The `get_mempolicy`/`mbind` syscalls are blocked by the sandbox's seccomp policy, so the GC NUMA probe SIGSYS-crashes the process at startup.
- The sysroot's pthread lacks robust-mutex support, so `NamedMutex` must use the shared-memory-file implementation.
- Tracked by: https://github.com/dotnet/runtime/pull/132827 (first PR of the series, currently ready for review).
2. **Build infrastructure** — `-os linux-ohos` support: RID graph entry, NDK/sysroot toolchain plumbing, and CI cross-build legs mirroring `linux-bionic`.
3. **Runtime (CoreCLR/Mono) enablement** — platform-level bring-up, PAL adjustments, and validation on OpenHarmony devices/emulators.
4. **Tests & validation** — targeted test legs for the `linux-ohos` RID.
## Approach
- Follow the existing `linux-bionic` (Android) and `linux-musl` patterns for cross-compilation and RID plumbing.
- Keep every PR independently reviewable and a no-op on existing platforms: new behavior is guarded by `TARGET_OHOS`, which is only defined when the new target is selected.
## Open questions
- Which HarmonyOS API level and NDK version to target.
- Whether to support both OpenHarmony (open source) and HarmonyOS NEXT (commercial) from the start.
- Mono vs CoreCLR prioritization for the first milestone.
> [!NOTE]
> This issue was authored with AI assistance (Copilot/agent tooling) under the repository owner's direction.
Contributor guide
Research direction
Start by reading PR 132827, then compare the existing linux-bionic and linux-musl approaches mentioned in the issue. Choose one independently reviewable area—RID and toolchain plumbing, TARGET_OHOS runtime enablement, or targeted validation—and confirm that the corresponding linux-ohos build or test path works without changing existing platforms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, linux
- Domain
- build-system, mobile-dev, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100