Visual Studio构建失败:无法从obj\debug复制exe文件到bin\debug

199
更新:在Microsoft Connect上可以找到一个重现此bug的示例项目 这里。我还测试并验证了下面被接受的回答在该示例项目中有效。如果这个解决方案对你不起作用,你可能遇到了另一个问题(需要提出一个单独的问题)。

这是之前在Stack Overflow和其他地方问过的问题,但我找到的建议都没有帮助我,所以我只好尝试提一个新的问题。

场景:我有一个简单的Windows Forms应用程序(C#,.NET 4.0,Visual Studio 2010)。它具有大约两个基本表单,大多数其他表单都从中继承,它使用Entity Framework(和POCO类)进行数据库访问。没什么花哨的东西,没有多线程等。

问题:一切都很好一段时间,然后突然间,当我要启动应用程序时,Visual Studio无法构建。我得到了警告"无法删除文件'...bin\Debug\[ProjectName].exe'。路径'...bin\Debug\[ProjectName].exe'的访问被拒绝。和错误"无法将文件'obj\x86\Debug\[ProjectName].exe'复制到'bin\Debug\[ProjectName].exe'。该进程无法访问文件'bin\Debug\[ProjectName].exe',因为另一个进程正在使用它。"(在重新生成时,我会同时获得警告和错误,但仅在构建时获得错误 - 我认为这不相关?)

我完全理解警告和错误消息的含义:显然,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的bug吗?如果是,是否有补丁可用?还是我做错了什么,我有循环引用或类似的问题,如果是,我该如何找出?

    非常感谢任何建议 :)

    更新: 如下评论所述,我还使用Process Explorer进行了检查,确实是Visual Studio锁定了该文件。


    4
    你检查过你的应用程序是否正常关闭了吗?任务管理器是否显示在进程列表中有 [ProjectName].exe? - miensol
    2
    我以前遇到过这个问题,我只是将文件重命名为.old等,然后重新运行构建。虽然不是完美的解决方法,但对我来说有效。 - codingbadger
    2
    @Naliluj:我在微软论坛上看到了这篇文章,它解释说这可能与资源文件有关。如果你正在使用resx文件,这可能会给出一些提示。 - Patrick
    1
    为了后人,我遇到了这个问题,并通过将<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>元素添加到我的csproj文件中来解决它。 - ThisIsTheDave
    在SharpDevelop论坛中可能与此密切相关(具有相同的MSBuild消息):线程 - O. R. Mapper
    显示剩余10条评论
    36个回答

    120

    可能听起来很傻,但我尝试了所有这些解决方案,在Windows 7上运行VS2010。除了重命名和构建之外,它们都没有起作用,而这种方法非常繁琐。最终,我找到了罪魁祸首,真难以置信。但我在AssemblyInfo.cs中使用了以下代码...

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

    这很常见,但不知为何将版本更改为2.0.0.0后事情又开始工作了。我不知道它是否仅适用于Windows 7(我只使用了3-4周),或者是否是随机的,但它对我有用。我猜测VS一直在跟踪它生成的每个文件的句柄,以便知道如何递增它们?我真的不确定以前是否发生过这种情况。但如果其他人也在拔光头发,可以尝试一下。


    13
    这个主意有点疯狂,没错 ;) 更疯狂的是,它似乎真的能够起作用!我已经多次测试过了,可以确认当使用类似于“2.0.*”这样的组件版本时,会出现错误。但是如果我改用“2.0.0”,那么它就能够完美地工作!我敦促更多的人来测试一下,如果你发现它能够正常工作,请给这个答案投票,因为这是需要被知道的!希望微软能够注意到这一点……谢谢drharris :) - Julian
    2
    这对我没有用,当我重新启动VS时,有一段时间我没有收到错误。每次出现此错误时,我都必须重新启动VS 2010。 - Sharique
    6
    知悉,这对我没有起作用。我的设置一直是:[assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyFileVersion("1.0.0.0")] - tbone
    4
    如果您当前的代码是 [assembly: AssemblyVersion("1.0.0.0")],请将其替换为 [assembly: AssemblyVersion("2.0.0.0")](即将数字 '1' 改成 '2')。这对我起作用了。虽然我没有检查过,但只要将版本号改成与现在不同的任何版本可能都可以解决此问题。 - Frederick The Fool
    1
    更好的是:这不仅仅是自动递增。我无法通过我的程序、Notepad++,甚至是VS本身来更改“AssemblyVersion”。另一方面,似乎只有对“AssemblyVersion”的更改才会触发它。“AssemblyFileVersion”和“AssemblyInformationalVersion”可以自由更改。 - Bob
    显示剩余11条评论

    14

    由于我没有收到有关此问题的更多反馈,我想分享一下我的解决方案:

    如原帖中Barry在评论中建议的那样,手动将 '...bin\Debug[ProjectName].exe' 重命名为其他名称(例如'[ProjectName]1.exe')是一个解决方法(但我不允许自己删除该文件,我必须说我觉得这有点奇怪,因为同样的锁应该会防止重命名...)。它不是一个好的解决方案,但它相对快速(至少做了几次之后,几乎成为一种例行程序),而且至少比重新启动Visual Studio要快。

    如果有人想知道,我只在某种程度上随机地遇到了这个问题。它通常发生在我对表单的设计模式进行更改后(但并非总是如此)。如果我仅更改业务逻辑代码或非可视相关代码,则通常不会发生此问题(但有时确实会发生...)。确实令人沮丧,但是至少我有一个对我有效的方法——让我们希望我的下一个项目也不会面临这个问题...

    @Barry:如果您想获得评论荣誉,请随时将其发布为答案,我会确保接受它:)


    我已经投票支持了,因为这是我过去所做的。我同意,这是一个不太好的解决方案,但它确实有效。VS在过去的几个版本中一直存在这个问题。我也从网络目录加载我的项目。它已经被完全信任,但这并不重要。无论是驱动器映射还是UNC都没有关系。是的,微软真的需要解决这个问题。他们有一个关闭的错误报告,说无法复现。太糟糕了! - Josh Robinson

    14
    我找到了一个简单的解决方案,只需禁用Windows索引服务对该项目文件夹及其子文件夹进行索引即可。

    2
    这对我也起作用了。虽然进程资源管理器显示devenv.exe正在持有锁定句柄,但我不确定为什么会这样。尽管如此,关闭索引就解决了问题。 - Fopedush
    1
    @Fopedush 我也遇到了同样的问题,尽管当时我没有看到这个问题。这个答案解释了为什么它有帮助。 - DJH
    1
    这个对我有用。 - Martin Capodici

    12

    我在Windows 7 x32上使用VS2008开发WPF项目时也遇到了同样的问题(MSB3021)。 如果我在上一次运行应用程序后过快地尝试重新运行它,就会出现这个问题。几分钟后exe文件会自动解锁,然后我才能重新运行应用程序。但是这样长时间的等待令我很恼火。 唯一真正帮助我的方法是以管理员身份运行VS。


    1
    我发现了一个关于这个确切问题的最新错误报告:https://connect.microsoft.com/VisualStudio/feedback/details/558848/vsip-rebuilding-a-project-with-open-designers-twice-causes-an-error-with-locked-bin-debug-dlls。该错误报告提供了一个示例项目,可以重现该错误。drharris建议的解决方案在那里也起作用(请参见上面链接中发布的解决示例项目的逐步解决方案)。 - Julian
    这肯定比重新启动 VS 更容易。 - Elvedin Hamzagic
    1
    “页面未找到”这个连接出了问题,他们是因为尴尬才删除的吗 =S 是否曾经发布过解决方案/变通方法? - Paul C

    9
    当我遇到这个问题时,通常是因为我尝试构建的项目设置为解决方案中的启动项目,从而使得 obj 文件夹中的 .exe 文件被锁定(它也会出现在任务管理器中)。请右键单击解决方案中的另一个项目并选择"设置启动项目"。这将释放锁定,从任务管理器中删除它,并允许您构建。

    1
    这对我来说每次都有效。这似乎与为服务生成并启动的vshost进程有关。 - jaywayco

    8

    我尝试了这里所有其他答案的建议,但都没有奏效。最终我使用了Process Monitor发现我的.exe文件被系统进程(PID=4)锁定,导致VS2010无法构建。在SO上搜索涉及此情况的解决方案,找到了this答案。

    总结:如果您禁用了应用程序体验服务(就像我一样),请重新启用并启动它。两年的烦恼结束了。


    +1 我之前尝试过其他所有方法(1.任务管理器,2.进程管理器-关闭Windows不允许关闭的句柄,3.禁用杀毒软件,4.将APP_DATA/Local/Microsoft/Visual Studio从Windows索引服务中排除等),但是有关“应用程序体验”服务的提示是唯一一个让我避免了一直撞墙的方法。我启用了它后问题消失了。有趣的是,当我再次禁用它时,一切仍然很好。我再也没有遇到过任何问题。但毫无疑问,这是唯一可以解决我的问题的方法。 - Tomás
    也适用于我!!!另外一个可行的方法是在运行应用程序之前删除bin文件夹,但你必须每次都要删除,非常烦人。 - E_Blue

    6

    我曾经遇到过一个非常类似的问题,后来发现原因是因为我把 bin\debug 文件夹共享给了 VMware,然后 VM 客户机下的 Explorer 或者甚至是客户机下的防病毒程序(虽然我不认为我安装了这样的程序)都在占用文件的句柄。


    我已经安装了Avast杀毒软件,今天早上我收到一个随机的MVC错误,说我的dll文件里有病毒。在出现错误后,我无法再构建我的MVC项目。我向Avast文件系统屏蔽器添加了一个例外,现在一切都恢复正常了。 - Dusty

    5

    禁用“启用Visual Studio托管进程” 项目调试设置


    4

    使用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 的链接,其中包含一个错误报告和一个可重现该错误的示例项目:https://connect.microsoft.com/VisualStudio/feedback/details/558848/vsip-rebuilding-a-project-with-open-designers-twice-causes-an-error-with-locked-bin-debug-dlls - Julian
    禁用托管进程对我有用。即使重新启用后,它仍然有效。我花了4个小时尝试数百种解决方案来解决这个问题。这是唯一一个似乎起作用的解决方案。 - Drew Chapin

    4

    我同意,锁定文件的原因不一定是VS。病毒检查器也可能会导致这种情况发生。尝试关闭病毒检查器,看看是否有所帮助。 - Polyfun
    抱歉,我忘了提到我已经做过那个了。它显示是Visual Studio (devenv.exe)正在锁定该文件([ProjectName].vshost.exe)。所以这对我也没有什么帮助。 - Julian
    @ShellShock:禁用我的防病毒软件(Avast)也无济于事。 - Julian
    对我来说,使用Sysinternals ProcessExplorer,我可以看到该文件的句柄,但是当我点击它时,没有显示任何应用程序持有它,当我尝试关闭句柄时,在ProcessExplorer中出现“打开进程错误:句柄无效。”的错误。然而锁定仍然存在。 - tbone

    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文,
    原文链接