Add OpenHarmony (HarmonyOS) support to the .NET runtime

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

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: Use the process temp directory for shared memory on OpenHarmony #132827 (first PR of the series, currently ready for review).
Build infrastructure — -os linux-ohos support: RID graph entry, NDK/sysroot toolchain plumbing, and CI cross-build legs mirroring linux-bionic.
Runtime (CoreCLR/Mono) enablement — platform-level bring-up, PAL adjustments, and validation on OpenHarmony devices/emulators.
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.

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

Already tracked at #103627.

Add post-PR#132827 OHOS upstream PR plan

Add OHOS PR plan restructured on the OpenBSD/Haiku landing model

Milestone update — first openharmony-arm64 release + device-verified.

Released (2026-09-10): all three forks now publish under the openharmony-arm64 RID (the rename requested in review):

springmin/sdk-ohos v11.0.100-rc.1.26451.109-ohos — dotnet-sdk-…-openharmony-arm64.tar.gz (160MB)
springmin/runtime-ohos v11.0.0-rc.1.26451.109-ohos — runtime / NativeAOT / ILCompiler / Crossgen2 packs
springmin/aspnetcore-ohos v11.0.0-rc.1.26451.109-ohos

Device verification (HarmonyOS, aarch64):

SDK installs and runs: dotnet --info reports RID: openharmony-arm64; dotnet new/build/run works end-to-end.
ELF .codesign: fixed a release-blocking issue where shipped signatures were rejected on device (EPERM). Signing passes now force re-sign every ELF (selfsign --force); the republished tarball's csc executes on device.
R2R 27.1: clean-rebuild verification confirmed the earlier NativeAOT SIGSEGV report was a toolchain version-mismatch, not a regression (issue NativeAOT app startup SIGSEGV after #132787 (R2R 27.1 unboxing stubs) — null TypeManager in InitializeModules #133296 closed).

Upstream PRs:

Add OpenHarmony/HarmonyOS build infrastructure #132953 (infra + RID graph, includes the ohos → openharmony rename and all review items) — awaiting re-review.
Use the process temp directory for shared memory on OpenHarmony #132827 (sandbox fixes: read-only /tmp, NUMA, robust-mutex) — awaiting review.

Next: continue the upstream PR series (sysroot compile fixes, NativeAOT BuildIntegration, SDK RID support) per the plan posted in the fork docs.

Note

This comment was drafted with AI assistance (agent tooling) under the reporter's direction; release and device results were verified by the reporter.

Follow-up (2026-09-12): released assets corrected + independently verified.

Asset fixes (re-uploaded; verified after re-download):

runtime-ohos Microsoft.NETCore.App.Runtime.ohos-arm64.11.0.0-rc.1.26451.109.nupkg — the released reassembly had dropped runtimes/ohos-arm64/lib/net11.0/System.Private.CoreLib.dll, so AOT publish failed (MSB4018 + FileNotFoundException); restored (82,705,719 → 91,029,763 B).
runtime-ohos Microsoft.DotNet.ILCompiler.11.0.0-rc.1.26451.109.nupkg — restored the ohos RID mapping in the ILCompiler targets and runtime.json; without it the legacy toolchain fails with Target OS 'ohos' is not supported.
runtime-ohos aspnetcore-runtime-11.0.0-rc.1.26451.109-ohos-arm64.tar.gz — pruned 3 stale accumulated Microsoft.NETCore.App frameworks (67.5 → 18.7 MB); host + frameworks verified on device.

Verification:

Full release audit (19 nupkg + 11 tar.gz): all RuntimeList declarations satisfied, SPC present, no stale RID references.
Fresh-consumer E2E (clean NuGet cache, release assets only): AOT publish rc=0 + device run for both shipped SDK tarballs.
CI: ohos-full-build run 34612494983 succeeded with the fixed build-ohos-all.sh condition (reassembly now runs only for missing/empty/corrupt packs) — the produced runtime pack is correct (RuntimeList 0 missing, R2R CoreLib in place, functional files byte-identical to the released pack).

Known gap (found while testing):

PublishReadyToRun is rejected for ohos-arm64 / openharmony-arm64 with NETSDK1095: ResolveReadyToRunCompilers.GetCrossgen2TargetOS has no ohos in its portable-platform list and the RID graph intentionally does not inherit linux. Fix = sdk-ohos task patch + SDK rebuild; tracking as follow-up.

Upstream PRs:

Add OpenHarmony/HarmonyOS build infrastructure #132953 — approved (jkotas); blocked only on unrelated Helix/infra checks.
Use the process temp directory for shared memory on OpenHarmony #132827 — all review comments addressed; awaiting re-review.

Note

This comment was drafted with AI assistance (agent tooling) under the reporter's direction; release and device results were verified by the reporter.

Follow-up (2026-09-12): PublishReadyToRun now works end-to-end on device — the gap from the previous comment is closed.

Root causes (two, stacked):

SDK side — ResolveReadyToRunCompilers.GetCrossgen2TargetOS had no ohos/openharmony in its portable-platform list and the RID graph intentionally keeps them standalone (no linux inheritance), so PublishReadyToRun failed with NETSDK1095. Fixed in sdk-ohos (f00cb86389) and shipped in the rebuilt SDK.
Tool side — the shipped Microsoft.NETCore.App.Crossgen2.<rid> pack was a trimmed single-file publish: ILLink strips interface-dispatched methods (CustomAttributeTypeProvider.GetPrimitiveType from ILCompiler.TypeSystem.dll — the same class of issue as NativeAOT app startup SIGSEGV after #132787 (R2R 27.1 unboxing stubs) — null TypeManager in InitializeModules #133296) and the bootstrap-layout publish does not carry the framework, so the tool failed at startup on device (TypeLoadException / missing closure). Fixed in sdk-ohos by re-publishing crossgen2_publish as an untrimmed split layout (PublishSingleFile=false, PublishTrimmed=false) and reassembling the pack (framework overlay from the runtime pack + runtimepack deps entry), mirroring the ilc split-publish handling that has been device-verified since the earlier rounds (710f6e9d, 7d61d65a).

Verification:

CI: ohos-full-build run 34670280963 succeeded (openharmony-arm64).
Device E2E (SDK + app with PublishReadyToRun=true): publish rc=0 (r2rohfix.dll 4,608 B IL → 6,656 B R2R) and device run rc=0:
```
R2R-FIX-OK sum=4950 sqrt2=1.4142
FR: .NET 11.0.0-rc.1.26451.109
```

Released assets updated (re-download verified):

Microsoft.NETCore.App.Crossgen2.openharmony-arm64.11.0.0-rc.1.26451.109.nupkg — 7,948,483 → 23,759,473 B (untrimmed split layout + framework).
dotnet-crossgen2-11.0.0-rc.1.26451.109-openharmony-arm64.tar.gz — 7,613,187 → 8,143,875 B (refreshed from the same layout).
Microsoft.AspNetCore.App.Runtime.openharmony-arm64 + aspnetcore-runtime-…-openharmony-arm64.tar.gz — were missing from the release; uploaded.

Legacy ohos RID: the legacy SDK tarball received the R2R fix backported (task assembly swap); the legacy crossgen2 pack stays frozen (the legacy RID is no longer built on the current branch). One observation resolved: RuntimeInformation.RuntimeIdentifier reporting ohos-arm64 on the test device traced to DOTNET_ROOT pointing at the legacy ohos SDK (its hostfxr predates the rename); with the rebuilt SDK the same app reports openharmony-arm64 correctly.

Upstream PRs: #132953 — approved, blocked only on unrelated infra checks; #132827 — awaiting re-review.

Note

This comment was drafted with AI assistance (agent tooling) under the reporter's direction; release and device results were verified by the reporter.

Plan update: restructured on the BSD/Haiku landing model.

Sharing the reorganized upstream plan for stacked-PR visibility.

Open PRs (status)

Add OpenHarmony/HarmonyOS build infrastructure #132953 — infra + RID graph (11 files). Approved; awaiting merge. The failing leg is Helix test-infrastructure, not this PR.
Use the process temp directory for shared memory on OpenHarmony #132827 — sandbox fixes (6 files). RID naming is settled as openharmony (the rename is already on the branch); a small follow-up commit (comment fixes + one test-path fix) was pushed on 09-13. Awaiting re-review.

Remaining runtime PRs (submission order; one concern each, OpenBSD/Haiku granularity)
N1 clrfeatures.cmake · N2 pal/src/configure.cmake + CMakeLists · N3 zstd.cmake · N4 libs/CMakeLists.txt + extra_libs.cmake · N5 apphost/static/CMakeLists.txt · N6 canceled (inotify_init1 is not trapped) · N7 pal_process.c (close_range guard) · N8 pal_interfaceaddresses.c (ethtool speed) · N9 clrconfigvalues.h (W^X default off; device-verified rationale) · N10 crossgen-corelib.proj · N11 Native.Unix.targets · N12 SingleEntry.targets · N13 packs (targetingpacks.targets, ds-portable-rid.c, sfxproj R2R-off, ILCompiler.pkgproj) · N14 eng/native/tryrun.cmake · N15 libraries TFM mapping (Directory.Build.props/targets + sfx + shims) · N16 System.Console.csproj.

SDK (split by layer): S1a RID data → S1b environment defaults → S1c codesign (reviewer-gated; default downstream — the enforcement is HarmonyOS-commercial-only). aspnetcore: A1 (RID lists + NativeAOT-for-ohos disable). CI leg: last, modeled on the OpenBSD leg (#130761).

Open for reviewer input

illink Microsoft.NET.ILLink.targets — its own tools/ PR, or fold into N12?
S1c codesign: upstream or downstream (needs one reviewer statement)?
Confirm the granularity/sequence before the remaining PRs are submitted.

The full plan (per-PR rationale, constraints, post-merge cleanups) is maintained on the fork branch: https://github.com/springmin/runtime-ohos/blob/feature/openharmony/docs/plans/2026-09-07-ohos-pr-plan-bsd-haiku-model.md

docs: mark the dotnet#132866 plan post as done

audit §32: upstream-gated follow-ups prepared as fork branches + patches

docs: refresh the upstream state to 2026-10-01

docs: register the reviewer threads' other-work items and our open ac…

docs: upstream opening drafts for dotnet#132827/dotnet#132953/dotnet#…

Add OpenHarmony/HarmonyOS build infrastructure (#132953)

Progress update — infrastructure and the first runtime PRs have landed

Since the plan update in September, the landing has started following the sequence listed there.

Merged

Add OpenHarmony/HarmonyOS build infrastructure #132953 — build infrastructure + RID graph (2026-10-14).
Add OpenHarmony platform identity and exclude unsupported NUMA calls #134670 — OpenHarmony platform identity (TargetOS=ohos); unsupported NUMA calls excluded (2026-09-26).
Skip robust mutexes on OpenHarmony #135321 — robust mutexes skipped on OpenHarmony (2026-10-07).
coreclr: disable the LTTng event source on OpenHarmony #135808 — N1: LTTng event source disabled (clrfeatures.cmake).
coreclr: PAL build fixes for OpenHarmony #135838 — N2: PAL build fixes (pal/src/configure.cmake + CMakeLists.txt).
corehost: singlefilehost fixes for OpenHarmony #135863 — N5: singlefilehost fixes (apphost/static/CMakeLists.txt), 2026-10-20.

Open

native: use the C90 qsort workaround for zstd on OpenHarmony #135839 — N3: C90 qsort workaround for zstd.
native: skip gssapi on OpenHarmony and use the OpenSSL crypto shim #135840 — N4: skip gssapi; use the OpenSSL crypto shim.
System.Native: read the full ethtool speed on OpenHarmony #135866 — N8: read the full ethtool speed.
coreclr: default EnableWriteXorExecute to 0 on OpenHarmony #136131 — N9: default EnableWriteXorExecute=0 (the sandbox denies PROT_EXEC on the file-backed mappings the W^X allocator uses); approved, CI finishing.
eng/native: pin the OHOS cross-build FIFO probe answers #136132 — N14: pin the OHOS cross-build FIFO probe answers in eng/native/tryrun.cmake.

Closed as not needed

Use the process temp directory for shared memory on OpenHarmony #132827 — shared-memory temp-directory change. Review established that the default (user-scoped) domain already works on OpenHarmony and that a global machine-wide mutex should throw; the change is not needed (the shared-mutex defaults were reworked in Fix shared mutex privliges/permissions/defaults to be secure #135778).

Next in the queue (rolling, 3–4 in flight)
N7 pal_process.c (close_range guard) · N10 crossgen-corelib.proj · N11/N12 AOT targets · N13 packs · N15 libraries TFM groups · N16 System.Console.csproj. Each branch is rebased onto the current main before submission. The granularity/sequence from the previous update is being followed as listed.

Open items

illink Microsoft.NET.ILLink.targets — its own tools/ PR, or folded into N12? If there is no preference, we will submit it as a separate tools/ PR after N12.
shims TFM cleanup — will follow N15's review: fold into N15 if requested, otherwise land immediately after.
S1c codesign — upstream or downstream (still open; the enforcement is HarmonyOS-commercial-only).

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

docs: record the dotnet#132866 progress comment (6285162682)

@am11

Consolidation question for the three open native PRs + remaining plan

Following @am11's batching guidance from #136132, the runtime port is now grouped as substantial batches: #136185 (NativeAOT + packs), #136186 (libraries TFM + console), #136187 (System.Native close_range).

Three earlier one-liners are still open and have not been reviewed yet:

native: use the C90 qsort workaround for zstd on OpenHarmony #135839 — native: use the C90 qsort workaround for zstd
native: skip gssapi on OpenHarmony and use the OpenSSL crypto shim #135840 — native: skip gssapi and use the OpenSSL crypto shim
System.Native: read the full ethtool speed on OpenHarmony #135866 — System.Native: read the full ethtool speed

Should these three be consolidated into one "native libs fixes" PR, or kept as they are? They are already open and focused; I am happy to close them and submit a single combined PR if that is preferred.

Remaining runtime work, for visibility:

Ready to submit next, in batches: the OpenSSL shim + NativeAOT static archive; optional AOT-ed SDK load-failure logging; the W^X write-barrier fallback.
CI leg: last, once the port is complete (it needs a prereqs image with the OpenHarmony NDK).

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

docs: dotnet#132866 consolidation question posted; SDK branches rebased

Following up on the codesign question from the September plan update (S1c in the SDK).

The signer — an MSBuild task that applies an ELF .codesign section to build and publish outputs, plus the targets hook and the resource strings — is currently kept downstream. A branch is ready (springmin/sdk-ohos pr/ohos-sdk-codesign) if you would like to review it upstream.

If there is no preference, we will keep S1c downstream and ship it in the fork's SDK packages. Please let us know.

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

docs: S1c branch cut and reviewer question posted

@am11

Progress update — native fixes reviewed, CI leg prepared

Merged

native: use the C90 qsort workaround for zstd on OpenHarmony #135839 — zstd C90 qsort workaround for OpenHarmony (2026-10-22).
OpenHarmony: NativeAOT and pack integration #136185 — NativeAOT and pack integration (2026-10-22).

Open and close to landing

native: OpenHarmony native library fixes #136194 — native libs fixes (process / interface addresses / CMakeLists / OpenSSL shim): CI is 100/100 green and @am11 approved. Per @jkotas, it still needs sign-off from @adamsitnik (pal_process.c) and @dotnet/ncl (pal_interfaceaddresses.c); both were pinged.
coreclr: check the GC barrier code page commit #136198 — s_barrierCopy commit check: approved by @janvorli, CI green, waiting for merge.
minipal: fail early when the double-mapping backing file cannot be made executable #136212 — W^X double-mapping pre-check: CI green, waiting for review.
CI: add an OpenHarmony arm64 build leg #136206 — OpenHarmony arm64 CI leg: it moves the leg to runtime-community.yml and runs the upstream setup-ohos-assets.sh. It waits for native: OpenHarmony native library fixes #136194 to land, then needs a runtime-community run (the PR author cannot queue it).

Validation

The fork CI runs the upstream setup script and the official subset clr.runtime+libs.native on upstream/main + feature/openharmony + #136206; build and verifier pass (run 39878384475).
feature/openharmony is synced to upstream/main (a99fb4b2a1b); the merge had a small conflict surface (11 files).
NativeAOT publish/run was verified on device (OpenHarmony 7.0.0.111, rc=0, IsOSPlatform(Linux/OpenHarmony)=true); the MSBuild IsUnixLike change (Perf: NonGeneric.HashTable default constructor 4x slower on Linux #15342) carries that evidence.

SDK follow-ups

The RID graph comes from Microsoft.NETCore.Platforms, so the SDK should not fork it; SDK-side changes are limited to the RID metadata that does not come from the runtime graph, after the corresponding packs are published.
The OpenHarmony ELF signer is proposed in Fix auto-atomicity for loops around required one/notone/set loops #56735, with a dotnet selfsign command for the force path; docs are in Add NETSDK1247-NETSDK1250 docs for OpenHarmony code signing docs#56529.

Next: the two area sign-offs for #136194, then a runtime-community run for #136206.

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

@springmin

@springmin I’m very interested in the work you’re doing. Would you be open to connecting further? You can find my email address on my profile. I was also previously a member of OpenHarmony-NET, where I helped maintain some of the toolchain.

Navigation Menu

Repository navigation

Add OpenHarmony (HarmonyOS) support to the .NET runtime #132866

Summary

Scope

Approach

Open questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add OpenHarmony (HarmonyOS) support to the .NET runtime #132866

Description

Summary

Scope

Approach

Open questions

Activity

dotnet-policy-service commented on Aug 27, 2026

huoyaoyuan commented on Aug 28, 2026

springmin commented on Sep 10, 2026

springmin commented on Sep 11, 2026

springmin commented on Sep 12, 2026

springmin commented on Sep 14, 2026

springmin commented on Oct 20, 2026

springmin commented on Oct 20, 2026

springmin commented on Oct 21, 2026

springmin commented on Oct 23, 2026

realybin commented on Oct 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions