Closed aguacongas closed 3 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
@radical it looks related to https://github.com/dotnet/runtime/issues/60274. I have a binlog at "\prkrishn-foo\share\msbuild.binlog" in case it helps, but it's fairly trivial to reproduce this with a regular blazor-wasm app.
Publish runs twice
and in the first one a bunch of MSBuild properties aren't resolved which results in this error:
First publish:
^ Notice Resources is missing
Second publish:
The first one is kicked off by WasmNestedPublishApp
. More worrying is that it's sufficient to have the tool installed (without required AOT compilation) to run in to this issue:
> dotnet publish
Microsoft (R) Build Engine version 17.0.0-preview-21474-03+9f83c725f for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
rc1 -> D:\temp\testapps\b1\rc1\bin\Debug\net6.0\rc1.dll
b1 -> D:\temp\testapps\b1\b1\bin\Debug\net6.0\b1.dll
b1 (Blazor output) -> D:\temp\testapps\b1\b1\bin\Debug\net6.0\wwwroot
Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
rc1 -> D:\temp\testapps\b1\rc1\bin\Debug\net6.0\rc1.dll
b1 -> D:\temp\testapps\b1\b1\bin\Debug\net6.0\b1.dll
b1 (Blazor output) -> D:\temp\testapps\b1\b1\bin\Debug\net6.0\wwwroot
Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
D:\temp\dotnet6\sdk\6.0.100-rc.2.21505.1\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(524,5): error BLAZORSDK1001: Unable to find 'rc1.dll' to be lazy loaded later. Confirm that project or package references are included and the reference is used in the project. [D:\temp\testapps\b1\b1\b1.csproj]
it looks related to dotnet/runtime#60274.
That one is failing with The command "emcc --version" exited with code 1.
, and seems unrelated.
This is my understanding of what's happening here:
Publish
target, and then the wasm native targets runduring the Publish
part of it:
a. we get to ProcessPublishFilesForBlazor
, which currently we skip for the nested publish case ($(WasmBuildingForNestedPublish)
)
@(StaticWebAsset)
, when runb. Then we get to GeneratePublishBlazorBootJson
, which fails because it doesn't have the StaticWebAssets
correctly populated, and thus can't find the lazy loaded assembly
Please correct me if I didn't that right. I don't really understand the static web assets part.
To fix this, I tried removing the condition on ProcessPublishFilesForBlazor so it would run for nested publish also.
@(WasmAssembliesToBundle)
is emptyThat seems to be because ProcessPublishFilesForBlazor
removes items from ResolveFileToPublish
_GatherWasmFilesForPublish
to fail as it depends on @(ResolvedFileToPublish)
to populate @(WasmAssembliesToBundle)
If this line of thinking is correct, then maybe we can instead of @(StaticWebAsset)
:
- <WasmAssembliesToBundle Include="%(ResolvedFileToPublish.FullPath)" Exclude="@(_Exclude)" Condition="%(Extension) == '.dll'" />
+ <WasmAssembliesToBundle Include="%(StaticWebAsset.FullPath)" Exclude="@(_Exclude)" Condition="%(Extension) == '.dll'" />
I'm not sure if this is the correct fix or not. @javiercn thoughts?
Our blazorwasm tests fail with this though, because there are more than one dotnet*js
files in the publish folder:
/Users/radical/dev/r3/artifacts/bin/Wasm.Build.Tests/net6.0-Release/browser-wasm/blz_aot_prj_file_Debug/bin/Debug/net6.0/publish/wwwroot/_framework/dotnet.6.0.0-rc.2.21470.23.bc68qmiu8q.js
/Users/radical/dev/r3/artifacts/bin/Wasm.Build.Tests/net6.0-Release/browser-wasm/blz_aot_prj_file_Debug/bin/Debug/net6.0/publish/wwwroot/_framework/dotnet.6.0.0-rc.2.21470.23.c0ti6blhkl.js
For future (7.0) work, the targets can be reworked a bit to reduce the amount of work we do in the nested publish, and better integrate it.
cc @lewing
This is duplicate to this issue? https://github.com/dotnet/aspnetcore/issues/37570
The linked issue has same issue but AOT is disabled
. It is using wasm-tools
.
Minimal example linked in the project if helpful.
@srpeirce the presence of the wasm-tools is sufficient to trigger the same code that appears as part of AOT.
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
@radical transferring this over to you.
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | aguacongas |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `untriaged`, `area-Build-mono` |
Milestone: | - |
Fixed by https://github.com/dotnet/sdk/pull/22145 . I will port this to main
also.
Description
If we want to compile a Blazor project with AOT and lazy loading the command
dotnet publish -c Release
fail with error :Reproduction Steps
dotnet publish -c Release
ex:
Expected behavior
The publish command should run without error
Actual behavior
The publish command fail with :
Regression?
No response
Known Workarounds
No response
Configuration
Other information
No response