Skip to content
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

Merged
merged 14 commits into from
Aug 3, 2023

Conversation

radical
Copy link
Member

@radical radical commented Jul 31, 2023

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.

  • Cannot use System.Private.CoreLib.dll because that is in native/ instead of lib/net8.0
  • Cannot use RuntimePackAsset because in many places that item isn't available.
    • AOT on helix where we run only the wasm targets on the proxy project.
    • Runtime tests which currently dump all the assemblies, and other bits into a single directory, not following the directory structure of a runtime pack. This also means the RuntimePackAsset cannot easily be synthesized.

Fixes #79109 .

@radical radical added the arch-wasm WebAssembly architecture label Jul 31, 2023
@ghost ghost assigned radical Jul 31, 2023
@ghost
Copy link

ghost commented Jul 31, 2023

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #79109 .

Author: radical
Assignees: -
Labels:

arch-wasm

Milestone: -

@radical radical marked this pull request as ready for review July 31, 2023 23:40

<!-- 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>
Copy link
Member

@ViktorHofer ViktorHofer Aug 1, 2023

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.

Copy link
Member Author

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.

Copy link
Member

@ViktorHofer ViktorHofer Aug 1, 2023

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.

Copy link
Member Author

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.

ViktorHofer
ViktorHofer previously approved these changes Aug 1, 2023
Copy link
Member

@ViktorHofer ViktorHofer left a 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

@radical
Copy link
Member Author

radical commented Aug 1, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@radical
Copy link
Member Author

radical commented Aug 1, 2023

AOT failure might be relevant. Investigating.

@radical radical added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Aug 1, 2023
@radical
Copy link
Member Author

radical commented Aug 1, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@radical
Copy link
Member Author

radical commented Aug 2, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@radical
Copy link
Member Author

radical commented Aug 2, 2023

I had to change from using RuntimePackAsset, because it is not available in many setups we test like AOT on helix.
This still does not fix the runtime tests though which seem to just dump all the assemblies into a native folder! I'm working on fixing that.

@radical
Copy link
Member Author

radical commented Aug 2, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@radical radical requested a review from ViktorHofer August 2, 2023 20:23
@radical
Copy link
Member Author

radical commented Aug 3, 2023

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ViktorHofer
Copy link
Member

@radical you added unrelated commits, didn't you?

@radical
Copy link
Member Author

radical commented Aug 3, 2023

@radical you added unrelated commits, didn't you?

The merge seems messed up a bit, so git log shows extra commits. But the only actual changes here are the relevant ones. I was avoiding cleaning this up to not mess up reviewing on github (it won't show "changes since last review" if you force-push), but I'll do that now.

@radical radical force-pushed the wasm-hardcoded-tfm branch from f177757 to 6106560 Compare August 3, 2023 17:57
@radical
Copy link
Member Author

radical commented Aug 3, 2023

Force pushed with the rebased commits.

Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@radical radical merged commit 2ab3874 into dotnet:main Aug 3, 2023
@radical radical deleted the wasm-hardcoded-tfm branch August 3, 2023 22:49
@ghost ghost locked as resolved and limited conversation to collaborators Sep 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Build-mono
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove hardcoded TFM in wasm build files
3 participants