WASM benchmark uses WebAssembly SDK and supports CoreClr runtime

[ilonatommy]

Should be merged together with dotnet/BenchmarkDotNet#2998.

[maraf]

We should migrate away from using test-main.js in this repository. That file is intended for unit tests in runtime repository.
Instead let's introduce a new file, in BDN, that will be tailored for running MicroBenchmarks.

Some of the configurations from this repository should probably be part of the BDN template as well

• Generating V8 script. Are we still using it to run benchmarks?

  performance/src/benchmarks/micro/MicroBenchmarks.Wasm.props

  Line 3 in f812c96

  <WasmGenerateRunV8Script>true</WasmGenerateRunV8Script>

• PublishTrimmed=true is default for wasm

  performance/src/benchmarks/micro/MicroBenchmarks.Wasm.targets

  Line 11 in f812c96

  <PublishTrimmed>true</PublishTrimmed>

• MainJS validation

  performance/src/benchmarks/micro/MicroBenchmarks.Wasm.targets

  Lines 28 to 30 in f812c96

  	<Target Name="Validate" BeforeTargets="Build">
  	<Error Text="Cannot find WasmMainJSPath: $(WasmMainJSPath)" Condition="'$(WasmMainJSPath)' == '' or !Exists('$(WasmMainJSPath)')" />
  	</Target>

Are these VFS items applied correctly

performance/src/benchmarks/micro/MicroBenchmarks.Wasm.targets

Line 24 in f812c96

<WasmFilesToIncludeInFileSystem Include="@(_LibrariesFile)" TargetPath="libraries\%(RecursiveDir)%(FileName)%(Extension)" />

?

[ilonatommy]

/ba-g failures not connected

[ilonatommy]

/ba-g failures not connected

[LoopedBard3]

Taking a look at this, hoping to have an update later today that completes some of the other cleanup things to merge this (updating BDN version we use, fixing some errors, etc).

[LoopedBard3]

I am still working on some of the finishing touches and one issue we are hitting on the wasm wasm runs. I have put up a draft PR here: #5123 with the test run through the 'Setup Testing' commit available here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2907458&view=results. The test run ran wasm aot successfully but the Wasm Wasm test run hit the following issue when attempting to run the benchmark:

[2026/02/18 14:34:08][INFO] // Benchmark: Perf_Boolean.TryParse: Wasm(Runtime=Wasm, Toolchain=Wasm, IterationTime=250ms, MaxIterationCount=20, MinIterationCount=15, WarmupCount=1) [value= True ]
[2026/02/18 14:34:08][INFO] // *** Execute ***
[2026/02/18 14:34:08][INFO] // Launch: 1 / 1
[2026/02/18 14:34:08][INFO] Executable /home/helixbot/work/AB5F093E/w/9FF608B7/e/performance/artifacts/bin/for-running/MicroBenchmarks/MicroBenchmarks-Wasm-1/bin/Release/net11.0/browser-wasm/wwwroot/benchmark-main.mjs not found
[2026/02/18 14:34:08][INFO] ExitCode != 0 and no results reported
[2026/02/18 14:34:08][INFO] No Workload Results were obtained from the run.

Here is the summarization of my current investigation to solve this:

Summary of changes and remaining issue for PR

Changes made (performance repo side)

1. scripts/run_performance_job.py — Wire --wasm-coreclr through to benchmarks_ci.py. When runtimeType=wasm and codeGenType=wasm (non-AOT), the --wasm-coreclr flag is
   passed to benchmarks_ci.py → micro_benchmarks.py → BDN's --wasmCoreCLR.
2. scripts/build_runtime_payload.py — Remove test-main.js requirement (BDN handles it now). Also install the CoreCLR browser-wasm runtime pack from
   staging/microsoft.netcore.app.runtime.browser-wasm/Release/ into dotnet/packs/Microsoft.NETCore.App.Runtime.browser-wasm// so the SDK can resolve it.
3. src/scenarios/build-common/WasmOverridePacks.targets — Made pack resolution conditional: when UseMonoRuntime=true (set by Microsoft.NET.Sdk.WebAssembly), use
   Microsoft.NETCore.App.Runtime.Mono.browser-wasm; otherwise (CoreCLR / Microsoft.NET.Sdk), use Microsoft.NETCore.App.Runtime.browser-wasm.
4. src/Directory.Build.props — Suppress CS9057 (Roslyn analyzer version mismatch) since the BDN
   0.16.0-custom analyzer targets Roslyn 5.0.0.0 which is newer than what .NET 9.0 SDK ships.

Remaining issue: benchmark-main.mjs not found

The WASM AOT runs (codeGenType: 'aot') succeed because they use Microsoft.NET.Sdk.WebAssembly, which provides the full WASM build pipeline (WasmBuildApp, StaticWebAssets,
etc.). These targets handle wwwroot/ content and produce a working WASM bundle in the publish output.

The non-AOT CoreCLR runs (codeGenType: 'wasm' with --wasm-coreclr) fail because BDN's WasmGenerator switches the SDK from Microsoft.NET.Sdk.WebAssembly to
Microsoft.NET.Sdk when IsMonoRuntime=false (WasmGenerator.cs line 50):

string sdkName = runtime.IsMonoRuntime ? "Microsoft.NET.Sdk.WebAssembly" : "Microsoft.NET.Sdk";

Without Microsoft.NET.Sdk.WebAssembly:

• The StaticWebAssets SDK isn't imported, so wwwroot/ content isn't processed during publish
• The WasmBuildApp target from the Mono WASM workload doesn't activate (it depends on UseMonoRuntime=true)
• The result is that dotnet publish produces a regular managed app output without a WASM bundle, and wwwroot/benchmark-main.mjs doesn't appear in the publish directory

This likely needs a BDN fix: the CoreCLR WASM path probably still needs Microsoft.NET.Sdk.WebAssembly as the SDK (which handles the build pipeline), but with
UseMonoRuntime=false set explicitly to select the CoreCLR runtime pack instead of Mono. The Microsoft.NET.Sdk.WebAssembly SDK doesn't force Mono — it's the UseMonoRuntime
property that controls which runtime pack is resolved. So the fix in BDN might be as simple as using Microsoft.NET.Sdk.WebAssembly for both cases and setting
false when IsMonoRuntime=false.

/end summarization

If y'all have any ideas on what the cause may be the help would be appreciated, otherwise I plan on attempting to repro this locally tomorrow to verify that the wwwroot is not being published at all and further investigate.

[maraf]

the CoreCLR WASM path probably still needs Microsoft.NET.Sdk.WebAssembly as the SDK

Yes