Error: Cannot access file bin/Debug/... because it is being used by another process

Question

Ugh, this is an old problem, something that still pops up in Visual Studio once in a while. It's bitten me a couple of times and I've lost hours restarting and fighting with VS. I'm sure it's been discussed here on SO more than once. It's also been talked about on the MSDN forums. There isn't an actual solution, but there are a couple of workarounds. Start researching here.

What's happening is that VS is acquiring a lock on a file and then not releasing it. Ironically, that lock prevents VS itself from deleting the file so that it can recreate it when you rebuild the application. The only apparent solution is to close and restart VS so that it will release the lock on the file.

My original workaround was opening up the bin/Debug folder and renaming the executable. You can't delete it if it's locked, but you can rename it. So you can just add a number to the end or something, which allows you to keep working without having to close all of your windows and wait for VS to restart. Some people have even automated this using a pre-build event to append a random string to the end of the old output filename. Yes, this is a giant hack, but this problem gets so frustrating and debilitating that you'll do anything.

I've later learned, after a bit more experimentation, that the problem seems to only crop up when you build the project with one of the designers open. So, the solution that has worked for me long term and prevented me from ever dealing with one of those silly errors again is making sure that I always close all designer windows before building a WinForms project. Yes, this too is somewhat inconvenient, but it sure beats the pants off having to restart VS twice an hour or more.

I assume this applies to WPF, too, although I don't use it and haven't personally experienced the problem there.

I also haven't yet tried reproducing it on VS 2012 RC. I don't know if it's been fixed there yet or not. But my experience so far has been that it still manages to pop up even after Microsoft has claimed to have fixed it. It's still there in VS 2010 SP1. I'm not saying their programmers are idiots who don't know what they're doing, of course. I figure there are just multiple causes for the bug and/or that it's very difficult to reproduce reliably in a laboratory. That's the same reason I haven't personally filed any bug reports on it (although I've +1'ed other peoples), because I can't seem to reliably reproduce it, rather like the Abominable Snowman.

_{<end rant that is directed at no one in particular>}

I've had this error crop up on me before, even in Visual Studio 2008. It came back and more prevalent in Visual Studio 2012.

Here is what I do.

Paste this in the troublesome project's pre-build event:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Computer (right-click) -> manage -> Service & Application -> service -> Enable Application experience

Worked For me!

I had the same issue in Visual Studio 2013. I'm not sure what caused this for my project, but I was able to fix it by cleaning the solution and rebuilding it.

1. Build > Clean Solution
2. Build > Rebuild Solution

I understand this is an old question. Unfortunately I was facing the same issue with my .net core 2.0 application in visual studio 2017. So, I thought of sharing the solution which worked for me. Before this solution I had tried the below steps.

1. Restarted visual studio
2. Closed all the application
3. Clean my solution and rebuild

None of the above steps didn't fix the issue.

And then I opened my Task Manager and selected dotnet process and then clicked End task button. Later I opened my Visual Studio and everything was working fine.

At least in my case I've noticed that visual studio 2012 was creating at least two msbuild.exe ghost processes, which did not perish after build. These zombies apparently are causing file locks to appear.

Killing msbuild.exe's is one time solution, it needs to be done per build basis.

But then I've figure out that I could disable parallel build once and for all - went into Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, I've switched to 1. Works like charm.

Of course builds are bit slower now, but better safe than sorry. At least for this particular small project I did not need more than one build thread.