Wasm tests use Microsoft.NET.Sdk.WebAssembly and support CoreClr runtime#2998
Wasm tests use Microsoft.NET.Sdk.WebAssembly and support CoreClr runtime#2998timcassell merged 14 commits intodotnet:masterfrom
Microsoft.NET.Sdk.WebAssembly and support CoreClr runtime#2998Conversation
Instead of explicitly passing UseMonoRuntime, we should disable runtime/targeting pack download, similar to dotnet/runtime#124288 |
We don't pass it explicitly. We decided to change the sdk type instead, to change the value UseMonoRuntime defaults to. |
…RunV8Script and redundant PublishTrimmed.
ilonatommy
changed the title
Microsoft.NET.Sdk.WebAssemblyMicrosoft.NET.Sdk.WebAssembly and support CoreClr runtime
Require --output (BuildPartition.cs) — WASM needs explicit output paths because the WebAssembly SDK publishes to wwwroot/ inside the output directory. Without --output, build artifacts land in the default bin/ tree where the executor doesn't look. excludeArtifactsPath (DotNetCliCommand.cs) — BDN normally passes /p:ArtifactsPath to redirect output. But the SDK auto-sets UseArtifactsOutput=true when ArtifactsPath is non-empty, which adds $(ArtifactsPath)/** to DefaultItemExcludes — excluding every file in the project directory (including wwwroot/) from default Content globs. For WASM, we pass /p:UseArtifactsOutput=false instead, since OutDir/OutputPath/--output already control where output goes. Content Update (WasmCsProj.txt) — With UseArtifactsOutput=false, the SDK's default <Content Include="wwwroot\**" ...> glob works, so Content Update can upgrade those items with CopyToOutputDirectory=PreserveNewest.
… + subdir for artifacts to avoid issues with excluding wwwroot files from contents.
|
Did these changes break |
What are the failures, where can I see them? I am not sure about the theory of no support. dotnet/runtime#61313, dotnet/runtime#62292 are in .net 7 and imply modules were working then already. |
|
Sorry, I misunderstood. It could have broken |
4 participants
Problem
The autogenerated benchmark project uses Microsoft.NET.Sdk, which does not set UseMonoRuntime=true. This causes ProcessFrameworkReferences to resolve the CoreCLR runtime pack (Microsoft.NETCore.App.Runtime.browser-wasm) instead of the Mono one (Microsoft.NETCore.App.Runtime.Mono.browser-wasm). The CoreCLR pack does not exist for browser-wasm, so the build fails.
PR #2994 worked around this by adding -r browser-wasm to the restore command, but this only defers the error — the runtime pack is still not resolved correctly during build.
Fix
Switch the default SDK to
Microsoft.NET.Sdk.WebAssembly, which auto-defaultsUseMonoRuntime=trueand resolves the correct Mono runtime pack. AddIsMonoRuntimeflag to WasmRuntime so users can opt into the CoreCLR runtime pack (--wasmCoreCLRCLI flag), which falls back toMicrosoft.NET.Sdk.Changes
Testing
Integration tests: 4/4 WasmTests pass (net8.0, AOT + Interpreter × V8 + JSC)
benchmarks_ci.py: 5/5 Perf_Boolean.Parse benchmarks pass on Wasm AOT