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

[cjablonski76]

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]

[jez9999]

I'm getting this too, very annoying. I have a .NET Core console app solution with 4 projects some of which reference each other. When I dotnet publish -f netcoreapp2.1 -c Release, I will frequently get warnings like:

C:\Program Files\dotnet\sdk\2.1.500\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3101: Could not write state file "obj\Release\netcoreapp2.1\ExcaliburBot.Data.csprojAssemblyReference.cache". The process cannot access the file 'C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Data\obj\Release\netcoreapp2.1\ExcaliburBot.Data.csprojAssemblyReference.cache' because it is being used by another process.
[C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Data\ExcaliburBot.Data.csproj]

... and errors like:

CSC : error CS2012: Cannot open 'C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Common\obj\Release\netcoreapp2.1\ExcaliburBot.Common.dll' for writing -- 'The process cannot access the file 'C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Common\obj\Release\netcoreapp2.1\ExcaliburBot.Common.dll' because it is being used by another process.'
[C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Common\ExcaliburBot.Common.csproj]

Perhaps some kind of race condition bug in the publish command?

[peterhuene]

Hi @cjablonski76 and @jez9999:

Thank you for reporting this to us.

Would it be possible to use Process Explorer to determine which process has the file that's causing the build to fail open? That might help us pinpoint the problem.

Additionally, if you run dotnet build-server shutdown following a failed build, does it then build successfully?

[jez9999]

@peterhuene Process Explorer doesn't show any files open after the build, so it appears to be some kind of race condition in the build itself. When I ran dotnet build-server shutdown before the build, it still produced this warning:

C:\Program Files\dotnet\sdk\2.1.500\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3088: Could not read state file "obj\Release\netcoreapp2.1\ExcaliburBot.Data.csprojAssemblyReference.cache". The process cannot access the file'C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Data\obj\Release\netcoreapp2.1\ExcaliburBot.Data.csprojAssemblyReference.cache' because it is being usedby another process. [C:\Development\ExcaliburBot\ExcaliburBot\ExcaliburBot.Data\ExcaliburBot.Data.csproj]

[peterhuene]

I was able to briefly reproduce it (only once so far) with the repro solution from this issue. There's a race here somewhere. I suspect the problem is building with the solution from the command line such that we're building the class library project twice (potentially concurrently): once from the solution reference and once as a project reference from the web application project.

[cjablonski76]

@peterhuene, are you restarting your machine in between repros of the issue? For whatever crazy reason this was the only way to consistently repro it for me.

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.

[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?

[rainersigwald]

I'm tempted to call this a duplicate of #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]

@cjablonski76 would not passing global properties like TargetFramework via the --framework switch when building a solution work as a workaround for you?

I agree that we can dupe this to #9585. I'm going to close this issue so that we can track this with the other one. Please feel free to re-open if you have reason to believe this is not a dupe.

Thanks again for reporting this to us!

[LEMMAH-PROJECTS]

getting following error while build the code in mac machine

/Volumes/MyDrive/LemmahTechnologies/Projects/Billing Guidelines/BuilingGuideline/BuilingGuideline/CSC: Error CS2012: Cannot open '/Volumes/MyDrive/LemmahTechnologies/Projects/Billing Guidelines/BuilingGuideline/BuilingGuideline/obj/Debug/netcoreapp3.1/BuilingGuideline.Views.pdb' for writing -- 'Sharing violation on path /Volumes/MyDrive/LemmahTechnologies/Projects/Billing Guidelines/BuilingGuideline/BuilingGuideline/obj/Debug/netcoreapp3.1/BuilingGuideline.Views.pdb' (CS2012) (BuilingGuideline)

[lozn00]

tasikkill /f /im dotnet.exe

[mbahamonde-dev]

I was having this issue:
The process cannot access the file [FILE] because it is being used by another process.

I was able to fix it by running taskkill /f /im dotnet.exe and then trying to build again.