You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all, this issue started early last week and it's preventing me from building at all.
I'm getting a bunch of errors like this one:
The process cannot access the file 'C:\Projects\Tafs.Activities\src\Tafs.Activities.Serialization\obj\Debug\Tafs.Activities.Serialization.GeneratedMSBuildEditorConfig.editorconfig' because it is being used by another process. [C:\Projects\Tafs.Activities\src\Tafs.Activities.Serialization\Tafs.Activities.Serialization.csproj]
The issue persists even after manually deleting all output, obj, and bin directories in the solution. I will also get occasional access denied errors from CSC, but this error typically resolves itself after a clean and rebuild. I think what's happening is it's spawning multiple msbuild processes to make the build more efficient. But these processes hold on to the files they create for the entire time they're running and don't actually shut down until the end of the build. This means when one msbuild process tries to access a file a different msbuild process is responsible for creating, it cannot because the file handle is still being held. I have confirmed that the msbuild process are in fact exiting properly once the build finishes, so this is not a case of lingering processes from earlier runs retaining a hold on those files.
This typically leads to some cascading exceptions, like a particular dll for a project library not existing or referencing the wrong version of System.Runtime because a particular target did not build.
I have also included the binlog from dotnet build Tafs.Activities.sln -bl, but I had to add the .txt extension in order to get it past GitHub's file filter. Please feel free to review this or to generate your own if you believe it will help. I'm not sure how to read it myself, so I was unable to extrapolate any additional information from it as to why the build was failing, nor was I able to use it to confirm my hypothesis.
Edit: I should note that the number of errors and the files that are locked do change between each build. Often it is the output DLLs for the project or the one of the generated files like the .editorconfig in the sample above.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all, this issue started early last week and it's preventing me from building at all.
I'm getting a bunch of errors like this one:
The issue persists even after manually deleting all output, obj, and bin directories in the solution. I will also get occasional access denied errors from CSC, but this error typically resolves itself after a clean and rebuild. I think what's happening is it's spawning multiple msbuild processes to make the build more efficient. But these processes hold on to the files they create for the entire time they're running and don't actually shut down until the end of the build. This means when one msbuild process tries to access a file a different msbuild process is responsible for creating, it cannot because the file handle is still being held. I have confirmed that the msbuild process are in fact exiting properly once the build finishes, so this is not a case of lingering processes from earlier runs retaining a hold on those files.
This typically leads to some cascading exceptions, like a particular dll for a project library not existing or referencing the wrong version of System.Runtime because a particular target did not build.
The repository, or rather, the fork that is having issues is open source and can be found here: https://github.com/Foxtrek64/Tafs.Activities
I have also included the binlog from
dotnet build Tafs.Activities.sln -bl
, but I had to add the .txt extension in order to get it past GitHub's file filter. Please feel free to review this or to generate your own if you believe it will help. I'm not sure how to read it myself, so I was unable to extrapolate any additional information from it as to why the build was failing, nor was I able to use it to confirm my hypothesis.msbuild.binlog.txt
Edit: I should note that the number of errors and the files that are locked do change between each build. Often it is the output DLLs for the project or the one of the generated files like the .editorconfig in the sample above.
Beta Was this translation helpful? Give feedback.
All reactions