Visual Studio 构建失败：无法将 exe 文件从 obj\debug 复制到 bin\debug答案

【问题标题】：Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debugVisual Studio 构建失败：无法将 exe 文件从 obj\debug 复制到 bin\debug
【发布时间】：2011-02-23 03:58:08
【问题描述】：

更新： 可以在here at Microsoft Connect 找到重现此错误的示例项目。我还测试并验证了the accepted answer below 中给出的解决方案适用于该示例项目。如果此解决方案不适合您，您可能遇到了不同的问题（属于单独的问题）。

这是以前在 Stack Overflow 和其他地方提出的问题，但到目前为止我发现的任何建议都没有帮助我，所以我只需要尝试提出一个新问题。

场景：我有一个简单的 Windows 窗体应用程序（C#、.NET 4.0、Visual Studio 2010）。它有几个大多数其他表单继承自的基本表单，它使用实体框架（和 POCO 类）进行数据库访问。没有什么花哨的，没有多线程或任何东西。

问题：有一段时间一切都很好。然后，出乎意料的是，当我即将启动应用程序时，Visual Studio 未能构建。我收到警告 “无法删除文件 '...bin\Debug\[ProjectName].exe'。对路径 '...bin\Debug\[ProjectName].exe' 的访问被拒绝。” 和错误 “无法将文件 'obj\x86\Debug\[ProjectName].exe' 复制到 'bin\Debug\[ProjectName].exe'。进程无法访问文件 'bin\Debug \[ProjectName].exe'，因为它正被另一个进程使用。”（我在运行 Rebuild 时同时收到警告和错误，但在运行 Build 时只收到错误 - 认为这不相关吗？ )

我完全理解警告和错误消息所说的内容：Visual Studio 显然正试图覆盖 exe 文件，同时由于某种原因它同时被锁定。但是，这并不能帮助我找到问题的解决方案......我发现唯一有效的方法是关闭 Visual Studio 并重新启动它。构建和启动然后工作，直到我对某些表单进行更改，然后我再次遇到同样的问题并且不得不重新启动......非常令人沮丧！

正如我上面提到的，这似乎是一个已知问题，因此有很多建议的解决方案。我将在这里列出我已经尝试过的内容，以便人们知道要跳过的内容：

创建一个新的干净解决方案，然后从旧解决方案中复制文件。

将以下内容添加到项目的预构建事件中：

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

将以下内容添加到项目属性（.csproj 文件）中：

 <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

但是，它们都不适合我，因此您可能会明白为什么我开始有点沮丧。我不知道还能去哪里看，所以我希望有人能给我一些东西！这是VS中的一个错误，如果是，有补丁吗？还是我做错了什么，我有循环引用或类似的，如果有，我怎么能找到？

任何建议都非常感谢:)

更新：正如下面评论中提到的，我还使用 Process Explorer 检查了它实际上是锁定文件的 Visual Studio。

【问题讨论】：

您是否检查过您的应用程序是否正常关闭？任务管理器会在进程列表中显示 [ProjectName].exe 吗？
我以前有过这个，我只是将文件重命名为 .old 等并重新运行构建。不完全是我知道的修复方法，但它对我有用。
@miensol：是的，它似乎正确关闭。我得到“程序 '[1848] [ProjectName].vshost.exe: Managed (v4.0.30319)' 已退出，代码为 0 (0x0)。” @Barry：重命名 bin\Debug 中的 exe 文件是可行的，但正如你所说，这并不是一个真正的解决方案，每次都必须这样做会很烦人。虽然比重新启动 Visual Studio 好一点...
@Naliluj：我在微软论坛上看到this 的文章，它解释了它可能与资源文件有关。如果您使用的是 resx 文件，这可能会给出提示。
为了后代，我遇到了这个问题，通过将 true 元素添加到我的 csproj 文件中解决了这个问题。

标签： c# .net winforms visual-studio

【解决方案1】：

这听起来很愚蠢，但我尝试了所有这些解决方案，在 Windows 7 上运行 VS2010。除了重命名和构建，它们都不起作用，至少可以说非常乏味。最终，我找到了罪魁祸首，我很难相信。但是我在 AssemblyInfo.cs 中使用了以下代码...

[assembly: AssemblyVersion("2.0.*")]

这很常见，但出于某种原因，将版本更改为 2.0.0.0 会使事情再次正常运行。我不知道它是否是 Windows 7 特有的东西（我只使用了 3-4 周），或者它是随机的，还是什么，但它为我修复了它。我猜 VS 会保留它生成的每个文件的句柄，所以它会知道如何增加内容？我真的不确定，以前从未见过这种情况。但如果外面的其他人也在拔头发，试试看。

【讨论】：

这是一个疯狂的想法，我会给你的 ;) 更疯狂的是，它实际上似乎有效！我已经对此进行了多次测试，我可以确认当使用“2.0.*”之类的程序集版本时出现错误，但是当我改为使用“2.0.0”时，它就像一个魅力！我敦促更多的人对此进行测试，如果您发现它有效，请投票赞成这个答案，因为这是需要知道的！希望微软能意识到这一点......谢谢你 drharris :)
这对我不起作用，当我重新启动 VS 时，我有一段时间没有收到错误。每次收到此错误时，我都必须重新启动 VS 2010
仅供参考...这对我不起作用。我的设置一直是：[assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyFileVersion("1.0.0.0")]
如果您当前有 [assembly: AssemblyVersion("1.0.0.0")]，请将其替换为 [assembly: AssemblyVersion("2.0.0.0")] （即 '2' 而不是 '1 '）。它对我有用。虽然我还没有检查过，但只需将版本更改为您现在所拥有的版本之外的任何版本都可以解决此问题。
也适用于 dll！ VS 说无法复制 dll，在将 BOTH [assembly: AssemblyVersion] 和 [assembly: AssemblyFileVersion()] 从 1.0.* 更改为 2.0.0.0 后，它起作用了。

【解决方案2】：

由于我没有收到有关此问题的更多反馈，我想我只是分享一下我最终的解决方案：

正如 Barry 在对原始帖子的评论中所建议的那样，手动将 '...bin\Debug[ProjectName].exe' 重命名为其他名称（例如 '[ProjectName] 1.exe') 是一种解决方法（但是我不允许我自己删除文件，我必须说我发现这有点奇怪，因为人们会相信防止删除的同一个锁也会阻止重命名...）。这不是一个好的解决方案，但它的速度相当快（至少在你做了几次之后，它几乎成了例行公事），并且至少比我一开始做的重新启动 Visual Studio 快得多。

如果有人想知道，我还可以补充一点，我只是半随机地看到这个问题。它通常发生在我对表单的设计模式进行了一些更改之后（但并非总是如此）。如果我只更改业务逻辑代码或非视觉相关代码，通常不会发生这种情况（但有时会发生......）。确实令人沮丧，但至少我有一个适合我的技巧 - 让我们希望我的下一个项目也不会遇到这个问题......

@Barry：如果您想为您的评论赢得赞誉，请随时将其发布为答案，我会确保接受它:)

【讨论】：

我投了赞成票，因为这是我过去所做的。我同意，这是一个肮脏的解决方案，但它确实有效。 VS 在几次迭代中遇到了这个问题。我也在从网络目录加载我的项目。它已被完全信任，但没关系。它是驱动器映射还是 UNC 都没有关系。是的，MS真的需要解决这个问题。他们有一个关闭的错误，因为它说无法重现。跛脚！

【解决方案3】：

我找到了一个简单的解决方案，只需禁用项目文件夹和子文件夹的 Windows 索引服务

【讨论】：

这对我也有用。我不确定我是否理解为什么，因为进程资源管理器显示 devenv.exe 持有锁定手柄。不过，关闭索引解决了这个问题。
@Fopedush 我用同样的解决方案遇到了这个问题，虽然我当时没有看到这个问题。 This answer 解释了为什么它会有所帮助。
这个是为我做的。

【解决方案4】：

我在 VS2008（在 Windows 7 x32 上）中的 WPF 项目有同样的问题（MSB3021）。如果我在上次运行后尝试过快地重新运行应用程序，则会出现问题。几分钟后，exe文件自行解锁，我可以再次重新运行应用程序。但是这么长时间的停顿让我很生气。 唯一真正帮助我的是以管理员身份运行 VS。

【讨论】：

我发现了这个关于这个确切问题的最新错误报告：connect.microsoft.com/VisualStudio/feedback/details/558848/… 该错误报告提供了一个能够重现该错误的示例项目。 drharris 建议的解决方案在那里也有效（请参阅上面链接中发布的解决方法，了解示例项目的分步解决方案）。
这也是唯一对我有用的解决方案。谢谢@Nailuj！
这肯定比重启VS容易。
“页面未找到”连接问题，他们是否只是因为尴尬而将其删除 =S 有没有针对此问题发布的解决方案/解决方法？

【解决方案5】：

当我遇到这个问题时，这与我尝试构建的项目被设置为解决方案中的启动项目有关，这使得 obj 文件夹中的 .exe 被锁定（它也出现在你的任务中经理，）右键单击解决方案中的另一个项目，然后选择设置启动项目。这将释放锁，将其从任务管理器中移除，然后您就可以构建了。

【讨论】：

这对我来说每次都有效。好像和为服务生成并启动的vshost进程有关

【解决方案6】：

我在这里的答案中尝试了所有其他建议，但都没有奏效。最终我使用进程监视器发现我的 VS2010 未能构建的 .exe 被系统进程（PID = 4）锁定。在 SO 中搜索涉及此问题的情况会产生 this 答案。

总结：如果您禁用了应用程序体验服务（就像我一样），然后重新启用并启动它。两年的恶化结束了。

【讨论】：

+1 我之前尝试过其他所有方法（1. 任务管理器，2. 进程资源管理器，即关闭窗口不允许我执行的操作，3. 禁用防病毒软件，4. 不包括 APP_DATA/Local/Microsoft /Visual Studio 来自 Windows 索引服务。）但是这个提示：“应用程序体验”服务是唯一让我免于撞墙的服务。我启用了它，问题就消失了。有趣的是，在我再次禁用它之后，一切仍然正常。我没有更多的问题。但绝对这是唯一为我排序的东西。
也为我工作！！！唯一可行的另一件事是在运行应用程序之前删除 bin 文件夹，但您必须始终在运行之前删除，非常烦人。

【解决方案7】：

我也遇到了与此非常相似的问题，并发现在我的情况下，我已将 bin\debug 文件夹作为 VMware 下的共享文件夹和 VMware、VM 来宾下的资源管理器，甚至可能是来宾下的防病毒程序（尽管我认为我没有安装）正在持有文件的句柄。

【讨论】：

我安装了 Avast，今天早上我收到一个随机的 MVC 错误，说我的 dll 中有病毒。出现错误后，我无法再构建我的 MVC 项目。我向 Avast File System Shield 添加了一个例外，一切都恢复正常了。

【解决方案8】：

禁用“启用 Visual Studio 托管进程”

【讨论】：

【解决方案9】：

我建议下载Process Explorer 以准确了解锁定文件的进程。可以在以下位置找到：

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

【讨论】：

我同意——锁定文件的不一定是 VS。病毒检查员可能会犯此罪。尝试关闭病毒检查器，看看是否有帮助。
对不起，我忘了说我已经这样做了。它说这是对文件（[ProjectName].vshost.exe）具有锁定的Visual Studio（devenv.exe）。所以这对我也没有多大帮助。
@ShellShock：禁用我的防病毒软件 (Avast) 也无济于事。
对我来说，使用 Sysinternals ProcessExplorer，我可以看到该文件的句柄，但是当我单击它时，没有显示任何应用程序持有它，当我尝试关闭句柄时，我得到一个“错误打开过程：句柄无效。” ProcessExplorer 中的错误。然而锁定仍然存在。

【解决方案10】：

使用 Visual Studio，我永远无法想出一个简单的项目来重现错误。

我的解决方案是禁用 Visual Studio 托管进程。

对于那些感兴趣的人，我附上了违规句柄的句柄跟踪：

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

【讨论】：

如果您在问题的最顶部看到，有一个指向 Microsoft Connect 的链接，其中包含错误报告和重现错误的示例项目：connect.microsoft.com/VisualStudio/feedback/details/558848/…
禁用托管进程对我有用。重新启用后它也继续工作。我花了 4 个小时尝试解决这个问题，尝试了数百种解决方案。这是唯一一个似乎可以远程工作的方法。

【解决方案11】：

如果您的问题尚未解决：

Visual Studio 的错误是：

“该进程无法访问文件 'bin\Debug**app.exe**'，因为它正被另一个进程使用。”

所以，去窗口的任务管理器（Ctrl+Shift+Esc），找到你的应用程序名称并通过 Endprocces 强制关闭。

【讨论】：

【解决方案12】：

这是另一种可能性：

在vs2012/win7收到此错误后，我去尝试删除bin目录下的文件，资源管理器显示该文件正在被XAML UI设计器使用。

我关闭了我在 VS 中打开的所有选项卡，关闭了 VS，然后确保在任务管理器中终止所有 MSBuild 进程。最后，重新启动 VS 后，我能够构建解决方案。

还有另一个可能的原因：

我注意到此问题的另一个可能原因。在进行了一些代码重构、将项目移入和移出解决方案后，我的项目引用不再像预期的那样引用解决方案中的项目。

这误导visual studio认为它可以同时构建一些项目，从而创建文件锁。

编辑：即使最近在使用 VS2012 时，我也曾发生过几次这种情况，一旦我将构建顺序设置为正确的依赖项，它就会修复它，杀死 VS 离开运行的任何 msbuild 进程，然后重新启动 VS。为了确定，我杀死了 msbuild 进程，但关闭 VS 也应该杀死它们。

我通常会重构一个项目，使其依赖于解决方案中的另一个项目，而该项目在上次构建时没有引用。这有时似乎会使 VS 感到困惑，并且它不会更新构建顺序。

要检查构建顺序：在解决方案资源管理器中右键单击解决方案并选择“项目构建顺序...”并验证是否正确记录了每个项目的依赖关系。

【讨论】：

我们最近在一个 WinPhone 8 项目中遇到了这种情况。莫名其妙地，原因是使用了 Tuple 类型。删除使用元组的代码问题就消失了。将代码添加回返回的问题。
我在 VS2012 上遇到了同样的问题，关闭 VS 并没有解决问题 - 必须手动终止所有 msbuild.exe 任务
我正在使用 VS 2013，我能够在每次构建之前在任务管理器中杀死“XDesProc.exe *32”进程（Microsoft Visual Studio XAML UI 设计器），这样就成功了.无需重新启动 VS，因为每次在设计视图中打开 *.xaml 文件时，XAML UI 设计器似乎都会重新加载。

【解决方案13】：

重启 IIS- 可能是附加到调试器的进程

【讨论】：

【解决方案14】：

禁用防病毒软件并尝试。 我也遇到了这个问题......但在我的情况下，当我禁用防病毒软件时，防病毒软件阻止了我的应用程序。

【讨论】：

【解决方案15】：

我遇到了同样的错误。

我通过删除所有依赖项目/库的 bin 文件夹的所有内容解决了这个问题。

这个错误主要是由于版本变化造成的。

【讨论】：

【解决方案16】：

这已在 Microsoft 的社区错误报告网站 Connect 上多次提交。仅供参考，我相信这个错误自 2003 年以来一直困扰着 Visual Studio，并且每次都在 RTM 之后得到修复。 :( 参考文献之一如下：

https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0

【讨论】：

【解决方案17】：

先做简单的事情。

检查您的解决方案的一部分是否未被正在运行的进程锁定。

例如，我在我的 Windows 服务上运行了“InstallUtil”（我通常从控制台进行单元测试）。

这将我的一些 dll 锁定在 Windows 服务项目的 bin 文件夹中。当我进行重建时，我在这个问题中遇到了异常。

我停止了windows服务，重建成功了。

在执行此问题中的任何高级步骤之前，请检查您的应用程序的 Windows 任务管理器。

所以当你听到脚步声时，想想马而不是斑马！（来自医学生朋友）

【讨论】：

【解决方案18】：

我有同样的问题。它说无法从 bin\debug 复制到 obj .....

当我构建 web 项目时，我发现我的 dll 都在 bin 文件夹中，而不是在 bin\debug 中。在发布期间 vs 正在寻找 bin\debug 中的文件。所以我在编辑器中打开了 web 项目文件并查找 bin\debug 的实例，我发现所有的 dll 都被称为 bin\debug\mylibrary.dll。我从路径中删除了所有 \debug 并再次发布。这次vs能够找到bin文件夹下的所有dll并发布成功。

我不知道这个路径是如何在 web 项目文件中改变的。

我花了5个多小时调试这个，终于自己找到了解决方案。

这是正确答案。

【讨论】：

【解决方案19】：

如果以上都不起作用，并且您正在开发控制台应用程序：

尝试在 Program.cs 中输入任何字符，然后将其删除。我不知道为什么会这样，但它似乎每次都能解决“无法复制”的问题。

【讨论】：

【解决方案20】：

这通常是由 Avast 引起的。

无论如何，我通常可以在 Release 中运行我的项目，但是在调试中运行时，它会经常失败。

我只是为我的项目文件夹添加了一个排除项，问题似乎就消失了。我认为这也可能是由其他防病毒软件引起的。

【讨论】：

【解决方案21】：

重命名 .exe 和 .pub 文件对我有用，但真的很乏味。我还面临在调试会话期间无法进行编辑的问题。最后我去了高级安全设置页面，按照：

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22%29&rd=true

我取消选择然后重新选择“启用 ClickOnce 安全设置”复选框。这几天一直没有问题....

【讨论】：

【解决方案22】：

对我来说，这是由于在目标文件夹 (C:\users\username\source\repos\project\project\bin\debug\app.publish) 中打开了命令提示符造成的。

不确定为什么 DEBUGGING 需要访问发布文件夹，但关闭命令窗口为我解决了这个问题。

【讨论】：

【解决方案23】：

如果有人在尝试调试单元测试或运行单元测试时遇到此问题，我必须终止以下两个进程才能释放文件：

【讨论】：

【解决方案24】：

我尝试了您提供的几种解决方案，但偶尔仍会收到此错误。我很肯定我的进程没有运行，当我尝试使用 Internet Explorer 删除可执行文件时，它已从文件列表中删除，但随后我按 F5 并瞧，文件又回来了。它根本没有被删除。

但是如果我通过TotalCommander删除文件，实际上exe文件被删除了，我可以成功构建项目。

我正在使用 Windows 7 x64 和总指挥官 7.56a 32 位。

【讨论】：

【解决方案25】：

没有其他答案对我有用，但关闭 Visual Studio 中所有打开的选项卡似乎已经解决了问题。

【讨论】：

【解决方案26】：

我知道这是一个非常古老的问题，但我最近在 VS 2012 中遇到了“无法从 obj 复制到 bin”错误。每次尝试重建某个项目时，我都会收到消息。唯一的解决方案是在每次重建之前进行清理。

经过大量调查，我发现我的一个文件中有一个不完整的编译指示警告语句，它并没有阻止编译成功，但不知何故混淆了 VS 以保持文件锁定。

就我而言，文件顶部有以下内容：

#pragma warning(

就是这样。我想我前一阵子试图做某事并且分心并且从未完成该过程，但是关于该特定行的VS警告在洗牌中丢失了。最终我注意到了这个警告，删除了这条线，从那以后每次都重建工作。

【讨论】：

【解决方案27】：

当我遇到类似问题时，唯一可行的方法是：

右键单击项目，转到“设置”，并确保“调试”和“发布”版本都针对相同的设置，或者其中包含应用程序尝试加载或保存的设置。
删除 C:\Users(YourUserAccount)\AppData\Local(YourAppName) 文件夹。
确保没有我在其中的文件被视为“已阻止”。右键单击我的项目包含的文件，我意识到一个图标实际上被阻止并被认为是坏的，因为它是从 Internet 下载的。我必须点击取消阻止按钮（例如，检查一下：http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png -“此文件来自另一台计算机，可能会被阻止以帮助保护这台计算机。”）。

【讨论】：

【解决方案28】：

对于使用 WCF 的 Windows 服务，我结束了 WFC 主机进程并且它工作正常。当这种情况发生时我讨厌它，而且它有时会随机发生。

【讨论】：

【解决方案29】：

我的解决方案与版本、进程被锁定、重启或删除文件无关。

问题实际上是由于构建失败，并且没有给出正确的错误。实际问题是设计缺陷：

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething();

在将“a”的范围更改为函数之外，或者在Task.Factory.StartNew();之后不使用“a”后，我能够再次构建。

在 Windows7x64 sp1 上使用 VS2012 Update 4 时发生这种情况。

错误信息：

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3390,5)：错误 MSB3030：无法复制文件“obj\x86\Debug\xxx.exe”，因为没找到。

【讨论】：

【解决方案30】：

我发现在 VS2013 中我经常收到此错误。似乎运行良好的方法是在尝试运行应用程序之前执行重建解决方案。我发现执行 CLEAN 有时会奏效，但重建解决方案似乎更稳定。

【讨论】：