This time, we’re taking a look at an annoying situation where your previous debugging session, or perhaps your dotnet serve, somehow locks-up your dlls or other important files that you kind of need to overwrite when rebuilding.
And that, well, causes your build or debugging session to fail.
So, let’s take a closer look at the actual errors we’ve run ourselves into!
Build complains about retrying something and failing afterward, and something like this is either in the console or in your build output in Visual Studio:
MSB3021 Unable to copy file "[yourfilename]" to "bin\Debug\net6.0\[yourfilename]". The process cannot access the file 'bin\Debug\net6.0\[yourfilename]' because it is being used by another process. C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets 4809
And additionally, something like the below:
Error MSB3027 Could not copy "[yourfilename]" to "bin\Debug\net6.0\[yourfilename]". Exceeded retry count of 10. Failed. The file is locked by: "[processname] (71168)" C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets 4809
The key here is to find out the process that’s locking your file. That pesky rascal needs to be killed off so that your new build can overwrite any assemblies or other files.
Time needed: 5 minutes.
How to kill a process that’s locking a file you want to use?
- Open a command prompt as admin
You’ll need an elevated command prompt. You can get it by clicking your terminal of choice with the right mouse button and selecting “Run as administrator”
- Taskkill time!
Run this in the command prompt:
taskkill /im [processname] /f
taskkill is the command to kill processes, /it means you want to use the process name (as opposed to pid – process id) to identify the process you’re killing, and /f means to kill the process with such force it has no chance of escaping.
[processname] is what you get from MSBuild error MSB3027. Although, I guess you could also use the pid as it’s shown by MSBuild.
But if you don’t get it from MSBuild – use Resource Monitor (Disk > Disk Activity > Sort by File) to figure out which process it is using.
- Debug again – it should work now!
Without further ado, re-run your debugging or build and see how it (hopefully) works now!
… and with any luck, you should be good!
Any further problems? Let me know in the comments -section below!
- How to fix NU3028 and NU3037 errors in Azure DevOps builds? - September 20, 2022
- How to kill the process causing the “MSB3021 Unable to copy file — The process cannot access the file because it is being used by another process.” error? - September 13, 2022
- How to replace and reload application settings changes in .NET? - September 6, 2022