错误：无法访问文件bin / Debug /…，因为它正在被另一个进程使用

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

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

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

为什么？如何解决此错误？

我使用Window 7 Professional。使用Xp，我从来没有遇到这个错误。

gh，这是一个古老的问题，有时仍会在Visual Studio中弹出某些问题。它被我咬了好几次，我已经花了很多时间重新启动和与VS战斗。我敢肯定，这里已经讨论了不止一次。在MSDN论坛上也有讨论。没有实际的解决方案，但是有两种解决方法。在这里开始研究。

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

我最初的解决方法是打开bin / Debug文件夹并重命名可执行文件。如果它已锁定，则无法删除，但可以重命名。因此，您可以在末尾添加一个数字，这样您就可以继续工作而不必关闭所有窗口并等待VS重新启动。甚至有人使用pre-build事件将此操作自动化，以将随机字符串附加到旧的输出文件名的末尾。是的，这是一个巨大的骇客，但是这个问题令人沮丧和失望，您将无所不能。

后来，经过更多的实验，我才知道，似乎只有在其中一位设计师开放的情况下构建项目时，问题才会出现。因此，长期有效的解决方案使我无法再次处理这些愚蠢的错误之一，这是确保在构建WinForms项目之前始终关闭所有设计器窗口。是的，这也有点不方便，但可以确保不必每小时重新启动VS两次或更长时间。

我认为这也适用于WPF，尽管我不使用它，也没有亲身经历该问题。

我也尚未尝试在VS 2012 RC上重现它。我不知道它是否已经修复。但是到目前为止，我的经验是，即使微软声称已修复它，它仍然可以弹出。在VS 2010 SP1中仍然存在。当然，我并不是说他们的程序员是白痴，他们不知道自己在做什么。我认为错误的原因多种多样，并且/或者很难在实验室中可靠地复制。这就是我没有亲自提交任何错误报告的相同原因（尽管我已经为其他人+1），因为我似乎无法可靠地重现它，就像可恶的雪人一样。

_{<特别针对任何人的终极咆哮>}

甚至在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"

计算机（右键单击）->管理->服务和应用程序->服务->启用应用程序体验

为我工作！

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

1. 构建>清洁解决方案
2. 生成>重建解决方案

至少就我而言，我注意到Visual Studio 2012正在创建至少两个msbuild.exe鬼进程，该进程在构建后不会消失。这些僵尸显然导致文件锁定的出现。

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

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

当然，构建现在要慢一些，但是比后悔要安全得多。至少对于这个特定的小项目，我不需要多个构建线程。

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

1. 重新启动Visual Studio
2. 关闭所有申请
3. 清理我的解决方案并重建

上述步骤均不能解决问题。

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

如果在运行单元测试时遇到此问题，请在这里查看我的答案。答案复制如下：

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

taskkill /f /im vstest.*
exit 0

该exit 0命令位于结尾，以防止在没有vstest.*可执行文件运行时构建失败。

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

要首先解决此问题，您需要了解仍在使用它的应用程序。我已经关闭了“ MSBuild”和“ MSBuild host”之类的所有进程。但这还不够。如果您已经安装了“代码合同”并已打开，则有时需要使用DLL来检查并挂起此操作。

因此，您需要停止“ CCCheck.exe”的所有进程，仅此而已。

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

为我工作。任务管理器->项目名称->结束任务。（我的项目名称有3个相同的过程）；

VS 2013；赢8;

确保以前停止了该应用程序的所有先前运行（例如，启动而没有调试选项）。我正在开发WPF应用程序，无需调试即可启动，并且在不断收到错误时将其最小化。关闭应用程序后，VS行为恢复正常。

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

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

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

就我而言，我已启用“显示所有文件”。Visual Studio 2017

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

这纯粹是猜测，而不是答案。

但是，我已经有一段时间了这个问题。

过了一阵子，我开始怀疑VS和AV预防措施之间是否存在相互作用。

一些上场后，似乎它可能已经消失，当我修改我的防病毒使下一切

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

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

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

可能为时已晚。但是，我遇到了类似的问题，就我而言，该项目具有自我参考意义。因此，将其从参考文献中删除就像是一种魅力！！！

我发现不关闭表单或重新启动VisualStudio的最快方法是转到项目的编译页面，然后单击“高级编译选项...”按钮。然后对选项之一进行任何更改（例如，将“生成调试信息”从“完全”更改为“仅pdb”），然后单击“确定”。它每次都有效，直到MS修复此错误为止都必须做（直到我从VS2012切换到VS2013为止，我从未遇到过此问题）

另外请注意，如果您无法清理项目或解决方案，则将无法构建。文件绝对被VS锁定（不是防病毒问题，至少在我看来不是）

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

我遇到了同样的问题，发现实际上在后台运行了多种Windows窗体应用程序。当您的应用程序有两种形式并且您关闭了第二种形式（不是您的主要形式）时，就会发生这种情况，因此应用程序将不会完全退出。

我通常会运行我的应用程序

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

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

生成前命令

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

有帮助

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

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

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

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

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

这将完美解决错误。

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

我发现科迪·格雷（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

取消选中“测试”菜单->“测试设置”->“保持测试执行引擎运行”

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

关闭VisualStudio，按ctrl-alt-delete，选择“任务管理器”，找到并结束所有MSBuild进程-VisualStudio基本上有一个非常严重的错误，它失去了对调试器的控制，并且调试器在debug / bin中保持对.pdb文件的锁定。夹。结束所有MSBuild（调试器）进程后，删除/ debug / bin文件夹，然后在Visual Studio中重新打开解决方案。您现在可以出发了。Microsoft需要修复此废话。

我打开了一个关于VS 2017 的单独问题，该问题在一次更新后具有相似的行为。该问题似乎是由防病毒程序引起的。

我已将bin文件夹添加到防病毒排除列表中，重新启动了计算机，现在看来可以正常工作。

我解决了这个问题。

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

另一个麻烦，嗯，但这很简单，并且在VS 2013中对我有用。单击项目。在属性面板中应该是一个名为Project File的条目，其值

（您的项目名称）.vbproj

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