I keep getting this error during the build of my VS2012 C# project
Error 41 Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to
"bin\Debug\WeinGartner.WeinCad.exe".
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
process.
Now I've figured out that killing the process
Weingartner.WeinCad.vhost.exe
works (sometimes ) but this is getting on my nerves. Any way to stop this happening at all?
My debugger settings are
It's because you have closed your application, but it's still running in background.
Temporary solution:
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:
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.
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.
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.
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
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.