-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasm] Remove hardcoded references to net8.0
from WasmApp*targets
#89699
Conversation
|
||
<!-- find the path with the assemblies, so we don't have to hardcode the tfm. | ||
Cannot use System.Private.Corelib since that is in a different directory --> | ||
<_SystemIOPath>@(RuntimePackAsset->WithMetadataValue('Filename', 'System.IO'))</_SystemIOPath> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
/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). |
/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.
f177757
to
6106560
Compare
Force pushed with the rebased commits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Look for
System.Runtime.dll
to find the runtime pack directory with the assemblies, so we don't need to figure out the tfm for the path.System.Private.CoreLib.dll
because that is innative/
instead oflib/net8.0
RuntimePackAsset
because in many places that item isn't available.RuntimePackAsset
cannot easily be synthesized.Fixes #79109 .