c# "obj\debug\.exe" - Visual Studio “Could not copy” … during build

"bin\debug\.exe". because (25)

In Visual Studio Premium 2013 (Update 3), I solved this with a pre-build one-liner:

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

This gracefully deletes any old PDB files (if it can), then renames anything that's left with a .old.pdb extension. A nice side effect is that if the old PDB is still locked, it just adds another .old piece to the filename, and they all get cleaned up next time you restart Visual Studio and do a build.

For example, build/debug session 1 leaves MyProject.pdb locked.
The next time you build:
MyProject.pdb --> MyProject.old.pdb

Then, build/debug session 2 is started, and both MyProject.pdb and MyProject.old.pdb are still locked:
MyProject.old.pdb --> MyProject.old.old.pdb
MyProject.pdb --> MyProject.old.pdb

Finally, restarting Visual Studio and doing a fresh build will get rid of both of these, and continue the process as usual.

I keep getting this error during the build of my VS2012 C# project

Error   41  Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to
 Exceeded retry count of 10. Failed.    

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

Now I've figured out that killing the process


works (sometimes ) but this is getting on my nerves. Any way to stop this happening at all?

My debugger settings are


A workaround is to put this in the Pre-build event command line property of the >project (In the build Events tab):

Code Snippet

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

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

In my case it was Resharper Unit Tests runner(plus NUnit tests, never had such problem with MsTests). After killing the process, was able to rebuild process, without restarting OS or VS2013

My 10 cents contribution.

I still have this problem occasionally on VS 2015 Update 2.

I found that switching compilation target solves the problem.

Try this: if you are in DEBUG switch to RELEASE and build, then back to DEBUG. The problem is gone.


@Geoff's (https://.com/a/25251766/3739540) answer is good, but it throws error code 1 on recompile.

Here is what worked for me (2>nul 1>nul on the end + exit 0):

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul
(if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul
exit 0

I was able to fix this issue (VS 2010) through supplying following pre build action;

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

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

I think I solved it removing the check mark to Break all processes when one process breaks in Debug options (op's first screenshot->second option).
It's been building/running well for a while since I unchecked it.
I'm using MySql NET Connector and DevExpress controls in my project. May be one of them was not disposing connections, bindings, etc. well because of this flag beeing activated.

EDITED: definitely it works! No more 'Unable to copy file' and no more Form designer errors.

I have solved it by killing IISExpress in task manager

Add in pre-build event of your master project taskkill /f /fi "pid gt 0" /im "YourProcess.vshost.exe"

If none of the answers works, try this simple check. Find for any MSbuild.exe running and holding your project EXE. Kill MSBuild.exe and you should be good to go.

I didn't realize I still had my debugger attached and was trying to build in the same Visual Studio instance. Once I stopped the debugger I was able to build.


In some cases in Visual Studio when you (Build || Rebuild) on top of running IISExpress you faced with this Exception:

Unable to copy file "obj\Debug\YourProjectName.dll" to bin\YourProjectName.dll". the process cannot access the file 'bin\YourProjectName.dll' because it is being used by another process


  1. Right click on web project that needs to build.
  2. Click on properties.
  3. Select Build Events Tab on the left side.
  4. In Pre-build events command line paste these 2 line:
tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "iisexpress.exe"

You are good 2 GO!

If you are debugging T4 templates, then this happens all the time. My solution (before MS fixes this) would be just to kill this process:

Task Manager --> User --> T4VSHostProcess.exe

This process only comes up when you debug a T4 template, not when you run one.

It's because you have closed your application, but it's still running in background.

Temporary solution:

  • Go to Task Manager (Ctrl + Alt + Esc).
  • Go to Processes tab and find "YourProjectName.exe".
  • Check "Show processes from all users" if you can't find your process.
  • End Process it.

Permanent solution: you have to close your application through coding. Here is the code...


You have to put this code in to the form's closing event in all form. Example:

private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)

It seems that by change the assembly name of a project fixes the problem.

So instead of this

I change it to this

Notice that I just changed it from Increment and Recall to Increment_Recall, I just removed the spaces. It is now working fine to me.

Killing the process w3wp.exe (IIS) will often solve this.
Generally, you can know the process that has the lock on the file by navigating to the bin folder and trying to delete it. The error message that will pop up, in case another process is using it, will contain the name of the process that needs to be killed.

You should disable your antivirus (especailly if it is an Avast) and try again. It helped me. The problem is that the debugger/builder creates the .exe file that is identified as a threat by Avast and therefor deleted right before it could be executed by VS.

I finally how fix it. Why we can't continue debug after the first debug because the first debug exe still running. So that, after first debug, you need to go to Task Manager -> Process Tab -> [your project name exe] end the exe process.

it works for me :)

I have encountered similar error messages in Visual Studio 2013.

Mostly, I have found that this situation has occurred when a debug process was halted because of an exception.

When clean+build has not resolved this problem for me, I have had success by doing the following:

  • Closing Visual Studio
  • Deleting the bin and obj folders, and
  • Reopening Visual Studio.

This "bug" has existed since Visual Studio 2003.

Finally, I have also found that I can often overcome this problem by simply renaming the executable file and then deleting it.

I faced the same problem on VS 2012 Version 11.0.60610.01 Update 3 on Windows 8

There were no designer windows open and the project was a simple console application.

The removal of the vshost process accessing the file does not work most of the time since the process isn't accessing the file.

The simplest workaround that works and takes the least amount of time is to remove the project from the solution, build another project in the solution and then add the original back.

It's an irritant and waste of time but it's the least expensive of all the other options that I know of.

Hope this helps...

See this other answer. Basically, you could have MSBuild.exe processes running in the background consuming resource files. If you have any pre or post build tasks that cause an MSBuild to be kicked off via command line, try adding the "/nr:false" flag to this command. But again, see the previous answer for more specific details.

I cannot give a solution to prevent this from happening but you can at least RENAME the locked file (windows explorer, or classic command window) and then compile/build. No need to reboot or restart VS201x. With some experience you can add a pre-build script to delete old files or rename then out-of-the-way in case there's a lock.

the .vhost.exe is a debugger process, so it appears that the process being debugged hasn't closed properly. Chances are you have a bug that's keeping it alive and are not stopping the debug process correctly - there are options to detach from the process when you click 'stop debugging' instead of actually killing the debugger so maybe you have that set.

But that's the problem - the file you're trying to copy over is locked (ie still being used) by the OS so its preventing the copy. Ensure that file is free and you'll be able to copy.

In my case, it was the .NET Reflector Visual Studio Extension (version with VS 2012. Debugging was taking 10 seconds for each Step Over (F10).

In Visual Studio, go to Tools/Extensions and Updates... and disable the .NET Reflector Visual Studio Extension. Don't forget to restart Visual Studio.

c# visual-studio-2012 build process