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

193

更新： 可在Microsoft Connect上找到重现此错误的示例项目。我还测试并验证了下面接受的答案中给出的解决方案可用于该示例项目。如果此解决方案不适合您，则可能是您遇到了其他问题（属于一个单独的问题）。

这是之前在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中被锁定的文件。

c# .net winforms visual-studio

— 朱利安
source

4

您是否检查过应用程序是否正常关闭？任务管理器是否在进程列表中显示[ProjectName] .exe？

— miensol

2

我以前有过，我只是将文件重命名为.old等，然后重新运行构建。我不知道确切的解决方法，但是它对我有用。

— –codingbadger

@miensol：是的，它似乎正常关闭了。我收到“程序'[1848] [ProjectName] .vshost.exe：托管（v4.0.30319）'退出，代码0（0x0）。” @Barry：在bin \ Debug中重命名exe文件是可行的，但是正如您所说的，这并不是真正的解决方案，每次都必须这样做很烦人。比重新启动Visual Studio更好一点……

— 朱利安

2

@Naliluj：我在Microsoft论坛上看到了这篇文章，该文章解释说它可能与资源文件有关。如果您使用的是resx文件，则可能会提示。

— 帕特里克

1

为了后代，我遇到了这个问题，并通过在我的csproj文件中添加<GenerateResourceNeverLockTypeAssemblies> true </ GenerateResourceNeverLockTypeAssemblies>元素来解决此问题。

— ThisIsTheDave 2010年

117

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

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

这很普遍，但是由于某种原因，将版本更改为2.0.0.0会使事情再次起作用。我不知道这是否是Windows 7专用的东西（我只使用了3-4周），或者它是随机的，还是什么，但是它为我修复了它。我猜想VS会对它生成的每个文件保持句柄，因此它会知道如何增加内容？我真的不确定，也从未见过这种情况。但是，如果有人在那里也拉扯头发，请尝试一下。

— 德拉里斯
source

12

那是一个疯狂的主意，我给你；）甚至更疯狂的是，它实际上似乎有效！我已经对此进行了多次测试，并且可以确认使用“ 2.0。*”之类的程序集版本时会出现错误，但是当我改用“ 2.0.0”时，它确实具有吸引力！我敦促更多的人对此进行测试，如果您发现它可行，请投票赞成该答案，因为这是必须知道的！希望微软对此有所帮助...谢谢drharris :)

— 朱利安

2

这对我不起作用，当我重新启动VS时，一段时间没有出现错误。每次遇到此错误，我都必须重新启动VS 2010

— Sharique

6

费...这对我不起作用。我的设置一直是：[assembly：AssemblyVersion（“ 1.0.0.0”）] [assembly：AssemblyFileVersion（“ 1.0.0.0”）]

— tbone 2011年

4

如果您当前具有[assembly：AssemblyVersion（“ 1.0.0.0”）]，则将其替换为[assembly：AssemblyVersion（“ 2.0.0.0”）]（即“ 2”而不是“ 1”）。它为我工作。尽管我还没有检查过，但是将版本更改为您现在所拥有的以外的任何版本都可以解决此问题。

— 傻子弗雷德里克（Frederick The Fool）

1

也适用于dll！VS说不能复制的dll和改变后BOTH [装配：的AssemblyVersion]和[装配：的AssemblyFileVersion（）1.0 *至2.0.0.0，它的工作。

— AZ。

14

由于没有更多有关此问题的反馈，我认为我只想分享最终成为我解决方案的内容：

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

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

@Barry：如果您想因自己的评论而获得好评，请随时将其作为答案发表，我将确保接受它:)

— 朱利安
source

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

— 乔什·罗宾逊

14

我找到了一个简单的解决方案，仅对项目文件夹和子文件夹禁用Windows Indexing Services

— 佩德罗
source

2

这也为我工作。我不确定我理解为什么，因为进程浏览器显示devenv.exe持有锁定句柄。但是，关闭索引解决了该问题。

— Fopedush 2014年

1

@Fopedush我用相同的解决方案遇到了这个问题，尽管当时我没有看到这个问题。这个答案对为什么有帮助有一些解释。

— 达伦·黑尔

1

这是为我做的。

— Martin Capodici 2014年

12

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

— 谢尔盖
source

1

我发现了有关此确切问题的最新错误报告：connect.microsoft.com/VisualStudio/feedback/details/558848/…该错误报告提供了一个能够重现该错误的示例项目。drharris建议的解决方案也在那里工作（有关示例项目的分步解决方案，请参见上面链接中发布的解决方法）。

— 朱利安

这也是唯一对我有用的解决方案。谢谢@Nailuj！

— 温格

这肯定比重新启动VS容易。

— Elvedin Hamzagic 2015年

1

对于连接问题，“找不到页面”，他们只是出于尴尬而将其删除了= S是否为此发布过解决方案/解决方法？

— Coops

9

当我遇到此问题时，实际上是我要构建的项目在解决方案中设置为Startup项目，从而使obj文件夹中的.exe锁定（它也出现在任务管理器中）。右键单击解决方案中的另一个项目，然后选择“设置启动项目”。这将释放锁，将其从任务管理器中删除，并应让您进行构建。

— 阿德里安·布斯（Adrian Booth）
source

1

每次都对我有用。似乎与为服务生成并启动的vshost进程有关

— jaywayco

8

我在这里尝试了答案中的所有其他建议，但都没有奏效。最终，我使用进程监视器发现VS2010无法构建的.exe被系统进程锁定（PID = 4）。在SO中搜索与此相关的情况可以得出此答案。

总结：如果您像我一样禁用了Application Experience服务，请重新启用并启动它。两年的苦难结束了。

— 八位大师
source

+1我以前尝试了其他所有方法（1.任务管理器，2。进程浏览器，即关闭不让我做的Windows的句柄，3。禁用防病毒，4。从Windows索引服务中排除APP_DATA / Local / Microsoft / Visual Studio。），但本文提示：“应用程序体验”服务是唯一使我免于撞墙的服务。我启用了它，问题就消失了。有趣的是，在我再次禁用它之后，一切仍然正常。我再也没有问题了。但这绝对是为我排序的唯一一件事。

— 托马斯

也为我工作！！！唯一起作用的是在运行应用程序之前删除bin文件夹，但是您必须在运行之前始终删除它，这很烦人。

— E_Blue

6

我也遇到了一个与此非常类似的问题，发现我的原因是我已将bin \ debug文件夹作为共享文件夹在VMware下提供，并且在VM guest虚拟机下可以作为VMware，Explorer甚至是防病毒软件使用来宾下的程序（尽管我认为我没有安装）正在握住文件的句柄。

— 昆西·冯·贝西克斯
source

我已经安装了Avast，今天早晨，我收到一个随机的MVC错误，说我的dll中含有病毒。错误之后，我无法再构建我的MVC项目。我在Avast File System Shield中添加了一个例外，一切都再次正常运行。

— 尘土飞扬的

5

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

— BCS软件
source

4

我建议下载Process Explorer以找出确切的过程来锁定文件。可以在以下位置找到：

http://technet.microsoft.com/zh-cn/sysinternals/bb896653.aspx

— 汉斯·奥尔森
source

我同意-锁定文件不一定是VS。病毒检查程序可能对此感到内。尝试关闭病毒检查器，看看是否有帮助。

— Polyfun

抱歉，我忘了提到我已经做到了。它说是Visual Studio（devenv.exe）对文件（[ProjectName] .vshost.exe）拥有锁定。因此，这对我也无济于事。

— 朱利安

@ShellShock：禁用我的防病毒软件（Avast）也无济于事。

— 朱利安

对我来说，使用Sysinternals ProcessExplorer，我可以看到该文件的句柄，但是当我单击该文件时，没有显示任何应用程序将其保存，并且当我尝试关闭该句柄时，出现“错误打开过程：该句柄是无效。” ProcessExplorer中的错误。但是锁仍然存在。

— tbone 2011年

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

— 丹尼尔
source

如果你在最高层的问题看，有微软连接链路与错误报告并再现错误的示例项目：connect.microsoft.com/VisualStudio/feedback/details/558848/...

— 朱利安

禁用托管过程对我有用。重新启用它后，它仍可以继续工作。我花了4个小时尝试通过数百种解决方案来解决此问题。这是唯一一个似乎遥不可及的功能。

— 德鲁·查平

4

如果您的问题尚未解决：

Visual Studio的错误是：

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

因此，转到Windows的任务管理器（Ctrl + Shift + Esc），找到您的应用程序名称并通过Endprocces强制其关闭。

— 阿米尔·侯赛因·雷扎伊
source

3

这是另一种可能性：

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

我关闭了在VS中打开的所有选项卡，关闭了VS，然后确保杀死taskmanager中的所有MSBuild进程。最后，在重新启动VS之后，我可以构建解决方案。

另一个可能的原因：

我注意到此问题的另一个可能原因。在完成一些代码重构，将项目移入和移出解决方案之后，我的项目引用不再按预期引用该解决方案中的项目。

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

编辑：我最近在VS2012上有几次发生过这种情况，一旦我将构建顺序设置为正确的依存关系，杀死了VS仍在运行的任何msbuild进程，然后重新启动VS，它确实可以解决此问题。我肯定会杀死msbuild进程，但是关闭VS也应该杀死它们。

我通常会导致此问题的原因是重构一个项目，使其依赖于上次构建中未引用的解决方案中的另一个项目。有时这似乎使VS感到困惑，并且它不会更新构建顺序。

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

— 凯文·沙纳汉（Kevin Shanahan）
source

我们最近在WinPhone 8项目中体验到了这一点。莫名其妙地，原因是使用了元组类型。删除使用元组的代码，问题就消失了。重新添加代码返回的问题。

— Seamus 2013年

我在VS2012上遇到过同样的问题，关闭VS并没有解决问题-必须手动杀死所有msbuild.exe任务

— Mizzle 2014年

我使用的是VS 2013，在每次构建之前，我都可以在任务管理器中终止“ XDesProc.exe * 32”进程（Microsoft Visual Studio XAML UI设计器），从而达到了目的。无需重新启动VS，因为XAML UI设计器似乎每次在设计视图中打开* .xaml文件时都会重新加载。

— Tim Sexton

3

重新启动IIS-可能是调试器附带的进程

— 艾伦
source

3

禁用防病毒并尝试。 我也面临着这个问题...但是在我的情况下，当我禁用防病毒软件时，防病毒软件阻止了我的应用程序，该软件得以解决。

— 哈桑·贾夫拉尼
source

3

我遇到了同样的错误。

我通过删除所有从属项目/库的bin文件夹的所有内容解决了该问题。

此错误主要是由于版本更改而发生的。

— 乌察夫黎明
source

2

该问题已在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

— 麦可
source

1

首先做简单的事情。

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

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

这将我的一些dll锁定在Windows服务项目的bin文件夹中。当我进行重建时，在此问题中出现了例外。

我停止了Windows服务，对其进行了重建，并成功了。

在执行此问题中的任何高级步骤之前，请为您的应用程序检查Windows Task Manager。

因此，当您听到脚步声时，请以为马不是斑马！（来自医学生朋友）

— 格雷格·JF
source

1

我有同样的问题。它说不能从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个多小时来调试它，终于自己找到了解决方案。

这是正确的答案。

— nccsbim071
source

1

如果以上方法均无效，并且您正在开发控制台应用程序：

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

— 格雷格
source

1

这通常是由Avast引起的。

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

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

— 詹姆斯·普萨特里
source

1

重命名.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安全设置”复选框。几天来一直没有问题。

— e
source

1

对我来说，这是由于在目标文件夹（C:\users\username\source\repos\project\project\bin\debug\app.publish）中打开命令提示符而引起的。

不知道为什么DEBUGGING需要访问publish文件夹，但是关闭命令窗口为我解决了这个问题。

— 巴西
source

1

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

— 哈吉斯777
source

0

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

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

我正在使用Windows 7 x64和Total Commander 7.56a 32位。

— Gico
source

0

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

— 伊恩·默瑟（Ian Mercer）
source

0

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

经过大量调查，结果发现我的一个文件中有一个不完整的实用警告警告语句，该语句不能阻止编译成功，但会以某种方式使VS混淆以保持文件锁定。

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

#pragma warning(

而已。我猜想我正试图做一些事情，但后来却分心了并且从未完成过该过程，但是关于该特定行的VS警告在混洗中丢失了。最终，我注意到了该警告，删除了该行，此后每次都可以进行重建。

— 克里斯
source

0

当我遇到类似的问题时，似乎唯一起作用的是：

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

— 亚历山德鲁
source

0

对于使用WCF的Windows服务，我结束了WFC主机进程，并且该进程有效。我讨厌这种情况发生，并且有时会随机发生。

— 肖尼·鲍伊
source

0

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

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

// 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”的范围更改为函数外部，或之后不使用“ a”后Task.Factory.StartNew();，便可以再次构建。

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

错误信息：

C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets（3390,5）：错误MSB3030：由于找不到文件“ obj \ x86 \ Debug \ xxx.exe”而无法复制。

— 库特拉基斯
source

0

我发现VS2013会定期出现此错误。看起来运行良好的方法是在尝试运行应用程序之前执行“重建解决方案”。我发现执行CLEAN有时可以工作，但“重建解决方案”似乎可以更一致地工作。

— mattpm
source