Fix WASM workload detection for non-Blazor/WasmSdk Exe projects by DrewScoggins · Pull Request #52677 · dotnet/sdk

DrewScoggins · 2026-01-26T19:33:56Z

This fixes an issue where BenchmarkDotNet-generated WASM benchmark projects stopped working after commit 34e2468 removed the _UsingBlazorOrWasmSdk condition from _WasmNativeWorkloadNeeded.

The change in that commit was intended to allow library projects with RuntimeIdentifier=browser-wasm to build without requiring the WASM workload (per dotnet/runtime#122607). However, the change was too broad - it affected ALL non-Blazor/WasmSdk projects, including Exe projects that need the workload for runtime pack resolution.

This fix adds back the workload requirement specifically for Exe projects that don't use Blazor/WasmSdk, while preserving the library-mode-without-workload behavior.

Changes:

WorkloadManifest.targets.in: Added condition to set _WasmNativeWorkloadNeeded for Exe projects without BlazorOrWasmSdk
Added regression tests to verify:
- Exe projects trigger workload usage (UsingBrowserRuntimeWorkload=true)
- Library projects don't force workload usage
- Runtime pack version is available when workload is used
Added test asset WasmConsoleApp for the test scenarios

Fixes the 'MicrosoftNetCoreAppRuntimePackDir is empty' error in WASM benchmarks.

This fixes an issue where BenchmarkDotNet-generated WASM benchmark projects stopped working after commit 34e2468 removed the _UsingBlazorOrWasmSdk condition from _WasmNativeWorkloadNeeded. The change in that commit was intended to allow library projects with RuntimeIdentifier=browser-wasm to build without requiring the WASM workload (per dotnet/runtime#122607). However, the change was too broad - it affected ALL non-Blazor/WasmSdk projects, including Exe projects that need the workload for runtime pack resolution. This fix adds back the workload requirement specifically for Exe projects that don't use Blazor/WasmSdk, while preserving the library-mode-without-workload behavior. Changes: - WorkloadManifest.targets.in: Added condition to set _WasmNativeWorkloadNeeded for Exe projects without BlazorOrWasmSdk - Added regression tests to verify: - Exe projects trigger workload usage (UsingBrowserRuntimeWorkload=true) - Library projects don't force workload usage - Runtime pack version is available when workload is used - Added test asset WasmConsoleApp for the test scenarios Fixes the 'MicrosoftNetCoreAppRuntimePackDir is empty' error in WASM benchmarks.

DrewScoggins · 2026-01-26T19:40:05Z

This fix came out of discussion with Copilot. Let me know if the tests don't match up with what y'all do in this repo.

Copilot

Pull request overview

This PR fixes an issue where WASM workload detection was broken for non-Blazor/WasmSdk Exe projects (such as those generated by BenchmarkDotNet). The previous change that allowed library projects targeting browser-wasm to build without the workload inadvertently affected all non-Blazor/WasmSdk projects, including Exe projects that require the workload for runtime pack resolution.

Changes:

Added a condition to require the WASM workload for Exe projects that don't use Blazor/WasmSdk
Added comprehensive test coverage to verify workload behavior for both Exe and library projects
Added test asset files for WasmConsoleApp (though not used by the automated tests)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
WorkloadManifest.targets.in	Adds condition to set `_WasmNativeWorkloadNeeded=true` for Exe projects without Blazor/WasmSdk, preserving library-mode-without-workload behavior
WasmWorkloadDetectionTests.cs	New test class with three tests covering Exe workload requirement, library non-requirement, and runtime pack version availability
WasmConsoleApp/WasmConsoleApp.csproj	Test asset project file for WASM console app (not used in automated tests)
WasmConsoleApp/Program.cs	Test asset source file with simple console output (not used in automated tests)
WasmConsoleApp/main.js	Test asset JavaScript entry point (not used in automated tests, contains reference to non-existent Greeting method)

Copilot · 2026-01-26T19:43:57Z

test/Microsoft.NET.Build.Tests/WasmWorkloadDetectionTests.cs

+{
+    /// <summary>
+    /// Tests for WASM workload detection with projects using Microsoft.NET.Sdk (not Blazor/WebAssembly SDK).
+    /// These tests verify the fix for https://github.com/dotnet/sdk/issues/XXXXX where BenchmarkDotNet


The placeholder issue number "XXXXX" should be replaced with the actual GitHub issue number.

Suggested change

/// These tests verify the fix for https://github.com/dotnet/sdk/issues/XXXXX where BenchmarkDotNet

/// These tests verify the fix for a bug where BenchmarkDotNet

DrewScoggins · 2026-01-26T23:12:11Z

Just to be clear, this is currently blocking our ability to collect performance results on WASM.

pavelsavara · 2026-01-27T18:09:15Z

...Manifests/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in

+    <!-- Exe projects targeting browser-wasm without Blazor/WasmSdk need the workload for runtime pack resolution.
+         This ensures tools like BenchmarkDotNet that generate WASM console apps work correctly.
+         Library projects can build without the workload (they don't need AppBundle generation). -->
+    <_WasmNativeWorkloadNeeded Condition="'$(_UsingBlazorOrWasmSdk)' != 'true' and '$(OutputType)' == 'Exe'">true</_WasmNativeWorkloadNeeded>


Please add and '$(_WasmNativeWorkloadNeeded)' == ''

pavelsavara · 2026-01-27T18:11:17Z

@maraf has this in progress dotnet/runtime#122607 I wonder if it's the solution for the same or similar problem

pavelsavara · 2026-01-27T18:13:51Z

Also much more localized solution could be to add <WasmBuildNative>true</WasmBuildNative> into the benchmark project.

Edit: hmm, it's already there

https://github.com/dotnet/performance/blob/43d3453263242e0d0a2adb8a70cac45184cba836/src/benchmarks/micro/MicroBenchmarks.Wasm.props#L7

pavelsavara · 2026-01-27T19:17:30Z

https://github.com/dotnet/performance/blob/43d3453263242e0d0a2adb8a70cac45184cba836/src/benchmarks/micro/MicroBenchmarks.Wasm.props#L7

https://github.com/dotnet/BenchmarkDotNet/blob/9612c51ad512acbdfd3f989d50b40ee46a395028/src/BenchmarkDotNet/Templates/WasmCsProj.txt#L4-L5

I wonder if that file is ever imported ...

It should be https://github.com/dotnet/BenchmarkDotNet/blob/9612c51ad512acbdfd3f989d50b40ee46a395028/src/BenchmarkDotNet/Templates/WasmCsProj.txt#L10

pavelsavara · 2026-01-27T19:45:55Z

Looking at Log and Binlog

[2026/01/27 08:20:35][INFO] .NET workloads installed:
[2026/01/27 08:20:35][INFO]  [wasm-tools]
[2026/01/27 08:20:35][INFO]    Installation Source: SDK 11.0.100-alpha.1
[2026/01/27 08:20:35][INFO]    Manifest Version:    11.0.0-ci/11.0.100-alpha.1
[2026/01/27 08:20:35][INFO]    Manifest Path:       /home/helixbot/work/BFC309E4/p/dotnet/sdk-manifests/11.0.100-alpha.1/microsoft.net.workload.mono.toolchain.current/WorkloadManifest.json
[2026/01/27 08:20:35][INFO]    Install Type:        FileBased
[2026/01/27 08:20:35][INFO] 
[2026/01/27 08:20:35][INFO]  [wasm-experimental]
[2026/01/27 08:20:35][INFO]    Installation Source: SDK 11.0.100-alpha.1
[2026/01/27 08:20:35][INFO]    Manifest Version:    11.0.0-ci/11.0.100-alpha.1
[2026/01/27 08:20:35][INFO]    Manifest Path:       /home/helixbot/work/BFC309E4/p/dotnet/sdk-manifests/11.0.100-alpha.1/microsoft.net.workload.mono.toolchain.current/WorkloadManifest.json
[2026/01/27 08:20:35][INFO]    Install Type:        FileBased

[2026/01/27 08:21:12][INFO]   Optimizing assemblies for size. This process might take a while.
[2026/01/27 08:21:21][INFO] /home/helixbot/work/BFC309E4/p/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/11.0.0-ci/Sdk/ILLink.Substitutions.WasmIntrinsics.xml(2,4): warning IL2007: Could not resolve assembly 'System.Private.CoreLib'. [/home/helixbot/work/BFC309E4/w/B2F20A0A/e/performance/artifacts/bin/for-running/MicroBenchmarks/MicroBenchmarks-Wasm-1/BenchmarkDotNet.Autogenerated.csproj::TargetFramework=net11.0]
[2026/01/27 08:21:21][INFO] /home/helixbot/work/BFC309E4/w/B2F20A0A/e/performance/src/benchmarks/micro/ILLink.Descriptors.Serialization.xml(2,4): 
warning IL2007: Could not resolve assembly 'System.Private.DataContractSerialization'. [/home/helixbot/work/BFC309E4/w/B2F20A0A/e/performance/artifacts/bin/for-running/MicroBenchmarks/MicroBenchmarks-Wasm-1/BenchmarkDotNet.Autogenerated.csproj::TargetFramework=net11.0]

[2026/01/27 08:21:36][INFO] /home/helixbot/work/BFC309E4/p/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/11.0.0-ci/Sdk/WasmApp.Common.targets(286,5): 
error : $(MicrosoftNetCoreAppRuntimePackDir)='', and cannot find %(ResolvedRuntimePack.PackageDirectory)=. 
One of these need to be set to a valid path 
[/home/helixbot/work/BFC309E4/w/B2F20A0A/e/performance/artifacts/bin/for-running/MicroBenchmarks/MicroBenchmarks-Wasm-1/BenchmarkDotNet.Autogenerated.csproj::TargetFramework=net11.0]
[2026/01/27 08:21:36][INFO] Build FAILED.

pavelsavara · 2026-01-27T20:30:54Z

pavelsavara · 2026-01-27T20:41:26Z

So far I think this is about missing runtime pack.

WasmApp.Common.targets(286,5): error : $(MicrosoftNetCoreAppRuntimePackDir)='', and cannot find %(ResolvedRuntimePack.PackageDirectory)

Probably nuget of the right version is not yet in the right feed ?

lewing · 2026-02-03T21:03:32Z

So far I think this is about missing runtime pack.

WasmApp.Common.targets(286,5): error : $(MicrosoftNetCoreAppRuntimePackDir)='', and cannot find %(ResolvedRuntimePack.PackageDirectory)

Probably nuget of the right version is not yet in the right feed ?

is this just becase UseMonoRuntime isn't set?

maraf · 2026-02-09T11:02:55Z

is this just becase UseMonoRuntime isn't set?

The problem is that dotnet/perf doesn't use WasmSDK and we don't have the former bundler anymore. WIP in dotnet/performance#5101

Copilot AI review requested due to automatic review settings January 26, 2026 19:33

github-actions bot added the Area-Workloads label Jan 26, 2026

Copilot started reviewing on behalf of DrewScoggins January 26, 2026 19:34 View session

DrewScoggins requested review from akoeplinger, javiercn, lewing and maraf January 26, 2026 19:38

Copilot AI reviewed Jan 26, 2026

View reviewed changes

pavelsavara reviewed Jan 27, 2026

View reviewed changes

ilonatommy mentioned this pull request Feb 2, 2026

[wasm] Bump chrome for testing - linux: 144.0.7559.109, windows: 145.0.7632.26 dotnet/runtime#123847

Open

Merge branch 'main' into fix/wasm-workload-detection-exe-projects

b49e04e

	/// These tests verify the fix for https://github.com/dotnet/sdk/issues/XXXXX where BenchmarkDotNet
	/// These tests verify the fix for a bug where BenchmarkDotNet

Conversation

DrewScoggins commented Jan 26, 2026

Uh oh!

DrewScoggins commented Jan 26, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

DrewScoggins commented Jan 26, 2026

Uh oh!

pavelsavara Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

pavelsavara commented Jan 27, 2026

Uh oh!

pavelsavara commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pavelsavara commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pavelsavara commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pavelsavara commented Jan 27, 2026

Uh oh!

pavelsavara commented Jan 27, 2026

Uh oh!

lewing commented Feb 3, 2026

Uh oh!

maraf commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

pavelsavara commented Jan 27, 2026 •

edited

Loading

pavelsavara commented Jan 27, 2026 •

edited

Loading

pavelsavara commented Jan 27, 2026 •

edited

Loading

maraf commented Feb 9, 2026 •

edited

Loading