[browser] Package CoreCLR browser-wasm native relink headers in the runtime pack

[pavelsavara]

Problem

Follow-up to #131646. That PR made CoreCLR browser-wasm native relink work from a restored/packaged SDK, and one part of it shipped the VM/minipal headers (callhelpers.hpp, minipal/entrypoints.h, minipal/utils.h) needed by the relink into the Microsoft.NETCore.App.Runtime.browser-wasm runtime pack under native/include. It:

• src/native/corehost/browserhost/CMakeLists.txt — install(... DESTINATION sharedFramework/include ...) the three headers.
• src/installer/pkg/sfx/Microsoft.NETCore.App/Directory.Build.props — declared them as PlatformManifestFileEntry.

But the headers still don't end up in the pack. Inspecting a daily wasm-tools pack (11.0.0-rc.1.26404.112), runtimes/browser-wasm/native/ has dotnet.native.wasm + libs but no include/ dir, so BrowserWasmApp.CoreCLR.targets sees Exists($(MicrosoftNetCoreAppRuntimePackRidNativeDir)include\callhelpers.hpp) == false, falls back to the in-repo source path (absent in a restored SDK), and native relink fails again with:

callhelpers-pinvoke.cpp:10:10: fatal error: 'callhelpers.hpp' file not found

Root cause

The browserhost install(... DESTINATION sharedFramework/include ...) places the headers in the host shared framework ($(HostSharedFrameworkDir)/include) — the same dir the runtime pack already harvests libBrowserHost.a / dotnet.native.js / dotnet.native.wasm from. But nothing harvests the include/ subtree, so the headers are dropped. The platform-manifest declaration doesn't help — validation is pack ⊆ manifest, so a missing file never fails the build.

Mono already ships its relink headers correctly, harvesting them via LibrariesRuntimeFiles with NativeSubDirectory="include\wasm".

Fix

Harvest the headers through the standard mechanisms, sourced from the host shared framework where the CMake install actually puts them:

• eng/liveBuilds.targets — add the headers to LibrariesRuntimeFiles with NativeSubDirectory="include" / include\minipal (feeds the nupkg), mirroring the Mono include\wasm handling.
• src/native/corehost/corehost.proj (CopyWasmNativeFiles) — stage them into the in-tree runtime-pack layout (MicrosoftNetCoreAppRuntimePackNativeDir) alongside the other browser host files, so an in-tree clr+libs+host build's layout is also relink-capable.

Validation

End-to-end build.cmd -os browser -subset clr+libs+host+packs -c Debug (0 warnings, 0 errors). The headers are produced by the real browserhost CMake install and land in all three places with the minipal/ subdir preserved:

# host sharedFramework (CMake install)
artifacts/bin/browser-wasm.Debug/sharedFramework/include/callhelpers.hpp
artifacts/bin/browser-wasm.Debug/sharedFramework/include/minipal/{entrypoints.h,utils.h}

# in-tree runtime-pack layout (CopyWasmNativeFiles)
artifacts/bin/microsoft.netcore.app.runtime.browser-wasm/Debug/runtimes/browser-wasm/native/include/...

# shipping nupkg (LibrariesRuntimeFiles harvest)
runtimes/browser-wasm/native/include/callhelpers.hpp
runtimes/browser-wasm/native/include/minipal/entrypoints.h
runtimes/browser-wasm/native/include/minipal/utils.h

This is exactly what BrowserWasmApp.CoreCLR.targets probes for, so _VmWasmIncludeDir / _MinipalIncludeDir now resolve from the runtime pack instead of falling back to the missing in-repo path.

Notes

• WASI CoreCLR relink has the same latent gap (the header install was only added to browserhost/CMakeLists.txt), and could be addressed separately.
• CopyWasmNativeFiles (layout) and LibrariesRuntimeFiles (nupkg) duplicate the browser host-file list today; unifying them is a larger cleanup left as a follow-up.

Related: #128362

[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

This change updates the CoreCLR runtime-pack SFX packaging project so that (for browser/wasi) header files staged under $(CoreCLRSharedFrameworkDir)include\**\*.* are harvested into the runtime pack under runtimes/<rid>/native/include/, preserving subdirectories via %(RecursiveDir).

Changes:

• Add a new AddCoreCLRWasmIncludeFiles MSBuild target (scoped to browser/wasi) to include sharedFramework/include/** in the runtime pack.
• Map harvested headers to runtimes/$(RuntimeIdentifier)/native/include/%(RecursiveDir) using the same TargetPath pattern already used by the Mono runtime pack.
• Ensure %(RecursiveDir) is evaluated off a separate glob item (_CoreCLRWasmIncludeFile) to avoid MSBuild self-referencing issues (MSB4120).

[dotnet-policy-service]

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

[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.

[Copilot]

Pull request overview

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