This post was most recently updated on November 28th, 2022.
2 min read.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!
Problem
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
What do?
Solution
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, /im 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.
Moving on, [processname] is what you get from MSBuild error MSB3027. Although, I guess you could also use the pid as it’s shown by MSBuild, too.
But if you don’t get it from MSBuild – use the Resource Monitor (Disk > Disk Activity > Sort by File) to figure out which process is using the file. And then you can get the id (or process name). - 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! ☺
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- “Performing cleanup” – Excel is stuck with an old, conflicted file and will never recover. - November 12, 2024
- How to add multiple app URIs for your Entra app registration? - November 5, 2024
- How to access Environment Secrets with GitHub Actions? - October 29, 2024
