Skip to content

Comments

[browser] Library mode without workload#122607

Draft
maraf wants to merge 9 commits intomainfrom
maraf/BrowserLibraryModeNoWorkload
Draft

[browser] Library mode without workload#122607
maraf wants to merge 9 commits intomainfrom
maraf/BrowserLibraryModeNoWorkload

Conversation

@maraf
Copy link
Member

@maraf maraf commented Dec 17, 2025

Building OutputType=library as WebAssembly application doesn't need a workload to be installed.
This PR moves the target that configures ILLink from workload to Wasm SDK.

@maraf maraf added this to the 11.0.0 milestone Dec 17, 2025
@maraf maraf self-assigned this Dec 17, 2025
@maraf maraf added arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm labels Dec 17, 2025
@maraf
Copy link
Member Author

maraf commented Dec 17, 2025

@copilot This test variantWasm.Build.Tests.WasmTemplateTests.LibraryMode(useWasmSdk: False, isPublish: True) is expected to fail the build. Update the test to check that the publish finishes with exit code 1

This comment was marked as resolved.

Copilot AI and others added 3 commits December 17, 2025 20:50
)

# Description

The `LibraryMode` test variant with `useWasmSdk: False, isPublish: True`
is expected to fail, but the test was asserting success for all
variants.

Updated test to set `ExpectSuccess: false` when publishing without WASM
SDK, verifying the operation exits with code 1 as expected.

```csharp
// Publishing without WASM SDK is expected to fail
bool expectSuccess = useWasmSdk || !isPublish;
if (isPublish)
    PublishProject(info, config, new PublishOptions(AssertAppBundle: useWasmSdk, ExpectSuccess: expectSuccess));
else
    BuildProject(info, config, new BuildOptions(AssertAppBundle: useWasmSdk, ExpectSuccess: expectSuccess));
```

# Customer Impact

No customer impact - test-only change.

# Regression

No. Test was incomplete, not validating the expected failure scenario.

# Testing

Test compiles successfully. The updated test will properly validate all
four variants:
- Build without SDK: succeeds
- Build with SDK: succeeds  
- Publish with SDK: succeeds
- Publish without SDK: **fails** (now correctly validated)

# Risk

Minimal - test-only change with no production code impact.

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for
you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: maraf <10020471+maraf@users.noreply.github.com>
@maraf
Copy link
Member Author

maraf commented Dec 18, 2025

The problem is when a library has RuntimeIdentifier=browser-wasm, but it doesn't import WasmSDK, we trigger the requirement for workload. It doesn't sound correct. Previously it might have make sense, because we triggered WasmAppBundler just by RID.

DrewScoggins added a commit to DrewScoggins/sdk that referenced this pull request Jan 26, 2026
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.
@dotnet-policy-service dotnet-policy-service bot removed this from the 11.0.0 milestone Feb 19, 2026
@dotnet-policy-service
Copy link
Contributor

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

@maraf maraf reopened this Feb 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants