[browser] Include WasmAssembliesFinal in ReferenceCopyLocalPaths

[Copilot]

Fixes dotnet/aspnetcore#65122
Regression from #120330

Description

When building WASM browser projects with WasmNativeWorkload, assemblies from WasmAssembliesFinal (AOT/relinked outputs) are removed from ReferenceCopyLocalPaths but never restored. Debugger metadata loading and downstream MSBuild targets fail because they expect ReferenceCopyLocalPaths to contain all final assemblies.

Changes

In Microsoft.NET.Sdk.WebAssembly.Browser.targets, the _ResolveWasmOutputs target now restores WasmAssembliesFinal to ReferenceCopyLocalPaths after populating _WasmBuildAssetCandidates:

<_WasmBuildAssetCandidates Include="@(ReferenceCopyLocalPaths)" />
<_WasmBuildAssetCandidates Include="@(WasmNativeAsset)" />
<_WasmBuildAssetCandidates Include="@(WasmAssembliesFinal)" />
<_WasmBuildAssetCandidates Remove="@(_WasmProjectAssemblyBuild)" />

<!-- Add WasmAssembliesFinal back to ReferenceCopyLocalPaths for debugging and postprocessing tools -->
<ReferenceCopyLocalPaths Include="@(WasmAssembliesFinal)" />

No duplicates occur because matching items were already removed earlier (line 293) based on filename comparison.

Impact

• Debug builds: Fixes debugging by ensuring metadata is available
• Build-time tools: Restores compatibility with targets expecting complete ReferenceCopyLocalPaths
• Publish/packaging: No change; only affects build-time item groups

Original prompt

Problem

When building .NET 11 WASM browser projects in Debug, debugging fails because the new process removes assemblies from ReferenceCopyLocalPaths when building with WasmNativeWorkload. While _WasmBuildAssetCandidates does include WasmAssembliesFinal, these are not propagated back to ReferenceCopyLocalPaths, causing issues for debugger metadata loading and post-processing tools that still rely on ReferenceCopyLocalPaths being complete.

Solution

After _WasmBuildAssetCandidates is set up (and ReferenceCopyLocalPaths is emptied of candidates present there), add back @(WasmAssembliesFinal) to ReferenceCopyLocalPaths. This ensures any final AOT or relinked assemblies are available to all postprocessing, debugging, and dependent targets expecting ReferenceCopyLocalPaths to be populated. The fix involves amending the logic in Microsoft.NET.Sdk.WebAssembly.Browser.targets right after _WasmBuildAssetCandidates is filled and before any further build pipeline steps.

Justification

• Ensures debugging works (metadata available)
• Maintains compatibility with downstream targets and common MSBuild/SDK logic
• Does not affect publish/packaging artifact correctness, since only Debug and build-time operations require this item group to be accurate

Steps

• In the _ResolveWasmOutputs target, after filling _WasmBuildAssetCandidates, add:
  
• Add a comment explaining that this is needed to retain debugging/IDE/diagnostic compatibility.

Notes

• Pattern is consistent with other uses in the repo (see src/mono/wasm/build/WasmApp.Common.targets)
• No effect on published output, only on intermediate build state

---

This resolves ongoing regressions for 11.0 debugging identified in dotnet/aspnetcore#65122.

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR fixes a regression from PR #120330 where WASM browser projects fail to debug because WasmAssembliesFinal items (AOT/relinked assemblies) are removed from ReferenceCopyLocalPaths but never restored, causing debugger metadata loading failures and breaking downstream MSBuild targets that rely on a complete ReferenceCopyLocalPaths item group.

Changes:

• Adds WasmAssembliesFinal back to ReferenceCopyLocalPaths in the _ResolveWasmOutputs target after the assemblies are removed (line 293) and included in _WasmBuildAssetCandidates (line 300)
• Includes a clear comment explaining the purpose for debugging and postprocessing tools