错误: 无法访问文件 bin/Debug/... ，因为它正被其他进程使用

呃，这是个老问题了，在 Visual Studio 中偶尔还会出现。它咬了我几次，我已经失去了几个小时重新开始和战斗与 VS 我肯定这里已经讨论了这么多次。在 MSDN 论坛上也有讨论。目前还没有实际的解决方案，但是有一些变通方法。从这里开始调查.

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

我最初的解决方案是打开 bin/Debug 文件夹并重命名可执行文件。如果它是锁定的，你不能对它进行 删除，但是你可以重命名它。所以你可以在结尾添加一个数字，这样你就可以继续工作，而不必关闭所有窗口，等待 VS 重新启动。有些人甚至使用预构建事件将其自动化将一个随机字符串附加到旧输出文件名的末尾。是的，这是一个 巨人黑客，但这个问题变得如此令人沮丧和虚弱，你会做任何事情。

I've later learned, after a bit more experimentation, that the problem seems to only crop up when you build the project with one of the designers open. So, the solution that has worked for me long term and prevented me from ever dealing with one of those silly errors again is making sure that I always close all designer windows before building a WinForms project. Yes, this too is somewhat inconvenient, but it sure beats the pants off having to restart VS twice an hour or more.

我假设这也适用于 WPF，尽管我没有使用它，也没有亲身经历过这个问题。

I also haven't yet tried reproducing it on VS 2012 RC. I don't know if it's been fixed there yet or not. But my experience so far has been that it still manages to pop up even after Microsoft has claimed to have fixed it. It's still there in VS 2010 SP1. I'm not saying their programmers are idiots who don't know what they're doing, of course. I figure there are just multiple causes for the bug and/or that it's very difficult to reproduce reliably in a laboratory. That's the same reason I haven't personally filed any bug reports on it (although I've +1'ed other peoples), because I can't seem to reliably reproduce it, rather like the Abominable Snowman.

_{< 不针对任何人的最后咆哮 >}

电脑(右击)-> 管理-> 服务及应用程式-> 服务-> 启用应用程式体验

Worked For me!

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

然而，这个问题我已经有一段时间了。

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

打了一会之后，好像 may已经走了，当我修改我的杀毒软件的时候，让一切都下了

C:\Users[username]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

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

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

Recently I've been in a trouble with Visual Studio 2012 with same error description: "The process cannot access the file because it is being used by another process..."

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

So, you need to stop all processes of "CCCheck.exe" and that's all.

最后，为了理解进程正在使用您的 DLL，您总是可以尝试删除“ obj”文件夹在您的文件管理器和这个操作将失败，您可能会看到“消息窗口”与挂起操作的描述。另外，作为一个变体，您可以尝试使用“ Sys Internals Suite”应用程序。

我以前遇到过这个错误，甚至在 VisualStudio2008中也是如此。它又回来了，并且在 VisualStudio2012中更加流行。

我是这么做的。

将其粘贴到麻烦的项目的预构建事件中:

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

可能已经太迟了。但是，我遇到了类似的问题，在我的情况下，项目有自我参考。因此，从参考文献中删除它像一个魅力! ! ！

另一个组装程序，呃，但是它很简单，在 VS 2013中对我很有用。点击项目。在属性面板中应该有一个名为 ProjectFile 的项，其值为

(您的项目名称)

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

对我有用。 任务管理器-> 项目名称-> 结束任务。(我有3个相同的过程与我的项目名称) ;

VS 2013;

如果在运行单元测试时遇到此问题，请参阅我的答案 给你:

Building upon Sébastien's answer, I added a pre-build step to my test 项目自动杀死任何 vstest.*可执行文件仍 下面的预构建命令对我很有用:

taskkill /f /im vstest.*
exit 0

最后的 exit 0命令是为了防止生成失败 没有运行 vstest.*可执行文件。

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

1. Build > Clean Solution 建造 > 清洁解决方案
2. 生成 > 重建解决方案

I've found the quickest way without closing forms or restarting VisualStudio is go to the project's compile page and click "Advanced Compile Options..." button. Then make any change to one of the options (say, changing Generate Debug Info from Full to pdb-only), then click OK. 它每次都能正常工作，直到微软修复这个 bug (我从来没有遇到过这个问题，直到我从 VS2012切换到 VS2013)

另一个注意事项是，如果您不能清理项目或解决方案，它将无法构建。这些文件肯定是被 VS 锁定的(不是防病毒问题，至少在我的情况下不是)

我尝试了所有这些建议以及其他地方发现的其他建议，唯一对我有效的就是重新启动我的电脑。然后我做了一个干净的解决方案，然后重建。我正在使用 VisualStudio2013作为参考。

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

At least in my case I've noticed that visual studio 2012 was creating at least two msbuild.exe ghost processes, which did not perish after build. These zombies apparently are causing file locks to appear.

杀死 msbuild.exe 的是一个时间的解决方案，它需要做每个构建的基础。

但是后来我发现我可以一劳永逸地禁用并行构建-进入工具 > 选项 > 项目和解决方案 > 构建和运行 > “最大数量的并行项目构建”-默认值为8，我已经切换到1。非常有效。

当然，现在构建速度有点慢，但安全总比遗憾好。 至少对于这个特殊的小项目，我不需要一个以上的构建线程。

我也遇到过同样的问题，我发现背景中有 实际运行多个 Windows 表单应用程序。当你的应用程序有两种形式，你关闭的 二年级不是你的 主要表格，所以应用程序不会完全退出时，就会发生这种情况。

我通常运行我的应用程序

• 通过它的前任或者
• run without debugging

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

预生成命令

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

Helped

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

我接近你得到这个错误，当你试图运行两个窗口形式一个接一个，如第一次加载表单后，有时它会自动消失，第二个表单加载到屏幕上。

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

To close the first form you have to add these two lines of code in the second form load event handler.

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

这将完美地解决这个错误。

一个简单的解决方案是进入 bin Debug 文件夹，删除该文件夹中的所有文件，然后重新构建。如果不起作用，关闭 Visual Studio，然后使用文件资源管理器进入 bin Debug 文件夹，在左边的角落，点击 File > Open Command Prompt > Open Command Prompt as Administrator > 输入这个命令“ DEL/F/Q/A *”> 然后重建

在 VisualStudio2017中，这个问题一直困扰着我。大约两三周前开始的，严重影响了我的工作效率。Clean 和 Rebuild 都不起作用; 甚至重新启动我的机器也不起作用。

处理这个问题的一种方法是清理有问题的程序集，然后生成(而不是重新生成)您希望立即运行的项目。这种方法在30% 的情况下有效。

然而，我发现的最可靠的解决方案可能是打开一个 Developer Command Prompt，并直接使用 msbuild。过去三天我一直在做这个，到目前为止，这个问题一次也没有发生过。

在我的例子中，我启用了“显示所有文件”。 Visual Studio 2017

我发现科迪 · 格雷的回答部分有帮助，因为它确实指引我找到了问题的真正根源，你们中的一些人可能也正在经历这个问题: 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，选择 Task Manager，查找并结束所有 MSBuild 进程—— VisualStudio 基本上有一个非常严重的错误，它失去了对调试器的控制，调试器在。在 debug/bin 文件夹中的 pdb 文件。结束所有 MSBuild (调试器)进程后，删除/debug/bin 文件夹并在 VisualStudio 中重新打开解决方案。你可以走了。微软需要解决这个问题。

我已经打开了一个关于 VS2017的 另一个问题，在一次更新后有类似的行为。这个问题似乎是由反病毒程序产生的。

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

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

1. 重启视觉工作室
2. 结束了所有的申请
3. 清理我的解决方案，重建

上述步骤都没有解决问题。

然后我打开我的 Task Manager和选择 dotnet进程，然后点击结束任务按钮。后来我打开了我的视觉工作室，一切都很好。

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

我解决了这个问题。

near the debug you see drop down menu with some configuration. Default there was Any CPU. Select x86 and run the program it will work. If x86 not there go to configuration manager and add the x86

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

I've tried every answered here and this worked for me

1. 关闭项目。
2. 停止在任务管理器中运行任务
3. 重启你的电脑
4. 再次打开并生成项目

对我很有效。

我得到这个错误是因为我正在运行我的解决方案，但不是在调试模式下。我忘了这个。我意识到了这一点，并停止了我的解决方案运行。这就解决了问题。