错误：无法访问文件bin / Debug / …，因为它正在被另一个进程使用
当我debugging我的项目，我得到以下错误：
“无法将文件”obj \ Debug \ My Dream.exe“复制到”bin \ Debug \ My Dream.exe“。进程无法访问文件”bin \ Debug \ My Dream.exe“，因为它被另一个处理。”
使用进程资源pipe理器，我看到MyApplication.exe出来了，但系统进程仍然使用它，虽然我停止debugging之前。 每当我改变我的代码，并开始debugging它将发生。 如果我将项目复制到USB并debugging，它运行正常。
为什么？ 我该如何解决这个错误？
我使用Window 7 Professional。 用XP我从来没有得到这个错误。
呃，这是一个老问题，在Visual Studio中偶尔会popup一个问题。 它咬了我几次，我已经失去了几个小时重新开始，并与VS战斗。 我确信这不止一次地在这里讨论过。 这也是在MSDN论坛上讨论的。 没有一个实际的解决scheme，但有几个解决方法。 从这里开始研究 。
发生什么事情是，VS正在获取一个文件locking，然后不释放它。 具有讽刺意味的是，该锁可以防止VS本身删除该文件，以便重build应用程序时可以重新创build该文件。 唯一明显的解决办法是closures并重新启动VS，以便释放文件的locking。
我原来的解决方法是打开bin / Debug文件夹并重命名可执行文件。 如果locking，则不能删除 ，但可以重命名。 所以你可以在最后添加一个数字或者什么东西，这样你就可以继续工作，而不必closures所有的窗口，等待VS重启。 有些人甚至使用预生成事件来自动执行此操作，以将随机string追加到旧输出文件名的末尾。 是的，这是一个巨大的黑客，但这个问题变得如此令人沮丧和虚弱，你会做任何事情。
后来我经历了一些更多的实验后才知道，只有当你打开一个devise者才能build立这个项目的时候，这个问题才会出现。 所以，长期为我工作的解决scheme，阻止我再次处理这些愚蠢的错误之一是确保我总是closures所有的devise器窗口之前build立一个WinForms项目。 是的，这也有点不方便，但是它肯定会跳过一个小时或更长时间重新启动VS的裤子。
我认为这也适用于WPF，虽然我不使用它，并没有亲自经历过那里的问题。
我还没有尝试在VS 2012 RC上复制它。 我不知道那里是否已经修好了。 但是迄今为止我的经验是，即使微软声称已经修复它，它仍然能够popup。 它仍然在VS 2010 SP1中。 当然，我不是说他们的程序员是不知道自己在做什么的笨蛋。 我认为这个错误有很多原因，并且/或者在实验室中很难可靠地复制。 这也是我没有亲自提交任何bug报告的原因（虽然我已经为其他人民+1了），因为我似乎无法可靠地重现它，而不是像可恶的雪人。
<针对没有人特别的结束咆哮>
我以前曾经遇到过这个错误，即使在Visual Studio 2008中也是如此。它在Visual Studio 2012中回来了，并且更为stream行。
这是我做的。
将其粘贴到麻烦项目的预生成事件中：
if exist "$(TargetPath).locked" del "$(TargetPath).locked" if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked" 计算机（右键单击） – >pipe理 – >服务和应用程序 – >服务 – >启用应用程序体验
为我工作！
我在Visual Studio 2013中遇到了同样的问题。我不确定是什么导致了我的项目，但是我能够通过清理解决scheme并重build它来修复它。
- 构build>清洁解决scheme
- Build>重build解决scheme
至less在我的情况下，我已经注意到，Visual Studio 2012创build至less两个msbuild.exe幽灵进程，并没有在构build后消失。 这些僵尸显然是导致文件locking出现。
杀死msbuild.exe的是一次性的解决scheme，它需要每个构build的基础上完成。
但后来我发现我可以一劳永逸禁用并行构build – 进入工具>选项>项目和解决scheme>构build和运行>“最大数量的并行项目构build” – 默认情况下它的值为8，I已经切换到1.工作像魅力。
当然，build设现在有点慢，但比对不起更安全。 至less对于这个特定的小项目，我不需要多个构build线程。
如果在运行unit testing时遇到此问题，请在此处查看我的答案。 复制如下：
基于Sébastien的回答，我在testing项目中添加了一个预构build步骤，以自动
vstest.*任何仍在运行的vstest.*可执行文件。 下面的预build命令为我工作：taskkill /f /im vstest.* exit 0当没有
vstest.*可执行文件正在运行时，exit 0命令将在最后防止生成失败。
最近，我一直在使用Visual Studio 2012的错误描述相同的错误：“进程无法访问该文件，因为它正在被其他进程使用…”
为了解决这个问题首先你需要了解那些仍然使用它的应用程序。 我closures了所有的进程，如“MSBuild”和“MSBuild主机”。 但这还不够。 如果你已经安装了“代码合同”并打开了，那么它有时会把你的DLL检查并挂起这个操作。
所以，你需要停止“CCCheck.exe”的所有进程，这就是全部。
最后，要了解该进程正在使用你的DLL，你总是可以尝试删除文件pipe理器中的“obj”文件夹，这个操作将会失败，你可能会看到挂起操作描述的“消息窗口”。 此外，作为一个变种，你可以尝试使用“Sys Internals Suite”应用程序。
为我工作。 任务pipe理器 – >项目名称 – >结束任务。 （我有3个与我的项目名称相同的进程）;
VS 2013; 赢8;
确保应用程序的任何以前的运行（例如，启动时没有debugging选项）实际上已停止。 我正在开发一个WPF应用程序，开始时不进行debugging，并在不断收到错误时将其最小化。 closures应用程序后，VS行为恢复正常。
在我的情况是，我已启用“显示所有文件”。 Visual Studio 2017
这是纯粹的猜测，而不是一个答案。
不过，我一直有这个问题。
一段时间后，我怀疑VS和我的防病毒预防措施之间的互动。
经过一番玩，似乎它可能已经消失，当我修改我的杀毒软件，以便下的一切
C：\用户[名] \ AppData \本地\微软\ VisualStudio的\ 10.0 \ ProjectAssemblies
文件夹不包含在实时保护中。
它看起来好像编译实际上首先在这里写DLL，然后将其复制到最终的构build位置。
可能为时已晚。 但是，我遇到了类似的问题，在我的情况下，这个项目有自己的参考。 因此，从引用中删除它像一个魅力工作！
我发现没有closures窗体或重新启动VisualStudio最快捷的方法是去项目的编译页面，然后单击“高级编译选项…”button。 然后对其中一个选项进行任何更改（例如，将生成debugging信息从完全更改为仅限pdb），然后单击确定。 它每次都有效，直到MS修复这个bug（我从来没有遇到这个问题，直到我从VS2012切换到VS2013）
另外请注意，如果您无法清理项目或解决scheme，则无法构build。 这些文件肯定是由VSlocking的（不是防病毒问题，至less不是我的情况）
我尝试了所有这些build议以及在别处find的其他build议，唯一对我有用的是重新启动计算机。 然后我做了一个干净的解决scheme，然后重build。 我正在使用Visual Studio 2013作为参考。
我已经运行到这个相同的问题，我发现实际上是在后台运行多个Windows窗体应用程序 。 它发生在你的应用程序有两种forms，而你closures第二种forms ，这不是你的主要forms，所以应用程序不会完全退出。
我通常运行我的应用程序
- 通过它的EXE或
- 没有debugging运行
解决scheme是closuresWindows窗体应用程序的另一个实例 。 这是一种总是closures应用程序实例的方法。
预build命令
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
帮助
[解决]错误：无法访问文件bin / Debug / …，因为它正在被另一个进程使用：
我接近，你得到这个错误，当你试图运行两个窗口一个接一个的forms，如首先加载一个窗体，然后有时会自动消失，第二个窗体加载到屏幕上。
基本上，您需要closures您在后台运行的第一个表单以及此错误背后的主要原因。
要closures第一个窗体，您必须在第二个窗体加载事件处理程序中添加这两行代码。
Form1 form = new Form1(); form.Close();
这将完美地解决错误。
一个简单的解决scheme是你去bin \ Debug文件夹，删除该文件夹中的所有文件，然后重build。 如果不起作用，closuresVisual Studio，然后使用文件浏览器进入bin \ Debug文件夹，在左侧的coner上，单击File> Open Command Prompt>以pipe理员身份打开命令提示符>input此命令“DEL / F / Q / A *“>然后重build
我一直在Visual Studio 2017中受到这个问题的困扰。它大约在两三个星期前就开始了，并且严重侵蚀了我的生产力。 清洁和再造不起作用; 即使重新启动我的机器也不能完成这项工作。
处理这个问题的一个方法是清理违规的程序集，并且build立（而不是重build）你想要立即运行的项目。 这大概有30％的时间。
但是，可能我find的最可靠的解决scheme是打开一个开发人员命令提示符，并直接使用msbuild 。 过去三天我一直在这样做，到目前为止这个问题还没有发生过一次。
我发现Cody Gray的回答部分有帮助，因为它确实指导了我的问题的真实来源，您可能还会遇到一些问题：Visual Studio的testing执行保持默认打开状态，并对文件保持locking状态。
要停止这种占主导地位的无用行为，请按照https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-rtmrel
取消选中testing菜单 – >testing设置 – >“保持testing执行引擎运行”
我的问题是dotnet被挂断，每当VS尝试创build一个新的DLL，或访问一个旧的，dotnet进程将locking到DLL，并停止视觉工作室克隆DLL。 解决办法就是在任务pipe理器中结束所有的dotnet任务（只会实际删除死掉的任务，如果你试图结束一个，那么就意味着它正在工作）。
另一个混乱，呃，但它很容易，在VS 2013我的作品。点击该项目。 在属性面板中应该是一个名为Project File的项目，并带有一个值
（您的项目名称）.vbproj
更改项目名称 – 例如添加-01到最后。 被locking的原始.zip文件仍然存在，但不再被引用…所以您的工作可以继续。 下一次计算机重新启动时，该锁消失，您可以删除错误的文件。
