Fix handling of relative paths when using graph builds with implicit restore #7361
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #5898
Context
Executing projects changes the cwd, which makes relative paths behave unexpectedly. So when an implicit restore happens (
/restore
), then the cwd is different than what it was originally. For non-graph builds, this isn't a problem as theBuildRequestData
gets the full path of the project file before the implicit restore, so there effectively are no relative paths to deal with. However, this was not the case forGraphBuildRequestData
, so doing a build with/retore
,/graph
, and a relative path to a project file was erroring incorrectly.Changes Made
The
ProjectGraphEntryPoint
constructor will now get the full path of the project file, similar to whatBuildRequestData
does today.I also followed all uses of
ProjectGraphEntryPoint.ProjectFile
and removed any normalization since it's now always done already.Testing
I tested this change calling msbuild on a relative path with graph on/off and restore on/off. It now behaves as expected.