Fix content publish path calculation#52731
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes incorrect publish TargetPath computation for Content items that only specify CopyToPublishDirectory, ensuring relative paths are consistently calculated from the user project directory instead of an SDK/imported targets directory.
Changes:
- Replaced
DefiningProjectDirectory-based relative path computation with$(MSBuildProjectDirectory)forContentitems with publish-only metadata. - Simplified conditional logic into a single path computation branch.
- Added an inline comment explaining why
DefiningProjectDirectoryis not reliable here.
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets
Show resolved
Hide resolved
|
This fix looks correct to me, but we'll need to backport to release/10.0.2xx when merged. @tmat the failing tests in CI are all under the dotnet-watch helix work item, and I can't seem to get any kind of output from azdo about them. How do you normally diagnose watch failures when they are reported in the pipelines? |
|
/ba-g known watch test timeout |
|
/backport to release/10.0.2xx |
|
Started backporting to |
|
/backport to release/11.0.1xx-preview1 |
|
Started backporting to |
You need to open the test logs. Unfortunately, the infra does not handle hanging tests well. |
Fixes dotnet/aspnetcore#65247
Thanks to @rainersigwald and @baronfel for quick analysis and rootcausing of the issue!
Context
The path was incorrecftly calculated from
DefiningProjectDirectory- which can point to sdk targets. The relative paths should be allways based onMSBuildProjectDirectorywhich points to the user project file.Testing
Was done manualy offline.
To repro the behavior, you need project with
CopyToPublishDirectoryitems, while it is being placed to more shallow folder nesting than the sdk that is being tested.