With static graph enabled, relative path isn't resolved correctly

[ViktorHofer]

PS C:\git\runtime3> dotnet build src\libraries\System.Runtime\ref\System.Runtime.csproj /bl
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

Some command line switches were read from the auto-response file "MSBuild.rsp". To disable this file, use the "-noAutoResponse" switch.
C:\Program Files\dotnet\sdk\5.0.100\MSBuild.dll -consoleloggerparameters:Summary -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\5.0.100\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\5.0.100\dotnet.dll -graph -maxcpucount -restore -verbosity:m /bl src\libraries\System.Runtime\ref\System.Runtime.csproj
  Determining projects to restore...
  All projects are up-to-date for restore.
C:\git\runtime3\src\libraries\System.Runtime\ref\src\libraries\System.Runtime\ref\System.Runtime.csproj : error MSB4025: The project file could not be loaded. Could not find a part of the path 'C:\git\runtime3\src\libraries\System.Runtime\ref\src\libraries\System.Runtime\ref\System.Runtime.csproj'.

Build FAILED.

C:\git\runtime3\src\libraries\System.Runtime\ref\src\libraries\System.Runtime\ref\System.Runtime.csproj : error MSB4025: The project file could not be loaded. Could not find a part of the path 'C:\git\runtime3\src\libraries\System.Runtime\ref\src\libraries\System.Runtime\ref\System.Runtime.csproj'.
    0 Warning(s)
    1 Error(s)

Using the 5.0.100 SDK. Looks like msbuild concatenates the relative path passed in with the path that resolves to the project file.

cc @rainersigwald @cdmihai

[rainersigwald]

I repro with two interesting tidbits:

1. Only in dotnet msbuild, not msbuild.exe
2. Not with a bootstrap debug copy of MSBuild

[rainersigwald]

Same debug copy of MSBuild repros when put in a .NET 5 install.

Proximate cause is here:

 	Microsoft.Build.dll!Microsoft.Build.Shared.FileUtilities.GetFullPath(string path) Line 411	C#
 	Microsoft.Build.dll!Microsoft.Build.Shared.FileUtilities.NormalizePath(string path) Line 372	C#
 	Microsoft.Build.dll!Microsoft.Build.Graph.GraphBuilder.AddGraphBuildPropertyToEntryPoints(System.Collections.Generic.IEnumerable<Microsoft.Build.Graph.ProjectGraphEntryPoint> entryPoints) Line 390	C#
 	Microsoft.Build.dll!Microsoft.Build.Graph.GraphBuilder.GraphBuilder(System.Collections.Generic.IEnumerable<Microsoft.Build.Graph.ProjectGraphEntryPoint> entryPoints, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Graph.ProjectGraph.ProjectInstanceFactoryFunc projectInstanceFactory, Microsoft.Build.Graph.ProjectInterpretation projectInterpretation, int degreeOfParallelism, System.Threading.CancellationToken cancellationToken) Line 61	C#
 	Microsoft.Build.dll!Microsoft.Build.Graph.ProjectGraph.ProjectGraph(System.Collections.Generic.IEnumerable<Microsoft.Build.Graph.ProjectGraphEntryPoint> entryPoints, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Graph.ProjectGraph.ProjectInstanceFactoryFunc projectInstanceFactory, int degreeOfParallelism, System.Threading.CancellationToken cancellationToken) Line 422	C#
 	Microsoft.Build.dll!Microsoft.Build.Graph.ProjectGraph.ProjectGraph(System.Collections.Generic.IEnumerable<Microsoft.Build.Graph.ProjectGraphEntryPoint> entryPoints, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Graph.ProjectGraph.ProjectInstanceFactoryFunc projectInstanceFactory) Line 329	C#
>	Microsoft.Build.dll!Microsoft.Build.Execution.BuildManager.ExecuteGraphBuildScheduler(Microsoft.Build.Graph.GraphBuildSubmission submission) Line 1414	C#

because the CWD is changed to the entry-point's folder. Not sure why yet.

[rainersigwald]

Something in ExecuteRestore is changing CWD. So there's a workaround:

dotnet build -graph src\MSBuild\MSBuild.csproj -restore:false

[cdmihai]

I repro with two interesting tidbits:

1. Only in dotnet msbuild, not msbuild.exe
2. Not with a bootstrap debug copy of MSBuild

That pretty much sums up what I tested things on, and what our CI tests against :)

[rainersigwald]

I wonder if this is going to start failing when we update to target .NET 5.

[cdmihai]

I was wondering why the static graph tests in the sdk are passing. But when I looked into it I remembered that they got disabled and we didn't follow up into reenabling them

[rainersigwald]

It looks like just doing a graph build changes the working directory--I see it when I disable restore but break in and check after the main call to ExecuteGraphBuild.

I'm going to stop looking at this for the moment but we should definitely chase this down.

[rainersigwald]

BTW, I think that invalidates my other findings: msbuild.exe doesn't have -restore by default, and neither does directly calling dotnet path\to\private\msbuild.dll. I bet if we added -restore there (as dotnet build does implicitly) we'd see the problem.

[marcpopMSFT]

@dfederm Would you be looking into static graph issues going forward?

[dfederm]

@marcpopMSFT Sure, will take a look.

[dfederm]

Looks like the cwd gets changed with non-graph builds too, but paths are resolved to be absolute beforehand so it's not a problem. Likely we just need to do the same with the graph build request