Visual Studio构build失败：无法将exe文件从obj \ debug复制到bin \ debug
更新： 重现此错误的示例项目可以在Microsoft Connect中find。 我也testing和validation了下面接受的答案给出的解决scheme适用于该示例项目。 如果这个解决scheme不适合你，你可能会遇到不同的问题（属于一个单独的问题）。
这是一个在Stack Overflow和其他地方都提到的问题，但是我发现的这些build议没有一个能够帮助我，所以我只需要尝试提出一个新的问题。
情景：我有一个简单的Windows窗体应用程序（C＃，.NET 4.0，Visual Studio 2010）。 它有大部分其他formsinheritance的基本forms，它使用entity framework（和POCO类）进行数据库访问。 没有什么花哨，没有multithreading或任何东西。
问题：一切都很好。 然后，当我即将启动应用程序时，Visual Studio没有build立起来。 我得到警告“无法删除文件”… bin \ Debug \ [ProjectName] .exe'。访问path“… bin \ Debug \ [ProjectName] .exe”被拒绝。 和错误“无法将文件obj \ x86 \ Debug \ [ProjectName] .exe'复制到'bin \ Debug \ [ProjectName] .exe'。进程无法访问文件'bin \ Debug \ [ProjectName] .exe因为它正被另一个进程使用。“ （我在运行重build时遇到了警告和错误，但是在运行Build时只有错误 – 不要认为这是相关的？）
我完全理解这个警告和错误消息是什么意思：Visual Studio显然是在尝试覆盖exe文件，同时出于某种原因locking它。 但是，这并不能帮助我find解决问题的办法…我发现的唯一工作是closuresVisual Studio并重新启动它。 build立和启动然后工作，直到我在一些forms进行更改，然后我再次有同样的问题，必须重新启动…非常沮丧！
正如我上面提到的，这似乎是一个已知的问题，所以有很多build议的解决scheme。 我只列出我已经在这里试过的东西，所以人们知道该跳过什么：
- 创build一个新的干净的解决scheme，只是从旧的解决scheme复制文件。
-
将以下内容添加到项目的预生成事件中：
if exist "$(TargetPath).locked" del "$(TargetPath).locked" if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked" -
将以下内容添加到项目属性（.csproj文件）中：
<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
但是，他们都没有为我工作，所以你可能会明白为什么我开始有点沮丧。 我不知道还有什么可以看的，所以我希望有人能给我一些东西！ 这是VS的错误，如果有的话，是否有补丁？ 或者我做错了什么，有没有循环引用或类似的东西，如果有，我怎么能find？
任何build议都高度赞赏:)
更新：如下面的评论中提到的，我也检查过使用Process Explorer，它实际上是locking文件的Visual Studio。
这听起来很愚蠢，但是我尝试了所有这些解决scheme，在Windows 7上运行VS2010。除了重命名和编译之外，他们没有任何工作，这是非常乏味的。 最后，我追查了罪魁祸首，我觉得很难相信。 但我在AssemblyInfo.cs中使用下面的代码…
[assembly: AssemblyVersion("2.0.*")]
这是很常见的，但由于某些原因，将版本更改为2.0.0.0使事情再次起作用。 我不知道它是否是一个Windows 7特定的事情（我只用了3-4周），或者它是随机的，或者是什么，但它为我修复了。 我猜测VS对每个生成的文件保持一个句柄，所以它会知道如何增加的东西？ 我真的不确定，从来没有见过这种情况发生过。 但是，如果别人也把头发拉出来，试试看。
由于在这个问题上我还没有得到更多的反馈，所以我想我只是分享最终成为我的解决scheme：
正如Barry在对原文的评论中所build议的那样，手动将'… bin \ Debug [ProjectName] .exe'重命名为其他内容（例如'[ProjectName] 1.exe' ）是一种解决方法（I'但是我不能自己删除这个文件，而且我必须说我觉得有点奇怪，因为人们会相信同一个锁可以防止重命名…）。 这不是一个好的解决scheme，但是它的速度是合理的（至less在你做了好几次之后，它几乎成了一个例程），至less比重新启动Visual Studio更快，这是我一开始就做的。
如果有人想知道，我可以补充一点，我只是半随机地看到这个问题。 它通常发生在我对表单的devise模式做了一些改变之后（但并不总是）。 如果我只更改业务逻辑代码或非可视化相关的代码（但有时它确实…），通常不会发生这种情况。 确实令人沮丧，但至less我有一个对我有用的黑客 – 让我们只希望我的下一个项目也不会面临这个问题…
@Barry：如果你想得到你的评论的荣誉，请随时张贴作为答案，我会确保接受它:)
我发现一个简单的解决scheme，只需要禁用项目文件夹和子文件夹的Windows索引服务
我在VS2008（在Windows 7 x 32上）有与WPF项目相同的问题（MSB3021）。 出现的问题，如果我试图重新运行应用程序太快之前运行。 经过几分钟的exe文件本身解锁，我可以重新运行应用程序。 但如此漫长的停顿激怒了我。 唯一真正帮助我的是以pipe理员身份运行VS。
当遇到这个问题的时候，就是要处理这个事实，我正在尝试构build的项目被设置为解决scheme中的启动项目，使obj文件夹中的.exe文件被locking（它也出现在您的任务pipe理器中）右键单击解决scheme中的另一个项目，并select设置启动项目。 这将释放锁，从任务pipe理器中删除它，应该让你build立。
我在这里的答案中尝试了所有其他的build议，其中没有一个能够工作。 最后，我使用Process Monitor来发现我的VS2010无法生成的.exe被系统进程locking（PID = 4）。 searchSO的情况涉及到这个答案。
总结：如果您禁用了应用程序体验服务（就像我一样），然后重新启用并启动它。 两年的恶化结束了。
我也遇到了一个类似这样的问题，发现我之所以这样做，是因为我已经将bin \ debug文件夹作为VMware下的共享文件夹提供，并且在VM guest虚拟机下可以是VMware，Explorer，甚至可以是反病毒程序下的客人（虽然我不认为我有一个安装）正在举行的文件（S）的句柄。
如果你的问题没有解决的话：
Visual Studio的错误是：
“进程无法访问文件'bin \ Debug ** app.exe **'，因为它正在被另一个进程使用。”
所以，去窗口的任务pipe理器（Ctrl + Shift + Esc），find你的应用程序（例如app.exe），然后强制它由Endproccesclosures。
禁用“启用Visual Studio宿主进程” 
使用Visual Studio我永远不会想出一个简单的项目来重现错误。
我的解决scheme是禁用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
这是另一种可能性：
在vs2012 / win7中收到这个错误后，我去了，试图删除bin目录中的文件，explorer指出这个文件正在被XAML UI Designer使用。
我closures了所有在VS中打开的选项卡，closuresVS，然后确保杀死taskmanager中的所有MSBuild进程。 最后，在重新启动VS后，我能够构build解决scheme。
另一个可能的原因是：
我注意到这个问题的另一个可能的原因。 在做了一些代码重构，将项目移入和移出解决scheme之后，我的项目引用不再像预期的那样引用解决scheme中的项目。
这个误导的视觉工作室认为它可以同时build立一些项目，从而创build文件locking。
编辑：我曾经有过这种情况发生在最近几次，甚至最近VS2012，它确实修复了一次，我把生成顺序设置为正确的依赖关系，杀死VS剩下的任何msbuild进程运行，然后重新启动VS. 我杀死了msbuild进程，但是closuresVS也应该杀掉它们。
我通常会这样做的是重构一个项目，以至于它依赖于解决scheme中的另一个项目，而这个项目在最后的构build中没有引用。 这有时似乎混淆了VS，它不会更新构build顺序。
要检查构build顺序，请执行以下操作：右键单击解决scheme资源pipe理器中的解决scheme，然后select“项目构build顺序…”，并validation每个项目的依赖项是否正确logging。
重新启动IIS-可能是一个附加到debugging器的进程
禁用防病毒并尝试。 我也面临这个问题…但在我的情况下，防病毒阻止我的应用程序，当我禁用防病毒解决。
我面临同样的错误。
我通过删除所有依赖项目/库的bin文件夹的所有内容来解决问题。
这个错误主要是由于版本变化。
我build议下载Process Explorer以确定哪个进程正在locking文件。 它可以在：
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Connect已经多次提交给微软的社区bug报告网站。 仅供参考，我相信这个bug自2003年以来一直困扰着Visual Studio，并且每次都在RTM之后进行修复。 :(其中一个参考如下：
如果以上都不行，而且你正在开发一个控制台应用程序：
尝试在Program.cs中input任何字符，然后删除它。 我不知道为什么这个工作，但似乎每次解决“无法复制”的问题。
这通常是由Avast造成的。
我通常可以在Release中运行我的项目，但是在debugging时运行它会经常失败。
我只是添加一个排除我的项目文件夹和问题似乎消失。 我认为这也可能是由其他杀毒软件造成的。
重命名.exe和.pub文件为我工作，但真的很乏味。 我也遇到了在debugging会话期间无法编辑的问题。 最后，我进入高级安全设置页面，如下所示：
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 =真
我取消select，然后重新select“启用ClickOnce安全设置”checkbox。 现在已经有一段时间没有问题了….
对我来说，这是由于在目标文件夹（ C:\users\username\source\repos\project\project\bin\debug\app.publish ）中打开命令提示符而导致的。
不知道为什么DEBUGGING需要访问发布文件夹，但closures命令窗口解决了我的问题。
我尝试了您提供的几个解决scheme，但偶尔我仍然收到此错误。 我很积极，我的进程没有运行，当我尝试删除与Internet Explorer的可执行文件它被从文件列表中删除，但后来我按F5和瞧，文件回来了。 它并没有被删除。
但是，如果我通过TotalCommander删除文件，exe文件实际上是删除，我可以成功地build立项目。
我正在使用Windows 7 x64和总指挥官7.56a 32位。
没有其他答案为我工作，但在Visual Studio中closures所有打开的标签似乎已经解决了这个问题。
我知道这是一个非常古老的问题，但是我最近在VS 2012中遇到了“无法从obj复制到bin”的错误。每次我尝试重build某个项目时，都会收到消息。 唯一的解决办法是在每次重build之前进行清理。
经过多方调查，事实certificate我的一个文件中有一个不完全的编译指示警告，这并不妨碍编译的成功，但是却让VS难以把文件锁住。
就我而言，我在文件顶部有以下内容：
#pragma warning(
而已。 我猜想我正在试图做一些事情，分心，从来没有完成的过程，但VS的警告关于特定的线路在洗牌失去了。 最后，我注意到警告，拆除了这条线，并从此每次都重build作品。
先做简单的事情吧。
检查您的解决scheme的一部分没有被正在运行的进程locking。
例如，我运行“InstallUtil”在我的Windows服务（我通常从控制台unit testing）。
这locking了一些我的DLL在Windows服务项目的bin文件夹。 当我做了重build，我得到了这个问题的例外。
我停止了Windows服务，重build并成功。
在执行此问题的任何高级步骤之前，请检查您的应用程序的Windows任务pipe理器。
所以，当你听到脚步声，想马不是斑马！ （来自医学生朋友）
当我面临类似的问题时，似乎工作的唯一的东西是：
- 右键单击该项目，转到设置，并确保“debugging版”和“版本”版本都以相同的设置为目标，或者在应用程序中尝试加载或保存设置。
- 删除C：\ Users（YourUserAccount）\ AppData \ Local（YourAppName）文件夹。
- 确保我没有在那里的文件被认为是“阻止”。 右键点击我的项目包含的文件，我意识到，一个图标实际上被封锁，认为不好，因为它是从互联网上下载的。 我不得不点击解除阻止button（例如，检查了这个： http : Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png – “这个文件来自另一台计算机，可能会阻止帮助保护这台电脑“）。
对于使用WCF的Windows服务，我结束了WFC主机进程，它工作。 当这种事情发生时，我讨厌它，而且它偶尔会发生。
我的解决scheme与版本无关，进程被locking，重新启动或删除文件。
问题实际上是由于构build失败，并没有给出正确的错误。 实际的问题是一个devise缺陷：
// 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” Task.Factory.StartNew(); ，我能够再次build立。
在Windows7x64 sp1上使用VS2012 Update 4时发生这种情况。
错误信息：
C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets（3390,5）：错误MSB3030：无法复制文件“obj \ x86 \ Debug \ xxx.exe”，因为没有find。
我发现与VS2013我经常得到这个错误。 似乎工作得相当好的是在尝试运行应用程序之前执行重build解决scheme。 我发现执行CLEAN有时可以工作，但重build解决scheme似乎工作更一致。
我有同样的问题。 它说不能从bin \ debug复制到obj …..
当我build立web项目，我发现我的DLL都在bin文件夹，而不是bin \ debug。 发布期间vs正在bin \ debug中查找文件。 所以我打开编辑器中的Web项目文件，并寻找bin \ debug的实例，我发现所有的DLL都提到了bin \ debug \ mylibrary.dll。 我从path中删除了所有\ debug并重新发布。 这一次vs能够findbin文件夹中的所有dll并发布成功。
我不知道如何在web项目文件中更改此path。
我花了超过5个小时的时间来debugging，最终find了自己的解决scheme。
这是正确的答案 。
