Uh oh!
There was an error while loading. Please reload this page.
[wasm] Remove hardcoded references to net8.0 from WasmApp*targets - #89699
Conversation
ghost
commented
Jul 31, 2023
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Why System.IO? System.IO is a pure shim assembly which might get trimmed out in certain scenarios.
There was a problem hiding this comment.
Trimmed from the runtime pack?
They are in different paths:./Microsoft.NETCore.App.Runtime.Mono.browser-wasm/8.0.0-dev/runtimes/browser-wasm/native/System.Private.CoreLib.dll./Microsoft.NETCore.App.Runtime.Mono.browser-wasm/8.0.0-dev/runtimes/browser-wasm/lib/net8.0/System.IO.dll
.. and we need the latter one.
There was a problem hiding this comment.
"C:\Users\vihofer.nuget\packages\microsoft.netcore.app.runtime.win-x64\8.0.0-rc.1.23381.3\runtimes\win-x64\lib\net8.0\System.Private.CoreLib.dll"
Why is the mono runtime pack different? The CoreCLR one has System.Private.CoreLib in the lib directory (as it's a managed library). cc @akoeplinger
Trimmed from the runtime pack?
Not from the runtime pack directly, but the linker trims out of some shim assemblies afaik. I wasn't sure if this code path would run before or after but I guess it's before. You could consider using an assembly that is more "core" to the .NETCoreApp shared framework, i.e. System.Runtime but I'm also ok with the current state.
There was a problem hiding this comment.
Looks like this fails for AOT/helix where we create a proxy project, and run only the wasm part of the build. And that doesn't have RuntimePackAsset, because none of the targets related to that were run.
I will try to populate RuntimePackAsset in the proxy project, but that will be bit of a hack.
ViktorHofer
left a comment
There was a problem hiding this comment.
If that works, looks good. Please double check that _MscorlibPath, _SystemRuntimePath and _WasmAOTSearchPaths include the correct values.
Thank you
radical
commented
Aug 1, 2023
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
radical
commented
Aug 1, 2023
AOT failure might be relevant. Investigating. |
radical
commented
Aug 1, 2023
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
radical
commented
Aug 2, 2023
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
radical
commented
Aug 2, 2023
I had to change from using |
radical
commented
Aug 2, 2023
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
radical
commented
Aug 3, 2023
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ViktorHofer
commented
Aug 3, 2023
@radical you added unrelated commits, didn't you? |
radical
commented
Aug 3, 2023
The merge seems messed up a bit, so |
… as native build depends on that
.. assemblies. `RuntimePackAsset` can't be reliably used because it is not always available in the various test setups used. Instead, find `System.Runtime.dll` in the runtime pack path, which is already known.
f177757 to
6106560Compareradical
commented
Aug 3, 2023
Force pushed with the rebased commits. |
Look for
System.Runtime.dllto find the runtime pack directory with the assemblies, so we don't need to figure out the tfm for the path.System.Private.CoreLib.dllbecause that is innative/instead oflib/net8.0RuntimePackAssetbecause in many places that item isn't available.RuntimePackAssetcannot easily be synthesized.Fixes#79109 .