[wasm] Remove hardcoded references to net8.0 from WasmApp*targets#89699
[wasm] Remove hardcoded references to net8.0 from WasmApp*targets#89699radical merged 14 commits intodotnet:mainfrom
net8.0 from WasmApp*targets#89699Conversation
ghost
added
the
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
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
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
AOT failure might be relevant. Investigating. |
radical
added
the
NO-MERGE
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I had to change from using |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
radical
removed request for
MichalStrehovsky,
lambdageek,
lateralusX and
marek-safar
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@radical you added unrelated commits, didn't you? |
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.
radical
force-pushed
the
wasm-hardcoded-tfm
branch
from
f177757 to
6106560
Compare
|
Force pushed with the rebased commits. |
3 participants
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 .