Visual Studio生成失败：无法将exe-file从obj\debug复制到bin\debug

I'd suggest download Process Explorer to find out exactly what process is locking the file. It can be found at:

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

Since I haven't gotten any more feedback on this issue, I thought I'd just share what ended up being my solution:

As suggested by Barry in a comment to the original post, manually renaming the '...bin\Debug[ProjectName].exe' to something else (e.g. '[ProjectName]1.exe') is one work-around (I'm however not allowed to delete the file myself, and I must say I find that a bit weird as one would believe the same lock preventing deletion would also prevent renaming...). It's not a good solution, but it's reasonable fast (at least after you've done it a couple of times, it almost becomes a routine), and at least way faster than restarting Visual Studio which is what I did in the beginning.

In case somebody wonders, I could also add that I only see this problem semi-randomly. It usually happens after I've done some changes in the design mode of a form (but not always). It usually doesn't happen if I only change business-logic code or non-visual related code (but sometimes it does...). Frustrating indeed, but at least I have a hack that works for me - let's just hope that my next project doesn't face this problem as well...

@Barry: if you would like to get credit for your comment, please feel free to post it as an answer and I'll make sure to accept it :)

This is going to sound stupid, but I tried all these solutions, running VS2010 on Windows 7. None of them worked except the renaming and building, which was VERY tedious to say the least. Eventually, I tracked down the culprit, and I find it hard to believe. But I was using the following code in AssemblyInfo.cs...

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

This is pretty common, but for some reason, changing the version to 2.0.0.0 made things work again. I don't know if it's a Windows 7 specific thing (I've only been using it for 3-4 weeks), or if it's random, or what, but it fixed it for me. I'm guessing that VS was keeping a handle on each file it generated, so it would know how to increment things? I'm really not sure and have never seen this happen before. But if someone else out there is also pulling their hair out, give it a try.

This has been filed multiple times on Connect, Microsoft's community bug reporting site. FYI, I believe this bug has afflicted Visual Studio since 2003 and has been fixed after RTM each time. :( One of the references is as follows:

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

I have the same problem (MSB3021) with WPF project in VS2008 (on Windows 7 x32). The problem appearing if i try to re-run application too quick after previous run. After a few minutes exe-file unlocked by itself and i can re-run application again. But such a long pause angers me. The only thing that really helped me was running VS as Administrator.

Using Visual Studio I could never come up with a simple project to reproduce the error.

My solution was to disable the Visual Studio Hosting process.

For those interested I have attached a handle trace for the offending handle:

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

I also had a problem very similar to this and found the reason in my case was that I had made the bin\debug folder available as a shared folder under VMware and either VMware, Explorer under the VM guest, or maybe even an anti-virus program under the guest (though I don't think I had one installed) was holding a handle to the file(s).

I tried several solutions that you provided, but occasionally I still receive this error. I am positive that my process is not running, and when i try to delete the executable file with internet explorer it is removed from the file list, but then I press F5 and voila, the file is back. It has not been deleted at all.

But if i delete the file through the TotalCommander, the exe file is actually deleted and I can successfully build the project.

I am using windows 7 x64 and total commander 7.56a 32 bit.

Here's another possibility:

After receiving this error in vs2012 / win7, I went and tried to delete the file in the bin directory and explorer indicated that the file was in use by the XAML UI Designer.

I closed all the tabs I had open in VS, closed VS, then made sure to kill all MSBuild processes in taskmanager. Finally, after restarting VS I was able to build the solution.

and another possible cause:

I have noticed another possible cause for this issue. After doing some code refactoring, moving projects in and out of a solution, my project references were no longer referencing the projects in the solution as expected.

This mislead visual studio to think it could build some projects concurrently, thus creating the file locks.

EDIT: I have had this happen on a few occasions even recently with VS2012 and it does fix it once I set the build order to the correct dependencies, kill any msbuild processes that VS left running, and then restart VS. I kill the msbuild processes just to be sure, but closing VS should kill them off too.

What I usually do to cause this is refactor a project such that it relies on another project within the solution that it wasn't referencing on last build. This sometimes seem to confuse VS and it doesn't update the build order.

To check build order: Right-click the Solution in the Solution Explorer and select "Project Build Order..." and verify that dependencies are properly noted for each project.

Do the simple things first.

Check that part of your solution is not locked by a running process.

For instance, I ran "InstallUtil ' on my windows service(which I normally unit test from a console).

This locked some of my dlls in the bin folder of the windows service project. When I did a rebuild I got the exception in this issue.

I stopped the windows service, rebuilt and it succeeded.

Check Windows Task Manager for your Application, before doing any of the advance steps in this issue.

So when you hear footsteps, think horses not zebras! (from medical student friend)

None of the other answers worked for me but closing all open tabs in Visual Studio appears to have solved the problem.

I know this is a very old question, but I recently experienced the "cannot copy from obj to bin" error in VS 2012. Every single time I tried to rebuild a certain project, I got the message. The only solution was to do a clean before every rebuild.

After much investigating, it turns out I had an incomplete pragma warning statement in one of my files that did not prevent the compilation from succeeding, but was somehow confusing VS into keeping the file(s) locked.

In my case, I had the following at the top of the file:

#pragma warning(

That's it. I guess I was attempting to do something a while back and got distracted and never finished the process, but the VS warnings about that particular line were lost in the shuffle. Eventually I noticed the warning, removed the line, and rebuild works every time since then.

I found one simple solution, just disable the Windows Indexing Services for the project folder and subfolders

When I have come across this problem it is to do with the Fact that the project I am trying to build is set as the Startup project in the solution making the .exe in the obj folder locked ( it also appears in your task manager,) right click another project in your solution and choose set startup project. This will release the lock, remove it from task manager and should let you build.

I tried all the other suggestions in the answers here, none of which worked. Eventually I used Process Monitor to discover that my .exe that VS2010 was failing to build was locked by the System process (PID=4). Searching SO for situations involving this yielded this answer.

Summarised: if you have the Application Experience service disabled (as I did) then re-enable and start it. Two years of aggravation ended.

Restart IIS- could be a process attached to the debugger

When I faced a similar issue, the only thing that seemed to work was:

• Right click the project, going to Settings, and making sure that both Debug and Release builds target the same settings, or have the settings in there that the application tries to load or save.
• Deleting the C:\Users(YourUserAccount)\AppData\Local(YourAppName) folder.
• Making sure that no files that I had in there were considered "Blocked". Right-clicking my project's included files, I realized that one icon was actually blocked and considered bad because it was downloaded from the internet. I had to click the Unblock button (in example, check this out: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "This file came from another computer and might be blocked to help protect this computer.").

For Windows Services using WCF, I ended the WFC host process and it worked. I hate it when this happens, and it happens randomly at times.

IF YOUR PROBLEM IS NOT SOLVED YET:

Visual studio's error is :

"The process cannot access the file 'bin\Debug**app.exe**' because it is being used by another process."

So ,go to task manager of windows(Ctrl+Shift+Esc),find your application name and force it to close by Endprocces.

My solution has nothing to do with versions, processes being locked, restarting, or deleting files.

The problem was actually due to the build failing, and not giving the correct error. The actual problem was a design flaw:

// 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();

After changing the scope of "a" to outside the function, or not using "a" after Task.Factory.StartNew();, I was able to build again.

This happened when using VS2012 Update 4 on Windows7x64 sp1.

Error message:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3390,5): error MSB3030: Could not copy the file "obj\x86\Debug\xxx.exe" because it was not found.

I have found with VS2013 I get this error regularly. Something that seems to work reasonably well is to perform a Rebuild Solution prior trying to run the application. I found that performing a CLEAN sometimes works, but the Rebuild Solution seems to work more consistently.

I had same problem. It said could not copy from bin\debug to obj.....

When i build web project i found my dll were all in bin folder and not in bin\debug. During publish vs was looking for files in bin\debug. So i opened web project file in editor and look for instances of bin\debug and i found all the dll were mentioned as bin\debug\mylibrary.dll. I removed all \debug from the path and published again. This time vs was able to find all the dll in bin folder and publish succeeded.

I have no idea how this path got changed in web project file.

I spent more than 5 hours debugging this and finally found solution on my own.

This is the right answer.

Disable antivirus and try. I was also facing that problem... but in my case antivirus was blocking my application when I disabled antivirus it resolved.

I faced the same error.

I solved the problem by deleting all the contents of bin folders of all the dependent projects/libraries.

This error mainly happens due to version changes.

If none of the above works, and you are developing a console application:

Try typing any character into Program.cs, then delete it. I have no idea why this works, but it seems to resolve 'Unable to copy' problem every time.

This is rather commonly caused by Avast.

I can usually run my projects in Release regardless, but when running in debug it would pretty regularly fail.

I just add an exclusion for my projects folder and the problem seems to go away. I assume this might also be cause by other antivirus software.

This helps for me after i remove read only flag from bin directory. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

1. Set another project as startup
2. Build the project (the non problematic project will display)
3. Go to the problematic bin\debug folder
4. Rename myservice.vshost.exe to myservice.exe

Renaming the .exe and .pub file worked for me, but really tedious. I also face the problem that I could not do editing during a debug session. Finally I went to the Advanced Security Setting Page, as per:

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

I un-select then re-select the "Enable ClickOnce security settings" checkbox. It's been problem free for some days now....

One thing that really helped me was adding the ".exe" on the Debug folder to the Exclusions on my Anti-Virus.

For me this was being caused by having a command prompt open in the targeted folder (C:\users\username\source\repos\project\project\bin\debug\app.publish).

Not sure why DEBUGGING requires access to the publish folder, but closing the command window solved the issue for me.

[Solved] Unable to copy exe-file from obj\debug to bin\debug:

I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen.

Basically, you need to close your first form which is running in the background and the main reason behind this error.

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();

This will solve the error perfectly.

Disable "Enable the Visual Studio hosting process"

Re-enabling the Application Experience service of Windows has fixed that kind of problems for me.

See the following links:

• Visual Studio output file permissions?
• Under which circumstances does the System process (PID 4) retain an open file handle?

I had the problem using Visual Studio 2008, 2010 and 2013 with Windows 7 64-bit.

In case somebody is running into this while trying to debug a Unit Test or Run a unit test I had to kill the following two processes in order for it to release the file:

I had the same problem multiple times but two different approaches helped in conjunction. In all cases one fact is interesting, namely that you can still rename the file. If a file is open by a process it's not possible to rename it. So it must be something else than a simple open file handle.

1. While compiling a solution that produces IL code Defender totally blocked it even if it contained just a few commands. Even adding the directory to the exclusion list of Windows Defender didn't help. I think the virus scan of Windows Defender has a flaw and goes into an endless loop (or a breakdown?) if a file has a certain unfinished state and it blocks the file. But it never recovers except after a PC restart.
2. I had the no access bug after I had to kill my solution while Debugging because the Debugger stop button didn't work, or maybe also while doing a regular stop using the stop button, I can't remember anymore. Some dlls seemed to remain locked, no delete possible but I could rename them (??). Then I used 'tasklist.exe' to list all the processes and to my astonishment there was a process still listed with my app's name. Without window. And Task Manager didn't list it in 'Details'. Strange. I could use taskkill /PID:... /F (the /F was necessary) and the process went. After that the compilation succeeded and everything was back to normal. Looks like this exe was holding the DLLs, but in a strange way.

It also occurred much more when Oracle VirtualBox was also running. Don't know whether that has an influence. Could also have a connection to the 'Out of Memory' exceptions that sometimes are reported while VirtualBox is consuming a lot of memory.

Now I use both approaches in conjunction whenever the problem occurs. And it still happens from time to time.