[wasm] Don't import the Mono wasm props on the CoreCLR path

[lewing]

Alternative to #131372, following @maraf's review feedback there: keep the CoreCLR wasm targets a standalone set instead of conditioning the shared Mono props.

Problem

Publishing a browser-wasm app with the experimental CoreCLR wasm SDK fails with:

error MSB4057: The target "_WasmBuildAppCore" does not exist in the project.
  (BrowserWasmApp.CoreCLR.targets(216))

Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in imported BrowserWasmApp.props unconditionally (and through it WasmApp.Common.props), then picked the targets file per flavor. So the CoreCLR path inherited Mono's WasmNestedPublishAppDependsOn=_WasmBuildAppCore, a target defined in WasmApp.Common.targets, which the CoreCLR path never imports.

Fix

Condition the BrowserWasmApp.props import on Mono, matching the existing per-flavor targets split:

<Import Project="...\BrowserWasmApp.props"           Condition="'$(UseMonoRuntime)' != 'false'" />
<Import Project="...\BrowserWasmApp.targets"         Condition="'$(UseMonoRuntime)' != 'false'" />
<Import Project="...\BrowserWasmApp.CoreCLR.targets" Condition="'$(UseMonoRuntime)' == 'false'" />

CoreCLR needs no props counterpart:

• RuntimeIdentifier is set by WasmSdk/Sdk/Sdk.props and by our Microsoft.NET.Sdk.WebAssembly.Pack.props, both before this Sdk.targets runs.
• TargetOS / TargetArchitecture are only consumed in-tree (eng/native.wasm.targets), where eng/OSArch.props already derives both from RuntimeIdentifier == 'browser-wasm'. That is why in-tree CoreCLR works today without ever importing BrowserWasmApp.props.

The Mono files are untouched.

Validation

Staged a replica of the packaged SDK layout (generated Sdk.targets from the template plus the Sdk-dir files) and ran msbuild against it:

Scenario	Result
UseMonoRuntime=false	RID=browser-wasm IsBrowserWasmProject=true TargetsBrowser=true, Mono depends-on lists empty
UseMonoRuntime=true	unchanged: _WasmBuildAppCore in both lists, WasmAppRuntimeFlavor=Mono
UseMonoRuntime unset	identical to the Mono case
Invoke WasmNestedPublishApp for CoreCLR, before the change	reproduces the MSB4057 above
Same, after the change	runs clean: ResolveRuntimePackAssets -> Publish -> _GatherWasmFilesToPublish -> CoreCLR targets

The last pair also confirms the WebAssembly SDK's prepend to WasmNestedPublishAppDependsOn (_GatherWasmFilesToPublish) still composes on the CoreCLR side, as does PrepareForWasmBuildApp from eng/testing/tests.browser.targets.

Not affected: in-tree builds of either flavor (already split by RuntimeFlavor), WASI (no packaged CoreCLR split, and its CoreCLR targets define no nested-publish target), and the Helix/WBT CoreCLR leg (imports BrowserWasmApp.CoreCLR.targets directly).

Note

This change was drafted with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[lewing]

@maraf this?

[Copilot]

Pull request overview

This PR fixes the packaged Microsoft.NET.Runtime.WebAssembly.Sdk import chain for the experimental CoreCLR browser-wasm flavor by ensuring it imports a matched props+targets pair per runtime flavor, avoiding Mono-only property defaults leaking into the CoreCLR targets graph.

Changes:

• Make the packaged SDK’s Sdk.targets template import BrowserWasmApp.props only for Mono (UseMonoRuntime != false), and import a new BrowserWasmApp.CoreCLR.props for CoreCLR (UseMonoRuntime == false).
• Add BrowserWasmApp.CoreCLR.props containing only the minimal flavor-neutral properties needed by the CoreCLR path.
• Include the new .props file in the SDK NuGet package layout.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in	Splits imports so Mono and CoreCLR each get a consistent props+targets pair.
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj	Packages the new CoreCLR props file into the SDK’s Sdk/ directory.
src/mono/browser/build/BrowserWasmApp.CoreCLR.props	New CoreCLR-specific props file providing TargetOS, TargetArchitecture, and RuntimeIdentifier without Mono-only target list defaults.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[maraf]

@maraf this?

Yes ❤️

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[lewing]

@maraf even better?