在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

(有时)有用,但这让我很紧张。有办法阻止这一切发生吗?

调试器设置为


当前回答

使用Ms进程资源管理器查看是否需要在Windows 7中打开“应用程序体验”

在我的情况下,所有其他建议都不起作用(Windows 7, VS2019)

编译后,生成的. exe文件被重新锁定约一分钟。另一个奇怪的观察:当删除。exe文件时,它像往常一样消失在文件资源管理器中,但在刷新时(F5)重新出现。

您可以使用MS进程资源管理器来查找是否有任何进程持有生成的. exe文件的句柄。为此,查看进程资源管理器的“下窗格”,选择查看句柄而不是dll,并使用“查找”来搜索您的. exe文件。

这告诉我,这是Windows 7的“系统”进程,得到了一个句柄。exe。

一些研究显示,我必须打开Windows的“应用程序体验”服务(“自动启动”)才能永久摆脱这种奇怪的行为。


以下是更多信息: 在什么情况下,系统进程(PID 4)保留一个打开的文件句柄?

其他回答

.vhost.exe是一个调试器进程,因此正在调试的进程似乎没有正确关闭。有可能你有一个错误,使它仍然存在,并且没有正确地停止调试进程——当你单击“停止调试”而不是实际杀死调试器时,有一些选项可以从进程中分离出来,所以也许你有这样的设置。

但这就是问题所在——你试图复制的文件被操作系统锁定(即仍在使用),所以它阻止了复制。确保该文件是免费的,您将能够复制。

如果您正在调试T4模板,那么这种情况经常发生。我的解决方案(在MS修复这个问题之前)将只是杀死这个进程:

任务管理器—> User—> T4VSHostProcess.exe

此过程仅在调试T4模板时出现,而不会在运行T4模板时出现。

在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并进行一个新的构建将摆脱这两个问题,并像往常一样继续这个过程。

I ran into this as well. It turns out that I had been testing with a service which I had built myself and which was running out the of the ..\bin\release directory of one of the projects in my solution. I had got the service running, but I forget to stop/uninstall it before returning to testing. As a result, it was holding on to one of the dlls that I reference and which needed to be moved (automatically as a dependency) from one project's bin/release subfolders to another. Stopping the service solved the problem.

在你的主项目taskkill /f /fi "pid gt 0" /im "YourProcess.vshost.exe"中添加预构建事件