构建错误：“进程无法访问该文件，因为它正由另一个进程使用”

Question

我有一个C＃webforms应用程序，直到今天才一直在游泳。

今天，突然间，每次我尝试运行应用程序时，都会出现文件锁定错误：

  

无法将文件“obj \ Debug \ MyProject.exe”复制到“bin \ Debug \ MyProject.exe”。该进程无法访问文件“bin \ Debug \ MyProject.exe”，因为它正由另一个进程使用。

谷歌搜索错误没有超出明显的范围，即VS认为文件被锁定。并且肯定 Visual Studio本身锁定文件，因为当我关闭VS并重新打开它时，项目执行正常 - 第一次。当我第二次尝试运行它时，我收到文件锁定错误。

每次我想运行应用程序时关闭VS并重新打开都不是一个可行的解决方法！如何找出锁定文件的内容，并阻止其被锁定？

编辑：另一个有趣的发现：我甚至不必运行该应用。只需编译一次就会导致文件锁定;我不能连续两次编译！

此问题特定于我的解决方案中的一个项目。所有其他项目都可以正常工作，并且可以根据需要执行多次。只有这一个项目才会被锁定。

Answer 1

我找到了一个适合我的简单解决方案。它是这样的：

当问题发生时，只需更改顶部的构建配置（如果在“Release”中更改为“Debug”，反之亦然），构建然后再切换回以前的配置并再次构建。

我认为更改配置会释放vcshost和devenv。

Answer 2

嗯，我自己解决了这个问题 - 虽然我仍然不知道为什么。我决定通过从项目中删除所有文件来隔离问题，然后重新添加它们并确定哪个文件是我的麻烦来源。因此，我一个接一个地将文件重新引入项目，编译和编译。清理了每一步...直到...我添加了最后一个......

......一切都运转良好。

我对原始.csproj的源代码控件进行了比较;没有真正的差异。即使我尝试恢复到之前版本的.csproj，它仍然有用。

黑魔法。如果它有效，有时最好不要问为什么 - 只要接受它并继续......

编辑：问题是反复出现的问题，我相信当编译器在编译时打开抽象/通用表单时，我已将其隔离。

获得的经验教训：确保在编译之前关闭任何抽象或通用表单或控件的表单设计器！如果没有，你必须关闭VS并重新打开！

Answer 3

我们在此发现的内容如下： 在项目属性页面的Debug选项卡中，取消选中＆＃34;启用visual studio主机进程＆＃34;。 我不确定这个属性是什么，但它一旦取消选中就完成了工作。

Answer 4

实际上您应该选中“启用Visual Studio托管过程”。至少对于VS2010来说。我也有：

如果存在“$（TargetPath）.locked”del“$（TargetPath）.locked” 如果存在“$（TargetPath）”如果不存在“$（TargetPath）.locked”move“$（TargetPath）”“$（TargetPath）.locked”

在预构建选项中。这个问题困扰了我很长一段时间，直到John W.提到这个复选框，我甚至注意到它存在并且很低，并且它已经没有被检查了。

另请注意，即使没有调试，-app-vshost.exe也会在后台运行。这就是每次我猜它成功构建和运行的原因。它以前没有运行过。我还尝试清理调试和释放文件夹并不断更改目标类型，除了上面所述之外没有任何工作。之前我的解决方案是在构建之间等待5分钟，这使得完成任务变得非常烦人且耗时。我没有看到行为的任何变化，其中重要的是打开或XNA与Windows窗体或打开设计器的选项卡。此问题发生在32位或64位版本中，如果我使用ALT-F4杀死应用程序或使用任务管理器将其终止，这无关紧要，从理论上讲，这将不允许应用程序关闭或释放资源。起初我以为这是一个垃圾收集问题。

Answer 5

稍微迟到了，但我通过转到项目的属性来解决这个问题＆gt;选项卡“调试”＆gt;取消选中“启用Visual Studio托管过程”。

Answer 6

VS2017 - 通过关闭Windows任务管理器中的所有MSBuild.exe实例来解决此问题

Answer 7

我通过重命名锁定的文件（使用Windows资源管理器）克服了这个问题。我不被允许删除该文件，但重命名锁定的文件有效！

Answer 8

我通过删除文件夹bin \ Debug并可能重启VS

来解决这个问题

Answer 9

只需投入2美分。通过打开任务管理器并终止应用程序解决了我的问题。它在后台运行，没有任何迹象表明它一直在运行（任务栏中没有项目，没有ui，没有），但我不确定为什么会这样。显然调试器没有运行，我当时只打开了一个VS的实例。令我惊讶的是，这仍然发生在VS 2017中。

也许我可以添加一个构建步骤来查找运行后台的应用程序并在启动新应用程序之前将其杀死。

Answer 10

删除.NET项目的Obj，零售和调试文件夹，然后重新构建对我来说再次起作用。

Answer 11

我在Visual Studio中的Xamarin应用程序遇到了同样的问题，通过拔掉我的测试移动设备解决了这个问题。应用程序已关闭，调试器已停止，但在尝试构建或重建解决方案时仍出现错误。它只是在我拔下设备后才停止，因为我不得不接听电话。

Answer 12

只需检查引用并删除对项目的自引用。

说明：我的问题在创建自定义控件后开始，然后将其拖放到工具箱面板中，以便在设计表单中使用它。首先出现了一个警告，说自定义控件源文件（.cs）和可执行项目（.exe）之间存在冗余。在执行/调试时出现错误：无法访问（.exe）因为它被使用（并且它是真的）。​​

我真的删除了关于自定义控件的整个源代码，问题仍然存在，直到我检查了引用并且它引用了自身以便能够＆＃34;能够＆＃34;得到以前的自定义控件。我删除了引用并完成了!!

Answer 13

从“运行”框中运行此命令：

net stop iisadmin /y

然后

iisreset

为我工作。 vs 2003

Answer 14

对我来说，这是一个安装并运行的Windows服务。一旦我停止了它，构建就成功了。

Answer 15

另一种解决方案：当文件被锁定时，报告阻止过程（类似“ ServiceHub.Host.CLR.x64（7764）”），其ID放在括号中。 要摆脱该过程，请打开PowerShell（x + Win + I）并键入：“ Stop-Process -Id idNumber”。

Answer 16

不幸的是，没有一个答案对我有用。这就是解决它的方法：

Win Key + R 并运行 resmon.exe。在那里您会找到 VS 声称正在使用该文件的 EXE 进程。右键单击并结束该过程。虽然您可能会收到访问被拒绝错误消息，但它会被暂停，您可以重新构建。

Answer 17

我认为大多数回答的人都有些无知，并且通过反复试验找到了解决方案。我最近也遇到了这个问题，并查看了该线程中的各种解决方案，但它们没有多大意义。我查看了我的项目的 makefile（它是由我的项目负责人手工制作的），我在那里找到了 -j11。我用 -j1 替换了它，它解决了问题。预感是 make 在运行多个作业（线程）方面可能做得不好，即当一个线程正在处理一个文件时，另一个线程正在尝试使用它。

对于使用 IDE 编译代码的人，您需要查找构建属性，您可以在其中设置作业数量，然后尝试将作业数量设置为 1 来编译代码。您可能还需要关闭并重新启动 IDE（这完全取决于 IDE 的编程方式）。

我知道这可能会阻碍您构建的性能，但在 make 修复此错误（如果有的话，我没有费心去挖掘）或 makefile 生成器变得足够智能之前，可能别无选择以防止出现这种情况。

Answer 18

我在UWP应用程序部署期间遇到了类似的错误。最终，我找到了使用导致该错误的文件并停止它的过程。归功于this链接。复制粘贴的版本如下。

如何解决问题？

处理锁定文件或文件夹的最简单方法之一就是使用Microsoft Sysinternals Process Explorer。

确定哪个程序正在使用文件

使用Process Explorer，有一种简单的方法可以找到程序：

1. 打开Process Explorer（以管理员身份运行）。
2. 在工具栏上，找到右侧的瞄准镜图标。
3. 将图标拖放到已锁定的打开文件或文件夹上。
4. 正在使用该文件的可执行文件将在Process Explorer的主显示列表中突出显示。

确定哪个句柄或DLL正在使用文件

1. 打开Process Explorer（以管理员身份运行）。
2. 输入键盘快捷键Ctrl + F。
3. 或者，单击“查找”菜单，然后选择“查找句柄或DLL”。 搜索对话框将打开。
4. 键入锁定文件或其他感兴趣文件的名称。 通常，部分名称就足够了。
5. 点击“搜索”按钮。
6. 将生成一个列表。 可能有很多条目。

然后终止此过程。

Answer 19

我在问题上苦苦挣扎了5天，可以通过事件查看器日志获取问题的根源； 端口443，我尝试访问的应用程序正在使用中，因此我不得不更改注册表设置；基本上，您将能够通过事件查看器中的错误日志来找到问题的来源。

Answer 20

对我有用的是重启IIS

Answer 21

我遇到了这个问题（以及我在其他地方不仅是VS看到的一个问题）。

这是由Dropbox（在我的情况下）引起的。编辑一些代码并运行后，有时dropbox会立即锁定文件（以便它可以处理它）。

解决方案1。 再次点击运行

解决方案2。 暂停保管箱。 （如果您使用保管箱作为云备份，则不好）

解决方案3。 从保管箱同步列表中删除构建文件夹。

Answer 22

我使用Visual Studio Code，并且由于开发服务器正在运行而收到此错误（我通过按Ctrl + F5运行了开发服务器）。

因此，我只是单击了停止标志以将其停止，错误消失了。

Answer 23

如果这是一个SSIS项目，请打开任务管理器并杀死DtsDebugHost.exe的所有实例，这些实例应释放锁定的文件。

Answer 24

我也遇到过同样的问题。 我尝试了上面列出的“几种解决方案”，但它们对我不起作用。

我通过从服务器资源管理器中关闭连接并关闭了在Visual Studio中打开的所有选项卡来解决了这个问题。

Answer 25

我遇到了同样的问题，无法使用前面的答案中提到的任何方法来纠正。我通过杀死任务管理器中的“ SSIS调试历史记录（32位）”的所有实例来解决该问题，现在可以正常使用了。

Answer 26

我最近在部署到Service Fabric时遇到了这个问题。该错误表明一个“文件”正在使用中，但是，我发现该端口正在被另一个IDE使用。通过停止已经在端口上托管的正在运行的服务，我能够阻止发生此异常。

Answer 27

最近在尝试构建我正在开发的解决方案（不仅仅是winforms proj）时遇到了这个问题 除了build失败之外，我注意到清理项目会悄然失败（检查bin文件夹显示文件实际上没有被删除）并且关闭Visual Studio并没有结束devenv进程 - 而是，它导致它崩溃。然后，Windows恢复过程将重新启动Visual Studio。

经过一些试验和错误后，我发现当我在启动VS时从“最近”菜单打开解决方案时，问题才发生在我身上。 从File >> Open >> Project/Solution打开解决方案，发现它通常正常工作。

目前不知道为什么 - 会继续关注这一点，但至少现在，至少我可以工作！

Answer 28

对于那些使用Docker在VS中进行开发的人，请重新启动Windows服务的docker，该问题将立即得到解决。

在重新启动docker之前，我尝试了所有提到的答案，没有找到运行的msbuild.exe进程，还尝试了无济于事地重新启动VS，仅重新启动了docker即可。

Answer 29

当我结束流程.Net Core Host时，一切正常。我不必关闭Visual Studio或进行其他任何更改。

Answer 30

同样的错误，通过更新Google Nuget支持包解决了

Answer 31

您的网络应用是如何配置的？它是在Cassini（托盘Web服务器）还是IIS下运行？

但这不应该正常发生。我认为ProcessExplorer可以告诉你进程锁定了哪些文件。如果不是，则使用其他sysinternals工具处理资源管理器。

在下载其中一个SI工具之前尝试的一件事是停止Cassini Web服务器，看看是否可以释放文件。

Answer 32

在我的情况下，有一些vstest进程在运行（有各种名称，但都包含字符串vstest）。我不得不在taskmgr中终止它们。

Answer 33

我也有同样的问题。更改调试/发布配置没有做到这一点。至少不是没有在两者之间建立。

在我的解决方案（winform）中，通过在设计器中打开winform的mainform来解决它。切换到代码（F7）。然后关闭代码，关闭winform的设计者并重建所有（ctrl-shift-B）。这对我有用。

似乎winform app中的某种句柄（运行后台工作者）仍然在其他一些库上使用了文件句柄。

Answer 34

我有两个Visual Studio实例打开了相同的解决方案。

Answer 35

遇到同样的问题，因此打开了任务管理器（错误提示该进程正在使用该进程），我的exe正在运行。我结束了任务，之后又恢复了正常