Skip to content

[browser] Add explicit runtime flavor to perf pipeline#123181

Merged
maraf merged 1 commit intomainfrom
maraf/BrowserPerfRuntimeFlavor
Jan 14, 2026
Merged

[browser] Add explicit runtime flavor to perf pipeline#123181
maraf merged 1 commit intomainfrom
maraf/BrowserPerfRuntimeFlavor

Conversation

@maraf
Copy link
Member

@maraf maraf commented Jan 14, 2026

Fix regression from #122495. I have updated runtime.yml pipeline, but missed performance.

@maraf maraf added this to the 11.0.0 milestone Jan 14, 2026
@maraf maraf self-assigned this Jan 14, 2026
@maraf maraf requested a review from akoeplinger as a code owner January 14, 2026 16:48
Copilot AI review requested due to automatic review settings January 14, 2026 16:48
@maraf maraf added arch-wasm WebAssembly architecture area-Build-mono perf-pipeline Issues with dotnet-runtime-perf, or runtime-wasm-perf pipelines os-browser Browser variant of arch-wasm labels Jan 14, 2026
@maraf maraf requested a review from lewing January 14, 2026 16:48
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR adds an explicit /p:RuntimeFlavor=Mono parameter to the browser/WASM performance pipeline's artifact preparation step. This aligns the performance pipeline with other browser/WASM build configurations that already specify the runtime flavor explicitly.

Changes:

  • Added /p:RuntimeFlavor=Mono to the build command in the WASM performance artifact preparation template

@maraf maraf enabled auto-merge (squash) January 14, 2026 16:53
@maraf maraf merged commit 91d0ef7 into main Jan 14, 2026
36 of 52 checks passed
@lewing lewing deleted the maraf/BrowserPerfRuntimeFlavor branch January 14, 2026 17:39
lewing added a commit that referenced this pull request Feb 11, 2026
## Problem

After UseMonoRuntime was removed from in-tree wasm props (PR #121789 by
@maraf), browser-wasm test restores fail with NU1102 (package not
found).

The `RestorePackage` target in `build.proj` runs `dotnet restore` for
test dependency projects. These projects use `Microsoft.NET.Sdk` (not
the WebAssembly SDK), so `UseMonoRuntime` is not set. Without it, the
newer SDK tries to download `Microsoft.NETCore.App.Runtime.browser-wasm`
(CoreCLR pattern) or `Microsoft.NETCore.App.Runtime.Mono.browser-wasm`
from NuGet — packages that don't exist for .NET 11.

The test restore doesn't need runtime or targeting packs from NuGet —
those come from the local build and are wired up during the test build
step. However, `EnableRuntimePackDownload=false` and
`EnableTargetingPackDownload=false` were only passed conditionally (when
`UseLocalAppHostPack=true`), and browser-wasm sets
`UseLocalAppHostPack=false`.

## Fix

Unconditionally pass `-p:EnableRuntimePackDownload=false
-p:EnableTargetingPackDownload=false` to the test dependency restore
command. This fixes both Mono and CoreCLR browser-wasm configurations
since neither needs pack downloads during restore.

## Context

- Root cause PR: #121789 (Remove duplicated UseMonoRuntime=true from
SDK)
- Follow-up pattern: #123181 (Added RuntimeFlavor=Mono to perf pipeline)
- Affected codeflow PR: #124232

cc @maraf @akoeplinger
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 perf-pipeline Issues with dotnet-runtime-perf, or runtime-wasm-perf pipelines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants