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

Avoid double writes to PDB in NAOT publish #98342

Merged
merged 1 commit into from
Feb 15, 2024

Conversation

MichalStrehovsky
Copy link
Member

Resolves #89763 (although it will only get fixed once we also update the SDK).

We currently let the publish logic do its things unaware of what PublishAot will do and then copy over native bits. So before this PR, we had to overwrite the PDB that Publish placed there. The fix in this PR fixes things based on the current par for the course.

In general, I wonder if we should switch to the same mechanism that R2R, ILLink, or Single file publishing use - have SDK be aware of the magic target and then modify ResolvedFileToPublish items as needed in the magic target.

Cc @dotnet/ilc-contrib

We currently let the publish logic do its things unaware of what PublishAot will do and then copy over native bits.

In general, I wonder if we should switch to the same mechanism that R2R, ILLink, or Single file publishing use - have SDK [be aware of the magic target](https://github.com/dotnet/sdk/blob/95025c62f4e260540c1257627616641e9670501e/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L453-L460) and then modify ResolvedFileToPublish items as needed.
@ghost
Copy link

ghost commented Feb 13, 2024

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Resolves #89763 (although it will only get fixed once we also update the SDK).

We currently let the publish logic do its things unaware of what PublishAot will do and then copy over native bits. So before this PR, we had to overwrite the PDB that Publish placed there. The fix in this PR fixes things based on the current par for the course.

In general, I wonder if we should switch to the same mechanism that R2R, ILLink, or Single file publishing use - have SDK be aware of the magic target and then modify ResolvedFileToPublish items as needed in the magic target.

Cc @dotnet/ilc-contrib

Author: MichalStrehovsky
Assignees: MichalStrehovsky
Labels:

area-NativeAOT-coreclr

Milestone: -

Copy link
Member

@sbomer sbomer left a comment

Choose a reason for hiding this comment

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

LGTM

In general, I wonder if we should switch to the same mechanism that R2R, ILLink, or Single file publishing use - have SDK be aware of the magic target and then modify ResolvedFileToPublish items as needed in the magic target.

For ILLink, I made SDK aware of the target in response to this feedback: dotnet/sdk#3125 (comment).

I think it'd make sense to switch to a similar model where we modify ResolvedFileToPublish (this could be done whether or not we hard-code a dependency on a magic target).

@MichalStrehovsky
Copy link
Member Author

Thank you for the extra context! I'll look into doing this like the other publish extension points are doing.

@MichalStrehovsky MichalStrehovsky merged commit c2eae1b into main Feb 15, 2024
108 of 110 checks passed
@MichalStrehovsky MichalStrehovsky deleted the MichalStrehovsky-patch-2 branch February 15, 2024 21:09
@github-actions github-actions bot locked and limited conversation to collaborators Mar 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Building ILC causes double writes in the runtime build
2 participants