错误：无法访问文件bin / Debug / ...因为它正由另一个进程使用

Question

当我调试我的项目时，出现以下错误：

  

“无法将文件”obj \ Debug \ My Dream.exe“复制到”bin \ Debug \ My Dream.exe“。进程无法访问文件'bin \ Debug \ My Dream.exe'，因为它正在被另一个进程使用。“

使用Process Explorer，我看到MyApplication.exe已经关闭，但系统进程仍然使用它，尽管我之前停止了调试。 每当我更改代码并开始调试时，它都会发生。如果我将项目复制到USB并进行调试，则运行正常。

为什么呢？我该如何解决这个错误？

我使用Window 7 Professional。使用Xp我从未遇到过这个错误。

Answer 1

呃，这是一个老问题，偶尔会出现在Visual Studio中。它被我咬了几次而且我已经失去了几小时重新启动并与VS战斗。我相信这里已经不止一次地讨论了这个问题。它也在MSDN论坛上被讨论过。没有实际的解决方案，但有几种解决方法。 Start researching here

正在发生的事情是VS正在获取文件锁定然后不释放它。具有讽刺意味的是，该锁定会阻止VS自身删除文件，以便在重建应用程序时重新创建它。唯一明显的解决方案是关闭并重新启动VS，以便释放对文件的锁定。

我原来的解决方法是打开bin / Debug文件夹并重命名可执行文件。如果已锁定，则无法删除，但您可以重命名。因此，您只需在末尾添加一个数字或其他内容，这样您就可以继续工作而无需关闭所有窗口并等待VS重新启动。 Some people have even automated this using a pre-build event将随机字符串附加到旧输出文件名的末尾。是的，这是一个巨型黑客，但这个问题变得令人沮丧和虚弱，你会做任何事情。

我稍后经过一些实验后才知道，当你打开一个设计师的时候，这个问题似乎只会出现。所以，对我来说长期工作并且阻止我再次处理其中一个愚蠢错误的解决方案是确保在构建WinForms项目之前我总是关闭所有设计器窗口。是的，这也有些不方便，但它肯定会让裤子不得不每小时重启VS两次或更多。

我认为这也适用于WPF，虽然我没有使用它并且没有亲身经历过那里的问题。

我还没有尝试在VS 2012 RC上再现它。我不知道它是否已在那里修复过。但到目前为止，我的经验是，即使在微软声称修复它之后，它仍然可以弹出。它仍然存在于VS 2010 SP1中。我不是说他们的程序员是白痴，他们当然不知道他们在做什么。我认为这个bug只有多种原因和/或在实验室中很难可靠地再现。这就是我没有亲自提交过任何错误报告的原因（虽然我已经和其他人一样），因为我似乎无法可靠地重现它，而不是像恶劣的雪人。

_{＆lt;结束咆哮，特别针对没有人＆gt;}

Answer 2

我之前就已经出现过这个错误，即使在Visual Studio 2008中也是如此。它在Visual Studio 2012中更为流行。

这就是我的工作。

将其粘贴在麻烦项目的预构建事件中：

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Answer 3

计算机（右键单击） - ＆gt;管理 - ＆gt;服务与发展申请 - ＆gt;服务 - ＆gt;启用应用程序体验

为我工作！

Answer 4

我在Visual Studio 2013中遇到了同样的问题。我不确定是什么导致了我的项目，但我能够通过清理解决方案并重建它来修复它。

1. 构建＆gt;清洁解决方案
2. 构建＆gt;重建解决方案

Answer 5

至少在我的情况下，我注意到visual studio 2012创建了至少两个msbuild.exe鬼进程，这些进程在构建后没有消失。这些僵尸显然导致文件锁定出现。

杀死msbuild.exe是一次性解决方案，需要在每个构建的基础上完成。

但后来我发现我可以一劳永逸地禁用并行构建 - 进入工具＆gt;选项＆gt;项目和解决方案＆gt;构建并运行＆gt; “并行项目构建的最大数量” - 默认情况下它的值为8，我已切换为1.像魅力一样工作。

当然构建现在有点慢，但比抱歉更安全。 至少对于这个特殊的小项目，我不需要多个构建线程。

Answer 6

如果您在运行单元测试时遇到此问题，请参阅我的回答here。答案复制如下：

  

在Sébastien的回答的基础上，我在测试中添加了一个预构建步骤   项目仍然自动杀死任何vstest.*可执行文件   运行。以下预构建命令对我有用：

taskkill /f /im vstest.*
exit 0

     

exit 0命令结束时防止构建失败   没有运行vstest.*个可执行文件。

Answer 7

我知道这是一个老问题。不幸的是，我在.net core 2.0中的visual studio 2017应用程序中遇到了同样的问题。因此，我想分享对我有用的解决方案。在此解决方案之前，我尝试了以下步骤。

1. 重新启动Visual Studio
2. 关闭了所有应用程序
3. 清理我的解决方案并重建

以上所有步骤均不能解决问题。

然后我打开Task Manager并选择dotnet进程，然后单击“结束任务”按钮。后来我打开了Visual Studio，一切正常。

Answer 8

最近我遇到了与Visual Studio 2012有相同错误描述的问题：“进程无法访问该文件，因为它正被另一个进程使用...”

首先要解决这个问题，你需要了解仍然使用它的应用程序。我已关闭所有进程，如“MSBuild”和“MSBuild host”。但这还不够。如果您已安装“代码合同”并已启用，则有时会使用您的DLL进行检查并挂断此操作。

因此，您需要停止“CCCheck.exe”的所有进程，这就是全部。

最后，要了解该进程正在使用您的DLL，您总是可以尝试在文件管理器中删除“obj”文件夹，此操作将失败，您可能会看到“消息窗口”，其中包含挂起操作的说明。此外，作为变体，您可以尝试使用“Sys Internals Suite”应用程序。

Answer 9

为我工作。 任务管理器 - ＆gt;项目名称 - ＆gt;结束任务。 （我的项目名称有3个相同的流程）;

VS 2013;赢8;

Answer 10

确保以前运行的任何应用程序（例如，启动时没有调试选项）实际上已停止。我正在开发一个WPF应用程序，在没有调试的情况下启动，并在我不断收到错误时将其最小化。关闭应用程序后，VS行为恢复正常。

Answer 11

在我的情况下，我已启用＆＃34;显示所有文件＆＃34;。 Visual Studio 2017

Answer 12

我在Visual Studio 2017中一直受到这个问题的困扰。它大约在两三个星期前开始，并严重影响了我的工作效率。清洁和Rebulid没有工作;即使重新启动我的机器也无法完成这项任务。

解决这个问题的一种方法是清理有问题的程序集，然后构建（而不是重建）之后要立即运行的项目。这大约占30％的时间。

但是，我发现可能最可靠的解决方案是打开开发人员命令提示符，并直接使用msbuild。我过去三天一直这样做，到目前为止，这个问题还没有发生过一次。

Answer 13

我解决了这个问题。

在调试附近，您会看到带有某些配置的下拉菜单。默认情况下有任何CPU。选择x86并运行将运行的程序。如果没有x86，请转到配置管理器并添加x86

Answer 14

运行taskmanager。
找到netcore并将其删除。
然后，您可以手动删除文件，也可以通过运行Clean删除文件。

Answer 15

我也遇到过同样的问题，但是以上答案都对我没有帮助！我只是简单地关闭了Visual Studio 2017，然后重新运行它，就可以了！

Answer 16

我已经开了一个关于VS 2017的separate question，在一次更新后有类似的行为。这个问题似乎是由防病毒程序产生的。

我已将bin文件夹添加到防病毒排除列表，重新启动计算机，现在它似乎正常工作。

Answer 17

关闭VisualStudio，ctrl-alt-delete，选择任务管理器，查找并结束所有MSBuild进程 - VisualStudio基本上有一个非常严重的错误，它失去了对其调试器的控制，调试器维护了对.pdb文件的锁定debug / bin文件夹。结束所有MSBuild（调试器）进程后，删除/ debug / bin文件夹并在Visual Studio中重新打开解决方案。你现在好好去。微软需要解决这个问题。

Answer 18

我的问题是dotnet挂断了，每当VS尝试创建一个新的dll或访问旧的dll时，dotnet进程会锁定到dll并阻止visual studio克隆dll。解决方案只是结束任务管理器中的所有dotnet任务（它只会实际删除死亡的任务，如果你试图结束它并且它不会关闭，这意味着它正在工作）。

Answer 19

我发现Cody Gray的答案部分有用，因为它确实引导我找到了我们有些人可能遇到的问题的真正根源：Visual studio的测试执行默认保持打开状态并保持对文件的锁定。

要停止这种无用的行为，请按照https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel

中的说明操作

取消选中“测试”菜单 - ＆gt;测试设置 - ＆gt; ＆＃34;让测试执行引擎保持运行＆＃34;

Answer 20

一个简单的解决方案是你去bin \ Debug文件夹，删除该文件夹中的所有文件，然后重建。如果它不起作用，请关闭Visual Studio，然后使用文件资源管理器转到bin \ Debug文件夹，在左侧转向，单击文件＆gt;打开命令提示符＆gt;以管理员身份打开命令提示符＆gt;输入此命令“DEL / F / Q / A *”＆gt;然后重建

Answer 21

[已解决]错误：无法访问文件bin / Debug / ...因为它正由另一个进程使用：

我正在接近你在尝试一个接一个地运行两个窗口时遇到这个错误，比如先加载一个表单，然后有时它会自动消失，第二个表单加载到屏幕上。

基本上，您需要关闭在后台运行的第一个表单以及此错误背后的主要原因。

要关闭第一个表单，您必须在第二个表单加载事件处理程序中添加这两行代码。

    Form1 form = new Form1();
    form.Close();

这将完美地解决错误。

Answer 22

预构建命令

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

的帮助下

Answer 23

我遇到了同样的问题，我发现在后台有实际运行多种Windows窗体应用程序。如果您的应用程序有两个表单并且您关闭第二个表单而不是您的主表单，则会发生这种情况，因此应用程序将不会完全退出。

我经常运行我的应用程序

• 通过其exe或
• 无需调试即可运行

解决方案是关闭Windows窗体应用程序的另一个实例。 这是one始终关闭应用程序实例的方法。

Answer 24

我尝试了所有这些建议以及其他地方发现的其他建议，唯一对我有用的就是重新启动计算机。然后我做了一个干净的解决方案，然后重建。我使用Visual Studio 2013作为参考。

Answer 25

我发现没有关闭表单或重新启动VisualStudio的最快方法是转到项目的编译页面并单击“高级编译选项...”按钮。然后对其中一个选项进行任何更改（例如，将“生成调试信息”从“完整”更改为“仅限pdb”），然后单击“确定”。 它每次都有效，直到MS修复了这个bug（直到我从VS2012切换到VS2013之前我才遇到过这个问题）

另外请注意，如果您无法清理项目或解决方案，则无法构建。这些文件肯定被VS锁定（不是防病毒问题，至少在我的情况下不是这样）

Answer 26

可能为时已晚。但是，我遇到了类似的问题，在我的情况下，该项目有自我参考。因此，从References中删除它就像一个魅力!!!

Answer 27

这是纯粹的推测，而不是答案。

然而，我一直有这个问题。

我过了一段时间怀疑VS和我的AV预防措施之间的互动。

经过一段时间的播放后，当我修改我的杀毒软件时，似乎可能已经消失了

C：\ Users [用户名] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

文件夹未包含在实时保护中。

看起来构建实际上首先在此处写入DLL，然后将其复制到最终构建位置。

Answer 28

另一个kludge，呃，但它很容易在VS 2013中为我工作。点击该项目。在属性面板中，应该是名为Project File的条目，其值为

（您的项目名称）.vbproj

更改项目名称 - 例如在末尾添加-01。锁定的原始.zip文件仍然存在，但不再引用...因此您的工作可以继续。下次重新启动计算机时，该锁定会消失，您可以删除错误文件。