Unable to copy a file from obj\Debug to bin\Debug

I have a project in C# and I get this error every time I try to compile the project:

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

So I have to close the process from the task manager. My project is only one form and there is no multi-threading.

What is the solution (without restarting VS or killing the process)?

enter image description here


Solution 1:

@Udpate: Since the time I was first posting this 'answer', I tend to another explanation to the problem. The issue since than happened more and more often outside of Visual Studio also - while trying to copy an .exe file from one folder to another. While in the first place Windows did not allow to copy(!) an .exe file (it was first asking me for administrative rights but refused to copy it afterwards anyway) it still showed up in the explorer. But after a while - without any further action taken, it disappeared magically. Just like the problem in the question always seems to solve itself after a while. So i assume, the problem is more related to a delayed deletion of the project output file and less a buggy VS. I apologize for any unjustified suspicion. :|

This gives the search for a solution a complete different direction, I guess. Did find that link and will update on any progress:

https://superuser.com/questions/234569/windows-7-delayed-file-delete

========================================================================

This is a known bug in VS. I discovered it very often - mostly in VS2010 (with/without SP1). Several "solutions" are recommended. Some of them, which kind of helped for me:

  1. Delete the .suo file in your project dir. Eventually need to create your whole solution from scratch.
  2. Close any Windows Form Designers may remain open.
  3. Use a prebuild script, which deletes the target from the output dir.
  4. Disable the VS hosting process.

None of these really fixes the bug. But it may brings the VS back to a usable state - until a true solution is provided by MS (if ever will).

http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/cea5e4b2-5b33-453c-bffb-8da9f1a1fa4a

http://social.msdn.microsoft.com/Forums/en/vbide/thread/cd12f3c7-de96-4353-adce-23975e30933f

Solution 2:

This should work.

Go to your project properties. Inside Build Events, under Pre-build event command line, add these two lines of code:

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

Solution 3:

I can confirm this bug exists in VS 2012 Update 2 also.

My work-around is to:

  1. Clean Solution (and do nothing else)
  2. Close all open documents/files in the solution
  3. Exit VS 2012
  4. Run VS 2012
  5. Build Solution

I don't know if this is relevant or not, but my project uses "Linked" in class files from other projects - it's a Silverlight 5 project and the only way to share a class that is .NET and SL compatible is to link the files.

Something to consider ... look for linked files across projects in a single solution.

Solution 4:

This is happening because [yourProjectName].exe process is not closing after finishing debugging.

There are two solutions to this problem.

  1. Every time you make change to application, Go to Task Manager -> Processes -> [yourProjectName].exe, end this process. You have to end this process every time you make changes to system.

  2. Add a exit button in your application to exit window and add these line to click event

    System.Diagnostics.Process.GetCurrentProcess().Kill();
    Application.Exit();
    

Solution 5:

If you look in the obj directory, and you don't see your .exe, it's possible that Avast! or other antivirus is deleting it. I would actually see the .exe show up and then disappear. As soon as I turned off Avast!, problem solved.

VS2010 throwing "Could not copy the file "obj\x86\Debug\[file].exe" because it was not found."