Skip to content

Fix running in browser wasm#7146

Merged
Evangelink merged 1 commit into
mainfrom
dev/amauryleve/fix-browser-wasm
Dec 17, 2025
Merged

Fix running in browser wasm#7146
Evangelink merged 1 commit into
mainfrom
dev/amauryleve/fix-browser-wasm

Conversation

@Evangelink
Copy link
Copy Markdown
Member

Contributes to #2196.

I have manually validated things are working with the fix:

image

I'll try to work on adding some acceptance test in a follow-up PR.

@Evangelink Evangelink enabled auto-merge (squash) December 17, 2025 13:17
@Evangelink Evangelink merged commit e183a03 into main Dec 17, 2025
11 checks passed
@Evangelink Evangelink deleted the dev/amauryleve/fix-browser-wasm branch December 17, 2025 15:02
if (processPath is null)
{
// Fallback for environments where ProcessPath is null (e.g., browser OS)
string[] commandLineArgs = environment.GetCommandLineArgs();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't GetCommandLineArgs return empty array on browser?

Evangelink added a commit that referenced this pull request May 25, 2026
After PRs #7137 and #7146, Microsoft.Testing.Platform boots on the
wasi-wasm runtime, but the sample wouldn't even produce a `dotnet.wasm`
bundle out of the box on the current preview SDK (`11.0.100-preview.5`):

* `WorkloadManifest.Wasi.targets` only resolves
  `$(UsingWasiRuntimeWorkload)` to `true` when `$(TargetsCurrent)`
  (net11.0) is true, never when `$(TargetsNet10)` is true, so the WASI
  Sdk targets are never imported.
* The pre-built `dotnet.wasm` tries to read `icudt.dat` from `cwd` even
  when `InvariantGlobalization` is on, so trimmed builds crash on
  startup.
* `WasmSingleFileBundle=true` requires `wasi-sdk` (clang) to relink the
  native runtime, which is a heavy prerequisite for a sample.

Set the matching properties explicitly on the project so a plain
`dotnet publish` produces a runnable bundle, and document the new
working build / run procedure (and the remaining `Task.Wait` blocker
tracked in #5366) in the README.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants