Non-deterministic concurrency issues in solutions with multiple projects

[natemcmaster]

I'm seeing concurrency issues that occurs when calling dotnet build SomeProject.sln. The errors I see do not occur on every build, nor does there seem to be any pattern to when they occur. The errors can occur on first builds after a fresh clone as much as they will occur on second and third builds.

The only thing that seems to be consistent is that it occurs in projects with multiple project references.

The project: DotNetTools.zip

Versions:
dotnet-cli 1.0.0-preview4-004215
Windows 10

Detailed log: msbuild.log.txt

The errors:

CSC : error CS2012: Cannot open 'C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\obj\Debug\netcoreapp1.0\Microsoft.DotNet.Watcher.Tools.Tests.dll' for writing -- 'The process cannot access the file 'C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\obj\Debug\netcoreapp1.0\Microsoft.DotNet.Watcher.Tools.Tests.dll' because it is being used by another process.' [C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\Microsoft.DotNet.Watcher.Tools.Tests.csproj]

C:\dev\Universe\DotNetTools.dotnet\sdk\1.0.0-preview4-004215\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(119,5): error MSB4018: The "GenerateRuntimeConfigurationFiles" task failed unexpectedly.\r [C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\Microsoft.DotNet.Watcher.Tools.Tests.csproj]
C:\dev\Universe\DotNetTools.dotnet\sdk\1.0.0-preview4-004215\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(119,5): error MSB4018: System.IO.IOException: The process cannot access the file 'C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\bin\Debug\netcoreapp1.0\Microsoft.DotNet.Watcher.Tools.Tests.runtimeconfig.json' because it is being used by another process.\r [C:\dev\Universe\DotNetTools\test\Microsoft.DotNet.Watcher.Tools.Tests\Microsoft.DotNet.Watcher.Tools.Tests.csproj]

[fearthecowboy]

We're seeing this too-a lot.

It looks like it's rebuilding the same dependent project if multiple projects depend on it.

Ie, if A depends on B , C , D, E, F and C and D and E depend on G ... we see conflicts.

[Eilon]

Hi folks, I was talking to @natemcmaster today and he tried a newer build and this issue didn't repro.

Is this issue officially resolved? Or maybe we just got "lucky" in our build and it happened to succeed?

[srivatsn]

No we haven't been able to figure out the root cause. Unless something changed in msbuild - @AndyGerlicher @rainersigwald, you may have just gotten lucky.

[natidea]

I'm not able to repro this on new builds either. Will keep a lookout for any similar failures.

[natemcmaster]

Same here. Haven't been able to repro in rc3 bits. We can probably close this

[srivatsn]

Closing this. Please reopen if you see this again.

[jaredpar]

Re-opening. We are seeing this on a virtually daily basis with dotnet/roslyn right now. This issue is tracking it on our side

dotnet/roslyn#21421

[jaredpar]

Ping. This continues to fail a non-trivial number of builds in dotnet/roslyn.

[natidea]

/cc @nguerrera @dsplaisted who own this scenario now. Much of the context/discussion for this issue is in #739

[nguerrera]

@jaredpar do roslyn builds save a .binlog? Would it be possible to see one in the failed case? Also, @rainersigwald used https://github.com/rainersigwald/ParallelBuildDebuggingLogger to diagnose the issue that was fixed in #739. A log with that on in the failed case would also help.

[jaredpar]

No. I will try and change it to generate binary logs.

[nguerrera]

Thanks, that will help a lot.

[nguerrera]

Closing this again as the cause of the issues in Roslyn is different than what was fixed for #739, which was almost certainly a dupe of this.

dotnet/roslyn#22232 will fix things for Roslyn

#1599 tracks better diagnostics/experience in this explicit-documentation-file-vs-multi-targeting case.