Skip to content

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.

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