在VS2012 c#项目的构建过程中，我一直得到这个错误
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.
现在我知道该终止进程了
Weingartner.WeinCad.vhost.exe
(有时)有用，但这让我很紧张。有办法阻止这一切发生吗?
调试器设置为
当前回答
我在Visual Studio 2013中遇到过类似的错误消息。
大多数情况下，我发现这种情况发生在调试进程因为异常而停止时。
当clean+build不能为我解决这个问题时，我通过以下方法取得了成功:
关闭Visual Studio 删除bin和obj文件夹 重新开放Visual Studio。
此“bug”自Visual Studio 2003以来一直存在。
最后，我还发现我通常可以通过简单地重命名可执行文件然后删除它来克服这个问题。
其他回答
如果我使用VS2012在WP8上编辑Xaml页面，每次部署都会遇到这个问题。
我需要要么不打开Xaml页面，要么使用进程资源管理器杀死进程XDesProc.exe。
如果您得到这个错误，那么我建议使用进程资源管理器来查看发生了什么(即使这是一个不同的问题)。只要找到进程“WeinGartner.WeinCad.exe”，它应该显示进程和处理访问文件(好吧，至少当杀死vhost文件不解决问题)。
我注意到一些答案可以解决我的问题，但是，以防有人有和我一样的问题。
如果你正在运行一个控制台应用程序:在你做任何其他事情之前。
确保您已经关闭了从以前的版本中打开的任何控制台窗口。例如，我只是在一个控制台应用程序中测试一些代码，我没有意识到以前运行程序时的控制台窗口是打开的。在我调试的过程中，窗口被推到后面，我看不到它。只是说，这可能是你的问题，所以检查确保这不是问题。
异常
在某些情况下，在Visual Studio当你(Build || Rebuild)在上面 运行IISExpress时，你会遇到这个异常:
无法复制文件"obj\Debug\YourProjectName.dll"到bin\YourProjectName.dll"。进程无法访问该文件 'bin\YourProjectName.dll'，因为它正在被其他人使用 过程
解决方案
右键单击需要构建的web项目。 单击属性。 在左侧选择Build Events选项卡。 在Pre-build events命令行中粘贴这两行:
tasklist /fi “imagename eq iisexpress.exe” |find “：” > NUL 如果错误级别 1 任务杀死 /f /im “iisexpress.exe”
你很好!
在Visual Studio Premium 2013 (Update 3)中，我用一个预构建的一行程序解决了这个问题:
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
这将优雅地删除任何旧的PDB文件(如果可以的话)，然后重命名任何带有.old的文件。pdb的扩展。一个很好的副作用是，如果旧的PDB仍然是锁定的，它只是在文件名中添加另一个.old块，并且在下次重新启动Visual Studio并进行构建时，它们都将被清除。
例如，构建/调试会话1离开MyProject。pdb锁定。 下次构建时: MyProject的。MyProject.old.pdb
然后，构建/调试会话2启动，并且MyProject。pdb和MyProject.old.pdb仍然锁定: MyProject.old.pdb—> MyProject.old.old.pdb MyProject的。MyProject.old.pdb
最后，重新启动Visual Studio并进行一个新的构建将摆脱这两个问题，并像往常一样继续这个过程。
看看另一个答案。基本上，你可以让MSBuild.exe进程在后台运行，消耗资源文件。如果你有任何构建前或构建后的任务，导致MSBuild通过命令行启动，尝试添加"/nr:false"标志到这个命令。但是，关于更具体的细节，请参见前面的回答。
