Error: Cannot access file bin/Debug/… because it i

Question

When I debug my project, I get following error:

"Unable to copy file "obj\Debug\My Dream.exe" to "bin\Debug\My Dream.exe". The process cannot access the file 'bin\Debug\My Dream.exe' because it is being used by another process."

Using Process Explorer, I see that MyApplication.exe was out but System process still uses it although I stopped debug before. Whenever I change my code and start debug it is going to happen. If I copy project to USB and debug, it runs OK.

Why? How can I fix this error?

I use Window 7 Professional. With Xp I have never got this error.

Answer 1

In my case was that I have enable "Show All Files". Visual Studio 2017

Answer 2

Make sure that any previous run of the application (for example, start without debugging option) is actually stopped. I was working on a WPF application, started without debugging and had it minimized when I kept getting the error. After closing the application VS behavior got back to normal.

Answer 3

[Solved] Error: Cannot access file bin/Debug/… because it is being used by another process:

I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen.

Basically, you need to close your first form which is running in the background and the main reason behind this error.

To close the first form you have to add these two lines of code in the second form load event handler.

    Form1 form = new Form1();
    form.Close();

This will solve the error perfectly.

Answer 4

It could be too late. But, I encountered similar problem and in my case the project had self reference. Hence, deleting it from the References worked like a charm!!!

Answer 5

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>}

Answer 6

I've found the quickest way without closing forms or restarting VisualStudio is go to the project's compile page and click "Advanced Compile Options..." button. Then make any change to one of the options (say, changing Generate Debug Info from Full to pdb-only), then click OK. It works every time and will have to do until MS fixes this bug (I've never had this problem until I switched from VS2012 to VS2013)

Another note, if you can't clean the project or solution, it won't build. The files are definitely locked by VS (not a antivirus problem, at least not in my case)