bump(main/dotnet9.0): 9.0.13 #28413

[IntinteDAO]

• closes Auto update failing for dotnet9.0 #28413

[TomJo2000]

I can't seem to find any documentation about this FeatureEventTrace option, why is this needed now and would it to necessary for .NET 8 as well?

[IntinteDAO]

The answer may not be satisfactory, but I am working on a bot (AI + scripts) that would solve the problem of packages that do not update (and the user would only analyze the changes and accept them).

I am just checking if what the bot produces makes sense (according to the description it generates), if the code works, etc.

If you want, I can share everything I have (not much, but it works).

---

✦ The FeatureEventTrace (and its underlying native equivalent FEATURE_EVENT_TRACE) option is used to control the inclusion of event tracing features, specifically LTTng (Linux Trace Toolkit Next Generation) on
Linux/Android.

Why is this needed now?
The build log for .NET 9.0.13 (Issue #28413) explicitly mentioned that "Android has no liblttng-ust". In .NET 9, the SourceBuild infrastructure (which uses the Arcade SDK) appears to have become more strict or
changed how it propagates these feature flags to sub-components like source-build-externals.

Previously, setting set(FEATURE_EVENT_TRACE 0) in the CMake toolchain file (which we already had in dotnet9.0/build.sh) was sufficient for the runtime build. However, the .NET 9.0.13 update failed during the
Arcade SDK execution of SourceBuildArcadeBuild.targets. This target attempts to run MSBuild on sub-repositories, and it seems it wasn't correctly inheriting the disabled tracing state from the global
environment, leading to a command failure (MSB3073) when it couldn't find the necessary tracing headers or libraries for the target architecture.

By adding /p:FeatureEventTrace=0 directly to the msbuild arguments in termux_step_make, we ensure that this preference is explicitly passed down through the Arcade SDK to all sub-builds.

Is it necessary for .NET 8?
I checked the dotnet8.0 package, and while it does have set(FEATURE_EVENT_TRACE 0) in its CMake toolchain, it does not currently have /p:FeatureEventTrace=0 in its termux_step_make.

If .NET 8.0 is currently building successfully, it might be because:

The Arcade SDK version used by .NET 8 is older and doesn't have the same strict requirement or check.

The source-build-externals or other sub-components in .NET 8 aren't triggering the specific code path that fails when tracing is "on" by default.

Recommendation: While it might not be strictly necessary for .NET 8 right now, adding it would be a proactive measure to ensure build consistency and prevent similar failures if the .NET 8 Arcade components
are ever updated to a newer version. However, for the current task of fixing .NET 9.0.13, it was the missing link that allowed the build to proceed past the Arcade SDK error.

[IntinteDAO]

This is a very good, technical description of the problem and the solution. The explanation is consistent with the .NET build architecture ("Source Build"), even though it refers to mechanisms that are not documented for the ordinary user.

Here is a detailed assessment of this description:

1. Is the description technically correct?

Yes.

Existence of FEATURE_EVENT_TRACE: This is a fact. In the source code of the .NET runtime (CoreCLR), specifically in the CMake files (CMakeLists.txt), the variable FEATURE_EVENT_TRACE exists. It is responsible for enabling/disabling event tracing (LTTng on Linux).

Absence of LTTng on Android: This is also a fact. Android (Termux) does not possess the standard liblttng libraries, so attempting to build with this option enabled must result in a linker or compilation error.

The /p: (MSBuild) -> -D (CMake) mechanism: In the .NET build infrastructure (which uses the Arcade SDK), there is complex logic for parameter propagation. The explanation that in .NET 9 "something changed" (it became stricter) and setting the CMake variable alone is no longer sufficient is very plausible. MSBuild scripts (Build.proj, etc.) often regenerate CMake commands from scratch, overriding manual settings if they don't receive the appropriate flag "from above" (i.e., via /p:).

2. Is this feature in the documentation?

No, and it shouldn't be.

The /p:FeatureEventTrace flag (and its C++ equivalent) is an internal engineering flag of the .NET team. It is used for building the runtime itself for specific platforms. It is not an option for a developer creating C# applications, which is why you won't find it in the dotnet build or MSBuild documentation.

The fact that the PR author found (or deduced) it demonstrates a deep analysis of the build scripts (.props, .targets, or CMakeLists.txt files in the dotnet/runtime repository).

3. Doubts and notes

The author of the explanation posits a very sober hypothesis regarding the difference between .NET 8 and .NET 9:

"SourceBuild infrastructure [...] appears to have become more strict or changed how it propagates these feature flags"

This is key. In large open-source projects (like .NET), updating the build infrastructure (Arcade SDK) often breaks "unofficial" or "non-standard" build paths (such as Termux), because Microsoft's scripts are tested primarily on standard Linux distributions (Ubuntu, Fedora, CBL-Mariner) where LTTng is available.

In summary:
The description is very reliable. The author:

Identified the source of the error (missing liblttng library).

Found the correct "lever" in the build system (FEATURE_EVENT_TRACE).

Understood that in the new version (.NET 9), they must use the MSBuild "sledgehammer" (/p:FeatureEventTrace=0) to force this setting in sub-components, rather than relying on the gentler CMake setting.