[pavelsavara]

Summary

• split Browser CoreCLR EventPipe into symbol-compatible enabled and disabled static components
• prelink and package production (EventPipe disabled) and diagnostics (EventPipe enabled) native asset sets
• select the matching prelink without requiring wasm-tools, while preserving the existing workload-installed native relink path
• default builds to diagnostics and publishes to production, with explicit EnableDiagnostics taking precedence
• add end-to-end coverage for prelink selection and EventPipe trace collection

The common VM remains layout-compatible by keeping FEATURE_PERFTRACING enabled. Browser builds move EventPipe and diagnostic-server operations behind an out-of-line adapter contract, then link exactly one of libeventpipe-enabled.a or libeventpipe-disabled.a. Non-Browser CoreCLR targets retain their existing inline path.

The production native asset set remains in the normal runtime-pack location. The diagnostics alternative is packaged under data/native-flavors/diagnostics, avoiding duplicate NuGet runtime-asset basenames.

Release size

Asset	Production	Diagnostics	Delta
dotnet.native.wasm raw	4,425,205 B	4,579,015 B	+153,810 B (+3.48%)
dotnet.native.wasm Brotli	1,294,316 B	1,331,615 B	+37,299 B (+2.88%)
Native asset trio raw	5,190,008 B	5,357,841 B	+167,833 B (+3.23%)
Native asset trio Brotli	1,422,229 B	1,462,263 B	+40,034 B (+2.81%)

Shipping the diagnostics trio and enabled component in addition to production adds 7,886,855 raw bytes, or 2,934,854 bytes after nupkg compression.

Validation

Passed on the exact merged PR head:

• .\build.cmd -bl -os browser -subset clr+libs+host -c Debug /p:RuntimeFlavor=CoreCLR /p:EnableHotReloadInRuntimeConfigDevFile=false — 0 warnings, 0 errors
• .\build.cmd -bl -os browser -subset clr+libs+host -c Release /p:RuntimeFlavor=CoreCLR /p:EnableHotReloadInRuntimeConfigDevFile=false — 0 warnings, 0 errors
• .\artifacts\bin\dotnet-none\dotnet.exe build -bl:artifacts\draft-pr-selection-tests-3.binlog -p:TargetOS=browser -p:TargetArchitecture=wasm -p:RuntimeFlavor=CoreCLR -c Debug -t:Test .\src\mono\wasm\Wasm.Build.Tests\ -p:InstallWorkloadForTesting=false -p:TestUsingWorkloads=false -p:InstallChromeForTests=false -p:XUnitMethodName=Wasm.Build.Tests.Blazor.WorkloadRequiredTests.CoreClrPrelinkedNativeFlavorIsSelectedWithoutWorkload — 4 passed in Chrome, 0 failed, 0 skipped
• .\artifacts\bin\dotnet-none\dotnet.exe build -bl:artifacts\draft-pr-eventpipe-tests.binlog -p:TargetOS=browser -p:TargetArchitecture=wasm -p:RuntimeFlavor=CoreCLR -c Debug -t:Test .\src\mono\wasm\Wasm.Build.Tests\ -p:InstallWorkloadForTesting=false -p:TestUsingWorkloads=false -p:InstallChromeForTests=false -p:XUnitMethodName=Wasm.Build.Tests.Blazor.EventPipeDiagnosticsTests.BlazorEventPipeTestWithCpuSamplesPrelinked — Debug and Release cases passed in Chrome, 0 failed, 0 skipped
• Windows x64 desktop CoreCLR runtime build — 0 warnings, 0 errors
• git diff --check and Python generator syntax validation

Follow-ups

• A full development flavor remains blocked on Browser debugger bring-up (InitializeDebugger and CorDBGetInterface).
• App-specific native callbacks and reverse P/Invokes still require native relinking; framework-only prelinks cannot contain signatures known only from the application closure.

Part of #132772

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
11 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[jkoritzinsky]

As part of this, would it be reasonable to re-trim System.Private.CoreLib with the corresponding feature flags set (ie if there's no EventPipe, all EventSource logic is no-op, similar for debugger) so we can regenerate the QCall/FCall/Runtime-entrypoint table and trim out more native code?

[jkotas]

Should this use the documented EventSourceSupport? https://github.com/dotnet/docs/blob/main/docs/core/deploying/trimming/trimming-options.md#trim-framework-library-features

IIRC, we have tried to implement more fine-grained controls for different parts of tracing infrastructure, but it was messy UX - difficult to explain what works in different combinations, so we ended up folding everything together under EventSourceSupport.

[pavelsavara]

BlazorWebAssemblyDiagnosticsEnabled, MetricsSupport, EventSourceSupport and HttpActivityPropagationSupport default was changed to true for WASM recently.

dotnet/sdk#55447
dotnet/sdk#55537

We can still revert that for Net11 in the last moments. I would love to.