-
Notifications
You must be signed in to change notification settings - Fork 520
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
Consider not passing framework references to UnpackLibraryResources
#15030
Labels
enhancement
The issue or pull request is an enhancement
performance
If an issue or pull request is related to performance
Milestone
Comments
Perhaps fits in #10251 |
We already have logic to skip framework assemblies, but maybe it's not working for .NET projects: |
Maybe it would still be better to filter them out on the MSBuild side (instead of in C#) because in MSBuild we know for sure what the framework references are. |
rolfbjarne
added a commit
that referenced
this issue
Oct 2, 2024
…assemblies. Fixes #19511. (#21305) We know BCL won't have library resources to unpack, so there's no need to spend any time looking at them. This also required porting the UnpackLibraryResources task to use System.Reflection.Metadata, because MetadataLoadContext requires the reference assemblies to be available to resolve assembly dependencies (and the idea is to not have to pass any reference assemblies to the task). Fixes #19511. Fixes #15030.
rolfbjarne
added a commit
that referenced
this issue
Oct 22, 2024
…assemblies. Fixes #19511. (#21305) We know BCL won't have library resources to unpack, so there's no need to spend any time looking at them. This also required porting the UnpackLibraryResources task to use System.Reflection.Metadata, because MetadataLoadContext requires the reference assemblies to be available to resolve assembly dependencies (and the idea is to not have to pass any reference assemblies to the task). Fixes #19511. Fixes #15030.
rolfbjarne
added a commit
that referenced
this issue
Oct 28, 2024
…assemblies. Fixes #19511. (#21305) We know BCL won't have library resources to unpack, so there's no need to spend any time looking at them. This also required porting the UnpackLibraryResources task to use System.Reflection.Metadata, because MetadataLoadContext requires the reference assemblies to be available to resolve assembly dependencies (and the idea is to not have to pass any reference assemblies to the task). Fixes #19511. Fixes #15030.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
The issue or pull request is an enhancement
performance
If an issue or pull request is related to performance
I'm seeing
UnpackLibraryResources
take over a second for a minimal project, and I'm guessing the most time is taken by reading all the reference assemblies:Perhaps if we know that none of the in the box assemblies come with resources, we should exclude them from the list being passed to the task? I think this should shave off a second from each project build.
This is dotnet 6.0.202
The text was updated successfully, but these errors were encountered: