Trim STAThreadAttribute in single-threaded (browser/wasi) Mono apps

[Copilot]

main PR

Description

System.STAThreadAttribute was unnecessarily retained in trimmed single-threaded Mono apps (browser/WASI).

This PR now addresses both sides of the behavior:

• src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml keeps System.STAThreadAttribute rooted only when System.Runtime.CompilerServices.RuntimeFeature.IsMultithreadingSupported is true.
• src/mono/mono/metadata/object.c was updated to tolerate the attribute type being absent by using a try-load path when checking for [STAThread] on entrypoint methods.

This preserves existing behavior on multithreaded Mono platforms while allowing single-threaded browser/WASI apps to trim the attribute safely.

Customer Impact

Without this fix, trimmed single-threaded Mono apps can retain unnecessary metadata, and WASI startup could fail when the attribute is trimmed.

Regression

No known product regression is introduced. The native startup path now handles missing System.STAThreadAttribute gracefully instead of assuming it is always present.

Testing

• Baseline build: ./build.sh mono+libs
• Targeted runtime build: ./build.sh mono.runtime -c Release
• Targeted WASI/Mono build: ./build.sh -os wasi -subset mono+libs -c Debug
• Parallel validation (code review + security scan) completed.

Risk

Low to medium. The change is narrowly scoped to STA attribute lookup in Mono startup and linker rooting configuration. Multithreaded platforms continue to root the type; single-threaded platforms can trim it, and runtime lookup now safely handles absence.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[MichalStrehovsky]

How are we ending up needing these attribute in the first place? When I make a new console app (on Windows even!), and PublishTrimmed the app, this attribute trims just fine. Does Blazor place the attribute on Main for some reason? Or roots some other code that needs it? I think this is the core part that should be addressed.

[pavelsavara]

How are we ending up needing these attribute in the first place?

Great question, thanks

<type fullname="System.STAThreadAttribute" /> in

https://github.com/dotnet/runtime/blame/0ded4d28b4990cc4bdb6f1e44bafca3f22aa6eda/src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml#L338

@copilot removing root cause is better alternative. Investigate if this type rooting is still necessary on other Mono/mobile platforms. If not, remove it from ILLink.Descriptors.xml

If it's still need, make it only explicitly used for those (MT) Mono platforms.

[Copilot]

How are we ending up needing these attribute in the first place? When I make a new console app (on Windows even!), and PublishTrimmed the app, this attribute trims just fine. Does Blazor place the att...

Good catch — the attribute trims fine on CoreCLR because nothing roots it. On Mono it's the descriptor that keeps it alive: src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml unconditionally roots System.STAThreadAttribute because the native runtime (object.c: prepare_thread_to_exec_main) looks it up via mono_class_load_from_name (which aborts if the type is missing) to set apartment state when launching an entry point through mono_runtime_run_main. Blazor WASM doesn't reach that path (the entry point is invoked directly), so the root was pure dead weight there. I've switched to fixing the root cause — see the updated commit.

Note

This comment was generated by GitHub Copilot.

How are we ending up needing these attribute in the first place?

Great question, thanks
...

Done in the latest commit. I confirmed the root is still needed on multithreaded Mono platforms (desktop/iOS/Android launch the entry point via mono_runtime_run_main → prepare_thread_to_exec_main, which calls mono_class_load_from_name for System.STAThreadAttribute and aborts if it's missing). Browser/wasi invoke the entry point directly and never hit that path, and apartment state is meaningless there.

So rather than removing the root outright, I gated it in ILLink.Descriptors.xml on System.Runtime.CompilerServices.RuntimeFeature.IsMultithreadingSupported (featurevalue="true" featuredefault="true") — kept for MT platforms, trimmed on single-threaded browser/wasi where that switch is false. I also reverted the earlier ILLink.LinkAttributes.Shared.xml change in favor of this root-cause fix.

Note

This comment was generated by GitHub Copilot.

[pavelsavara]

/ba-g CI failure is #130618

[Copilot]

Pull request overview

This PR attempts to reduce trimming roots for Mono single-threaded WebAssembly targets by making System.STAThreadAttribute no longer unconditionally rooted in Mono’s ILLink descriptors, instead gating its retention on RuntimeFeature.IsMultithreadingSupported.

Changes:

• Removes the unconditional System.STAThreadAttribute root from the main System.Private.CoreLib descriptor list.
• Re-adds System.STAThreadAttribute as a feature-gated root conditioned on System.Runtime.CompilerServices.RuntimeFeature.IsMultithreadingSupported == true.

[MichalStrehovsky]

If the runtime tolerates it now, why keep it?