Builds of solutions frequently fail with CS2012 "Cannot open" file errors

Steps to reproduce

1. Clone my repro repository: https://github.com/cjablonski76/dotnetCoreBuildIssue.git

2. Restart your machine (this was the only consistent way I could repro the issue).

3. open command prompt, navigate to the cloned repo location

4. run dotnet build ./WebApplication1/WebApplication1.sln --framework netcoreapp2.1

   • Removing the --framework option seems to build without any “Cannot open” errors.

5. build command will error with:

   CSC : error CS2012: Cannot open ‘c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll’ for writing – ‘The process cannot access the file ‘c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll’ because it is being used by another process.’ [c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\ClassLibrary1.csproj]

NOTE: you must restart the machine each time you wish to reproduce the error. During my testing, after the first run on a fresh restart dotnet build --framework netcoreapp2.1 ran successfully. I’m sure there is a way to get into the bad state without restarting the machine, but this was the simplest thing I could find with my knowledge around the build process. When running on our CI servers, they tend to fail with a project like this a majority of the time if we build with the --framework flag.

Expected behavior

Successful build of the solution.

Actual behavior

Errors on build with output:

Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 57.46 ms for c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\ClassLibrary1.csproj.
  Restore completed in 259.57 ms for c:\src\dotnetCoreBuildIssue\WebApplication1\WebApplication1\WebApplication1.csproj.
  ClassLibrary1 -> c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\bin\Debug\netcoreapp2.1\ClassLibrary1.dll
CSC : error CS2012: Cannot open 'c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll' for writing -- 'The process cannot access the file 'c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll' because it is being used by another process.' [c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\ClassLibrary1.csproj]
  WebApplication1 -> c:\src\dotnetCoreBuildIssue\WebApplication1\WebApplication1\bin\Debug\netcoreapp2.1\WebApplication1.dll

Build FAILED.

CSC : error CS2012: Cannot open 'c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll' for writing -- 'The process cannot access the file 'c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\obj\Debug\netcoreapp2.1\ClassLibrary1.dll' because it is being used by another process.' [c:\src\dotnetCoreBuildIssue\WebApplication1\ClassLibrary1\ClassLibrary1.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:02.97

Environment data

dotnet --info output:

 Version:   2.1.403
 Commit:    04e15494b6

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

Host (useful for support):
  Version: 2.1.5
  Commit:  290303f510

.NET Core SDKs installed:
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[rainersigwald]

I’m tempted to call this a duplicate of dotnet/sdk#9585, which is itself not the first time the problem has been found but I can’t find the original.

Problems arise whenever you explicitly pass a --framework (CLI) or /p:TargetFramework= (direct MSBuild) to the build of a solution. The issue is that global properties (such as that TF setting) are inherited in most cases, but not all. Here, the ClassLibrary1 project is built once with an explicit TF (inherited from the solution build) and once with no TF (since it only has one, the ProjectReference from WebApplication1 does not pass its TF down).

The best way out of this is to only pass --framework to builds of individual projects, not solutions. Project-to-project references are careful not to get into this situation.

[peterhuene]

I’ve been able to reproduce it every once and awhile after doing a git clean -xdf to get back to a clean state where no intermediate or output files exist.

The solution is indeed building ClassLibrary1 more than once and concurrently, thus it’s a race to see which csc invocation is going to win by writing to the output assembly for the class library.

@cjablonski76 does using -maxcpucount:1 to for the build command resolve the issue by chance? This won’t stop the class library from being built multiple times, but should stop the race by not building them in parallel.

@rainersigwald Do we have an existing issue in MSBuild regarding a race when building a solution containing a project that is also a project reference of another project in the solution?