[akoeplinger]

Fix XUnitLogChecker publishing in the CoreCLR Linux Bionic lane enabled by #137338.

The checker inherits UseAppHost=false from the runtime test projects, but its non-NativeAOT publish mode enables trimming and single-file publishing. The SDK consequently infers a self-contained application and fails with NETSDK1067. Enable the apphost locally when the checker selects single-file publishing, leaving NativeAOT and explicit framework-dependent publishing unchanged. No platform support guards or test coverage are disabled.

Validation:

• Reproduced NETSDK1067 before the fix for Bionic x64 and arm64.
• Published the fixed checker for linux-bionic-x64 and linux-bionic-arm64; verified both ELF outputs use /system/bin/linker64.
• Published and ran macOS arm64 single-file and NativeAOT checker binaries successfully.
• Checked 12 before/after configurations covering both Bionic architectures, desktop single-file, NativeAOT, framework-dependent publishing, and Android/browser/WASI/iOS/Mono exclusions.

Local validation used the installed SDK 12.0.100-alpha.1.26516.101, allowed by global.json roll-forward, rather than CI's pinned SDK. Bionic binaries were not executed on the macOS host, and the full runtime pipeline was not run locally.

Note

This pull request description and code change were generated with GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[am11]

@akoeplinger, just curious, why don't we use PublishAot on linux-bionic? given it isn't listed as unsupported OS

runtime/eng/common/native/NativeAotSupported.props

Line 5 in d990730

<_NativeAotSupportedOS Condition="

If linux-musl-loongarch64, openbsd-x64 type of community platforms even publish it with AOT, linux-bionic-arm64 sounds it should too.

[akoeplinger]

@am11 good question, I haven't looked deeper into it, feel free to do if you want. I'll merge this to unblock the pipeline.

[MichalStrehovsky]

@akoeplinger, just curious, why don't we use PublishAot on linux-bionic? given it isn't listed as unsupported OS

runtime/eng/common/native/NativeAotSupported.props

Line 5 in d990730

<_NativeAotSupportedOS Condition="

If linux-musl-loongarch64, openbsd-x64 type of community platforms even publish it with AOT, linux-bionic-arm64 sounds it should too.

It's excluded elsewhere: I gave that a try in #137386, but it couldn't find runtime pack or something like that.

[am11]

it couldn't find runtime pack

The platform, for which we don't have MSFT's published runtime-packs, should be considered a community platform: #136770 (IsOfficial=false); and we use --bootstrap build in the CI for those platforms.

Also, in another thread #106748 (comment), we were questioning keeping linux-bionic in addition to android is necessary. Unlike linux-musl multiple distros, bionic libc is only used by Android so libc abstraction doesn't make much sense for 1:1 relationship. For our purposes, bionic libc == Android with !FeatureGooglePlayIntegration (which could just be a (trimable) feature switch).

[MichalStrehovsky]

The platform, for which we don't have MSFT's published runtime-packs, should be considered a community platform: #136770 (IsOfficial=false); and we use --bootstrap build in the CI for those platforms.

We do build it and officially support it (I guess the official support status is still "experimental"): https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.NativeAOT.linux-bionic-arm64. This is some infra misconfiguration.

[akoeplinger]

@am11 yes there is demand for linux-bionic, see #137361

[am11]

@akoeplinger, I was questioning the RID justification: why do we need linux-bionic AND android? They have a 1:1 relationship. We removed all "distro" support in .NET 8 because it was a never-ending story (https://distrowatch.com suggests there are 600+ active Linux distros). In the case of linux-bionic and android, android is the distro, but we need it comparable to ios, making linux-bionic the odd one out. That is, if you have an android-arm64 NuGet package instead of linux-bionic-arm64, the RID resolver should work because the consumer project is also android-arm64; there is no other desktop or mobile distro that uses bionic libc (even OpenHarmony uses a custom variant of musl libc).