[wasm] Avoid unnecessary relinking when publishing a blazor project for AOT #82748
Conversation
ghost
assigned 
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
Depends on dotnet/xharness#1001 |
.. relinking during "Build", when publishing. `Publish` target triggers `Build` target to run. When publishing, we don't want to run relinking step during the `Build`, as it will be run for `Publish` anyway. Earlier there wasn't a good way to differentiate the two cases of `build` when building, and `build` when publishing, but now the sdk sets `$(_IsPublishing)=true`, which can be used here.
`dotnet run` uses the regular build output. Published blazor app, like when using AOT, needs to be run more "manually" by starting a web server in the publish folder. This is accomplished here by using the new xharness command `wasm webserver`.
|
This adds missing tests that run AOT'ed blazor app. And that repros the currently broken state. |
| @@ -172,7 +173,7 @@ | |||
| <!-- Use a unique property, so the already run wasm targets can also run --> | |||
| <MSBuild Projects="$(MSBuildProjectFile)" | |||
There was a problem hiding this comment.
I'm curious how this works.
Do we run separate MSBuild process here (which doesn't share variables and items from parent ?)
Do we still need to have it as separate process ?
Do we still need _WasmInNestedPublish_UniqueProperty_XYZ ?
There was a problem hiding this comment.
Do we run separate MSBuild process here (which doesn't share variables and items from parent ?)
No, but it runs it in a fresh context. I will be removing this, but I'm waiting for the blazor<->runtime build changes to happen.
Do we still need to have it as separate process ?
It's not necessarily a separate process. And this PR doesn't change anything about this.
Do we still need _WasmInNestedPublish_UniqueProperty_XYZ ?
Yep
Essentially, this PR doesn't change any behavior w.r.t the nested publish. The nested publish bit was a hacky solution, and will be removed. But I'm holding that off till we get further on the build consolidation with blazor.
There was a problem hiding this comment.
@ilonatommy opened issue for ICU related dependency on not nesting it
#82819
Updating 'Microsoft.DotNet.XHarness.CLI': '1.0.0-prerelease.23117.1' => '1.0.0-prerelease.23151.1' (from build '20230301.1' of 'https://github.com/dotnet/xharness') Updating 'Microsoft.DotNet.XHarness.TestRunners.Common': '1.0.0-prerelease.23117.1' => '1.0.0-prerelease.23151.1' (from build '20230301.1' of 'https://github.com/dotnet/xharness') Updating 'Microsoft.DotNet.XHarness.TestRunners.Xunit': '1.0.0-prerelease.23117.1' => '1.0.0-prerelease.23151.1' (from build '20230301.1' of 'https://github.com/dotnet/xharness')
|
Added the xharness dependency update here, from #82600 |
|
The failures are unrelated and #82868 . |
Publishtarget triggersBuildtarget to run. When publishing, we don't wantto run relinking step during the
Build, as it will be run forPublishanyway. Earlier there wasn't a good way to differentiate the two cases of
buildtarget -dotnet build, anddotnet publish, but now the sdk sets$(_IsPublishing)=true, which can be used here.VS uses
$(DeployOnBuild), and that is still supportedAnd add tests to run blazor+AOT