[wasm] Fix MSB4057 publishing CoreCLR browser-wasm apps#131372
Open
lewing wants to merge 1 commit into
Open
Conversation
The packaged WebAssembly SDK (Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in) imports BrowserWasmApp.props unconditionally, which pulls in WasmApp.Common.props, and then selects BrowserWasmApp.CoreCLR.targets when UseMonoRuntime is false. Those props defaulted WasmNestedPublishAppDependsOn to _WasmBuildAppCore, a target defined in WasmApp.Common.targets, which the CoreCLR path never imports. Publishing a CoreCLR browser-wasm app therefore failed with: MSB4057: The target "_WasmBuildAppCore" does not exist in the project. Guard the Mono-only target lists on UseMonoRuntime != 'false' so the CoreCLR path starts from an empty list and uses its own _CoreCLRWasmBuildAppCore, while contributions that prepend to the property (the WebAssembly SDK's _GatherWasmFilesToPublish and the test targets' PrepareForWasmBuildApp) still compose correctly. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b49e36e8-8a37-48ef-b7e8-54ac6443ea19
|
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. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a build/publish failure for CoreCLR-based browser-wasm apps caused by WasmApp.Common.props seeding Wasm*DependsOn properties with Mono-only target names that aren’t imported/defined in the CoreCLR flavor’s targets chain.
Changes:
- Split
WasmApp.Common.propssoTargetArchitecture=wasmremains unconditional, while theWasmBuildAppDependsOn/_WasmBuildAppCoreDependsOn/WasmNestedPublishAppDependsOndefaults are only set when$(UseMonoRuntime) != 'false'. - Add an explanatory comment documenting why these lists must not be seeded for CoreCLR.
lewing
added
arch-wasm
Contributor
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Member
Author
|
@maraf there was indeed a problem |
maraf
reviewed
Jul 27, 2026
| (see Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in), and it defines its own | ||
| equivalents. Seeding the Mono names there would make its WasmNestedPublishApp target | ||
| depend on the non-existent _WasmBuildAppCore, failing the build with MSB4057. --> | ||
| <PropertyGroup Condition="'$(UseMonoRuntime)' != 'false'"> |
Member
There was a problem hiding this comment.
I believe we should condition the import of BrowserWasmApp.props or WasmApp.Common.props in the workload pack.
My initial goal with CoreCLR targets was to a create completely separate CoreCLR-only set of targets.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Publishing a browser-wasm app with the experimental CoreCLR wasm SDK fails with:
Why
Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.inimportsBrowserWasmApp.propsunconditionally, which pulls inWasmApp.Common.props, and only then picks the flavor-specific targets file (BrowserWasmApp.CoreCLR.targetswhenUseMonoRuntime == 'false').WasmApp.Common.propsdefaultedWasmNestedPublishAppDependsOnto_WasmBuildAppCore, which is defined inWasmApp.Common.targets. The CoreCLR path never imports that file (it defines its own_CoreCLRWasmBuildAppCore), so the CoreCLRWasmNestedPublishApptarget inherited a dependency on a target that does not exist in its import chain.Approach
Guard the Mono-only target lists in
WasmApp.Common.propswithCondition="'$(UseMonoRuntime)' != 'false'". The flavor decision happens two lines after that import inSdk.targets.in, so the property is already set when the props are evaluated.The CoreCLR path now starts from an empty list and relies on its own
_CoreCLRWasmBuildAppCore, which was already listed explicitly in itsDependsOnTargets. Contributions that prepend to the property still compose correctly, so nothing is lost:_GatherWasmFilesToPublish(Microsoft.NET.Sdk.WebAssembly.Browser.targets)PrepareForWasmBuildApp(eng/testing/tests.browser.targets)Notes
UseMonoRuntime=truestill yields_WasmBuildAppCorefor bothWasmBuildAppDependsOnandWasmNestedPublishAppDependsOn, whileUseMonoRuntime=falseyields empty lists withTargetArchitecture=wasmstill set.WasmApp.InTree.propsimportsBrowserWasmApp.propsonly for Mono. This only bites consumers of the packaged SDK.WasiApp.CoreCLR.targets) defines no nested-publish target.Note
This change was drafted with GitHub Copilot.