c# - retry - visual studio unable to copy file used by another process

Visual Studio “Could not copy” … during build (20)


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!

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

  1. Open project properties [ menu > project > properties ]
  2. Choose "debug" tab
  3. Uncheck "Enable the visual studio hosting process"
  4. Start debugging [F5]
  5. You will receive security warning , just "ok". Lets application running
  6. Stop debugging.
  7. Check option "Enable the visual studio hosting process" , under debug tab,
  8. Now , try to start debugging , you will not see error again

[Work for me]

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

Follow the below steps

  1. Open Task Manager ( Ctrl + Alt + Delete )
  2. Under Performance tab select select <ProjectNameOfYours.exe>.
  3. Click on End Process.
  4. Now Build solution.

Above steps resolved error permanently :)

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.

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.

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 have solved it by killing IISExpress in task manager

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.

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.

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.

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

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 vstest.executionengine.exe process(es) resolves this issue 90% of the time for me. If that doesn't work, then also killing QTAgent32.exe and then deleting the /bin and /obj folders for the project in question works.

This is the most irritating part of my work day. :)

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.

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.



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"

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.