dotnet restore at solution-level doesn't follow ProjectReference with ReferenceOutputAssembly of false leading to random build failures

[livarcocc]

From @jhudsoncedaron on June 26, 2017 19:34

Steps to reproduce

The attached .zip contains a solution that reproduces the problem intermittently.

Expected behavior

dotnet restore on B finishes before C resulting in a good build of C

Actual behavior

dotnet restore on C sometimes finishes too soon causing nonsense build errors.

Environment data

Bug is partially mitigated by NTFS; please note that --disable-parallel and NTFS appear to fix the problem but really don't; a different set of names would cause the problem to reappear.

dotnet --info output:

.NET Command Line Tools (1.0.4)

Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.4

Visual Studio

Visual Studio 2017 can't restore or build this reliably either.

reduce-build-nasty.zip

Fixing issue #4781 would permit fixing the build issues in the .csproj files but would make builds much slower by recursively invoking dotnet restore

Copied from original issue: dotnet/cli#7004

[jhudsoncedaron]

We've been playing with the new tooling in .NET Core 2.0 preview; the new tooling fixes the bug by accident as it made dotnet restore implicit to dotnet build at the project level; it's still quite spectacular to open our master solution in Visual Studio and watch it promptly hose the build environment (apparently by invoking dotnet restore explicitly).

[tomtheisen]

For anyone else struggling with Visual Studio working with solutions like this, I have found a work-around that works for me. The problem is that normally VS automatically restores packages for solutions when they load. However, restore is broken, as per this issue. So this automatic restore is a sure-fire way to break your build.

My solution is to create a delicate custom-built restore script that runs with VS closed. Under the VS Options Dialog, in "NuGet Package Manager", clear all the checkboxes. If you're able to get your packages restored correctly outside of Visual Studio, this setting will prevent VS from breaking your solution every time you open it.

[emgarten]

Dupe of #4700

[jhudsoncedaron]

I think that's a false duplicate. The behavior they describe there is B not being restored at all. The behavior here is B is getting restored but C isn't waiting for the restore of B to finish and so gets confused.

[emgarten]

Restores are independent, a parent project does not use the result of restores from child projects.

ReferenceOutputAssembly=false is likely unrelated to the problem here. I see several mentions of restore failing here both in VS and command line and mentions of performance but no actual error messages or numbers of performance. Any extra info that could be provided using the latest dotnet CLI 2.0.0 would be helpful.

[jhudsoncedaron]

The restore never yields an error; but the build either yields this error:

error : Cannot find project info for 'C:\Users\jhudson\dev\reduce-build-nasty\src\B\B.csproj'. This can indicate a missing project reference.

or this error triplet:

Program.cs(7,18,7,25): error CS0518: Predefined type 'System.Object' is not defined or imported
Program.cs(9,26,9,32): error CS0518: Predefined type 'System.String' is not defined or imported
Program.cs(9,16,9,20): error CS0518: Predefined type 'System.Void' is not defined or imported

but sometimes it goes through anyway.

Forcing the restores to happen in dependency order would reliably make the problem go away. The reduction was done with git clone and examining output logs for which builds succeeded and which failed. The failures always had the characteristic of restore of C finished before B.

I just now went back and checked on the 1.1 tooling again; running the restores in the wrong order does not break the build; the build only breaks when the restores are ran in parallel. Therefore we may conclude as you say the results of package restore don't depend on each other. But somehow the process does.

[emgarten]

@jhudsoncedaron thanks for the extra info. I'm opening the issue.

[jhudsoncedaron]

Bug does not reproduce on .NET Core 2.0 release version; we haven't fully verified the VS restore can't corrupt these projects yet though