当我调试我的项目时，我收到以下错误：
“无法将文件“obj\Debug\My Dream.exe”复制到“bin\Debug\My Dream.exe”。该进程无法访问文件“bin\Debug\My Dream.exe”，因为它正在被其他人使用过程。”
使用 Process Explorer，我看到 MyApplication.exe 已退出，但系统进程仍在使用它，尽管我之前停止了调试。每当我更改代码并开始调试时，它都会发生。如果我将项目复制到 USB 并调试，它运行正常。
为什么？我该如何解决这个错误？
我使用 Window 7 专业版。使用 Xp 我从来没有遇到过这个错误。
呃，这是一个老问题，在 Visual Studio 中仍然偶尔会出现。它咬了我好几次，我已经失去了几个小时重新启动和与 VS 战斗。我敢肯定它已经在这里讨论过不止一次了。MSDN 论坛上也讨论过它。没有实际的解决方案，但有几个解决方法。在这里开始研究。
发生的事情是 VS 正在获取文件上的锁，然后不释放它。具有讽刺意味的是，该锁会阻止 VS 本身删除文件，以便在您重建应用程序时重新创建它。唯一明显的解决方案是关闭并重新启动 VS，以便它释放文件上的锁定。
我最初的解决方法是打开 bin/Debug 文件夹并重命名可执行文件。如果它被锁定，你不能删除它，但你可以重命名它。因此，您可以在末尾添加一个数字或其他内容，这样您就可以继续工作，而无需关闭所有窗口并等待 VS 重新启动。有些人甚至使用预构建事件将随机字符串附加到旧输出文件名的末尾来自动执行此操作。是的，这是一个巨大的黑客，但这个问题变得如此令人沮丧和衰弱，以至于你会做任何事情。
我后来了解到，经过更多的实验，这个问题似乎只有在您打开其中一位设计师的情况下构建项目时才会出现。因此，长期为我工作并阻止我再次处理这些愚蠢错误之一的解决方案是确保我始终在构建 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 中遇到了同样的问题。我不确定是什么原因导致我的项目出现这种情况，但我能够通过清理解决方案并重建它来修复它。
我知道这是一个老问题。不幸的是，我.net core 2.0在visual studio 2017. 所以，我想分享对我有用的解决方案。在此解决方案之前，我尝试了以下步骤。
以上步骤都没有解决问题。
然后我打开我Task Manager选择的dotnet进程，然后单击结束任务按钮。后来我打开了我的 Visual Studio，一切正常。
至少在我的情况下，我注意到 Visual Studio 2012 正在创建至少两个 msbuild.exe 幽灵进程，这些进程在构建后并没有消失。这些僵尸显然导致文件锁出现。
杀死 msbuild.exe 是一次性解决方案，需要在每个构建基础上完成。
但是后来我发现我可以一劳永逸地禁用并行构建-进入工具>选项>项目和解决方案>构建和运行>“并行项目构建的最大数量”-默认情况下它的值为8，我'已经切换到 1。像魅力一样工作。
当然，现在构建速度有点慢，但安全总比后悔好。至少对于这个特殊的小项目，我不需要多个构建线程。
如果您在运行单元测试时遇到此问题，请在此处查看我的答案。答案复制如下：
基于 Sébastien 的回答，我在我的测试项目中添加了一个预构建步骤，以自动终止任何
vstest.*仍在运行的可执行文件。以下预构建命令对我有用：taskkill /f /im vstest.* exit 0该
exit 0命令位于末尾，以防止在没有vstest.*可执行文件运行时构建失败。
为我工作。任务管理器 -> 项目名称 -> 结束任务。（我的项目名称有 3 个相同的流程）；
与 2013 年相比；赢8；
最近我在使用 Visual Studio 2012 时遇到了同样的错误描述：“该进程无法访问该文件，因为它正在被另一个进程使用......”
要解决此问题，首先您需要了解仍在使用它的应用程序。我已经关闭了“MSBuild”和“MSBuild 主机”等所有进程。但这还不够。如果您已安装“代码合同”并打开，则有时需要您的 DLL 来检查并挂断此操作。
因此，您需要停止“CCCheck.exe”的所有进程，仅此而已。
最后，要了解该进程正在使用您的 DLL，您总是可以尝试在文件管理器中删除“obj”文件夹，此操作将失败，您可能会看到“消息窗口”，其中描述了挂起操作。此外，作为变体，您可以尝试使用“Sys Internals Suite”应用程序。
就我而言，我启用了“显示所有文件”。视觉工作室 2017
我在 Visual Studio 2017 中一直受到这个问题的困扰。它大约在两三周前开始，严重影响了我的工作效率。Clean 和 Rebulid 没有用；即使重新启动我的机器也无法完成这项工作。
处理该问题的一种方法是清理有问题的程序集，然后构建（而不是重新构建）您想要在之后立即运行的项目。这大约有 30% 的时间有效。
但是，我发现的最可靠的解决方案可能是打开开发人员命令提示符，然后msbuild直接使用。我过去三天一直在这样做，到目前为止，问题还没有发生过一次。
我解决了这个问题..
在调试附近，您会看到带有一些配置的下拉菜单。默认有任何 CPU。选择 x86 并运行它将运行的程序。如果没有 x86，请转到配置管理器并添加 x86
确保应用程序的任何先前运行（例如，在没有调试选项的情况下启动）实际上已停止。我正在开发一个 WPF 应用程序，没有调试就开始了，当我不断收到错误时将其最小化。关闭应用程序 VS 行为后恢复正常。
运行taskmanager。
找到netcore并删除它。
然后，您可以手动删除该文件，也可以运行Clean.
这是纯粹的猜测，而不是答案。
但是，我遇到这个问题已经有一段时间了。
一段时间后，我怀疑 VS 和我的 AV 预防措施之间存在相互作用。
玩了一段时间后，好像我修改了我的杀毒软件后它可能已经消失了，所以下面的所有内容
C:\Users[用户名]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
文件夹未包含在实时保护中。
看起来好像构建实际上首先在此处写入 DLL，然后将其复制到最终构建位置。
可能为时已晚。但是，我遇到了类似的问题，就我而言，该项目有自我参考。因此，从参考文献中删除它就像一个魅力！！！
我发现不关闭表单或重新启动 VisualStudio 的最快方法是转到项目的编译页面并单击“高级编译选项...”按钮。然后对其中一个选项进行任何更改（例如，将 Generate Debug Info 从 Full 更改为 pdb-only），然后单击 OK。它每次都有效，并且必须这样做，直到 MS 修复了这个错误（在我从 VS2012 切换到 VS2013 之前，我从来没有遇到过这个问题）
另请注意，如果您无法清理项目或解决方案，它将无法构建。这些文件肯定被VS锁定（不是防病毒问题，至少在我的情况下不是）
预编译命令
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
帮助
我尝试了所有这些建议以及在其他地方找到的其他建议，唯一对我有用的是重新启动计算机。然后我做了一个干净的解决方案，然后重建。我正在使用 Visual Studio 2013 作为参考。
关闭 VisualStudio，按 ctrl-alt-delete，选择任务管理器，找到并结束所有 MSBuild 进程 - VisualStudio 基本上有一个非常严重的错误，它失去对其调试器的控制，并且调试器保持对 debug/bin 中 .pdb 文件的锁定文件夹。结束所有 MSBuild（调试器）进程后，删除 /debug/bin 文件夹并在 Visual Studio 中重新打开解决方案。你现在可以走了。微软需要解决这个问题。
我的问题是 dotnet 挂断了，每当 VS 尝试制作新的 dll 或访问旧的 dll 时，dotnet 进程都会锁定 dll 并阻止 Visual Studio 克隆 dll。解决方案只是在任务管理器中结束所有 dotnet 任务（它只会真正删除死的任务，如果你试图结束一个并且它不会关闭，这意味着它正在工作）。
一个简单的解决方案是转到 bin\Debug 文件夹，删除该文件夹中的所有文件，然后重新构建。如果它不起作用，请关闭 Visual Studio，然后使用文件资源管理器转到 bin\Debug 文件夹，在左侧角落，单击文件>打开命令提示符>以管理员身份打开命令提示符>输入此命令“DEL /F /Q / A *" > 然后重建
我遇到了同样的问题，但以上答案都没有帮助我！我只是简单地关闭了我的 Visual Studio 2017 然后重新运行它，它成功了！
我已经打开了一个关于 VS 2017 的单独问题，该问题在一次更新后具有类似的行为。该问题似乎是由防病毒程序产生的。
我已将 bin 文件夹添加到防病毒排除列表中，重新启动机器，现在它似乎可以工作了。
[已解决] 错误：无法访问文件 bin/Debug/... 因为它正被另一个进程使用：
我正在接近您在尝试一个接一个地运行两个窗口时遇到此错误，例如首先加载一个表单，然后有时它会自动消失并将第二个表单加载到屏幕上。
基本上，您需要关闭在后台运行的第一个表单以及此错误背后的主要原因。
要关闭第一个表单，您必须在第二个表单加载事件处理程序中添加这两行代码。
Form1 form = new Form1();
form.Close();
这将完美地解决错误。
我遇到了同样的问题，我发现实际上在后台运行了多个 Windows 窗体应用程序。当您的应用程序有两个表单并且您关闭不是主表单的第二个表单时，就会发生这种情况，因此应用程序不会完全退出。
我通常运行我的应用程序
解决方法是关闭 Windows 窗体应用程序的其他实例。这是始终关闭应用程序实例的一种方法。
我发现 Cody Gray 的回答部分有帮助，因为它确实引导我找到了你们中的一些人可能也遇到的问题的真正根源：Visual Studio 的测试执行默认保持打开状态并保持对文件的锁定。
取消选中测试菜单 -> 测试设置 -> “保持测试执行引擎运行”
另一个kludge，呃，但它很容易并且在VS 2013中对我有用。单击项目。在属性面板中应该有一个名为 Project File 的条目，其中包含一个值
（您的项目名称）.vbproj
更改项目名称 - 例如在末尾添加 -01。被锁定的原始 .zip 文件仍然存在，但不再被引用……因此您的工作可以继续。下次重新启动计算机时，该锁定将消失，您可以删除错误文件。