Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug

Question

Update: A sample project reproducing this bug can be found here at Microsoft Connect. I have also tested and verified that the solution given in the accepted answer below works on that sample project. If this solution doesn't work for you, you are probably having a different issue (which belongs in a separate question).

---

This is a question asked before, both here on Stack Overflow and other places, but none of the suggestions I've found this far have helped me, so I just have to try asking a new question.

Scenario: I have a simple Windows Forms application (C#, .NET 4.0, Visual Studio 2010). It has a couple of base forms that most other forms inherit from, it uses Entity Framework (and POCO classes) for database access. Nothing fancy, no multi-threading or anything.

Problem: All was fine for a while. Then, all out of the blue, Visual Studio failed to build when I was about to launch the application. I got the warning "Unable to delete file '...bin\Debug\[ProjectName].exe'. Access to the path '...bin\Debug\[ProjectName].exe' is denied." and the error "Unable to copy file 'obj\x86\Debug\[ProjectName].exe' to 'bin\Debug\[ProjectName].exe'. The process cannot access the file 'bin\Debug\[ProjectName].exe' because it is being used by another process." (I get both the warning and the error when running Rebuild, but only the error when running Build - don't think that is relevant?)

I understand perfectly fine what the warning and error message says: Visual Studio is obviously trying to overwrite the exe-file while it at the same time has a lock on it for some reason. However, this doesn't help me find a solution to the problem... The only thing I've found working is to shut down Visual Studio and start it again. Building and launching then work, until I make a change in some of the forms, then I have the same problem again and have to restart... Quite frustrating!

As I mentioned above, this seems to be a known problem, so there are lots of suggested solutions. I'll just list what I've already tried here, so people know what to skip:

• Creating a new clean solution and just copy the files from the old solution.

• Adding the following to the following to the project's pre-build event:

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

• Adding the following to the project properties (.csproj file):

   <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
  

However, none of them worked for me, so you can probably see why I'm starting to get a bit frustrated. I don't know where else to look, so I hope somebody has something to give me! Is this a bug in VS, and if so is there a patch? Or has I done something wrong, do I have a circular reference or similar, and if so how could I find out?

Any suggestions are highly appreciated :)

Update: As mentioned in the comment below, I've also checked using Process Explorer that it actually is Visual Studio that is locking the file.

Solution 1

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.

Solution 2

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 :)

Solution 3

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

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[miensol]

Have you checked if your application closes properly ? Does task manager show you [ProjectName].exe in list of processes ?

[codingbadger]

I've had this before and I simply renamed the file to .old etc and re ran the build. Not exactly a fix I know, but it worked for me.

[Julian]

@miensol: Yes, it seems to close properly. I get "The program '[1848] [ProjectName].vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0)." @Barry: renaming the exe-file in bin\Debug works, but as you said it's not really a solution and will be quite annoying to have to do every time. A bit better than restarting Visual Studio though...

[Patrick]

Does this happen on a clean Windows Forms solution as well? New project -> Windows Forms -> Build, run, shutdown, rebuild?

[Julian]

@Patrick: no, it does not happen on a clean solution.

[Patrick]

@Naliluj: I came across this article from a Microsoft forum that explains that it can be related to resource files. If you are using resx files this could give a hint.

[Julian]

@Patrick: I've already ran into that article several times. I do only have the default resx-file (and it is even empty). Also, the workarounds suggested by the article is the "if exist $(TargetPath).locked" and the "GenerateResourceNeverLockTypeAssemblies". Both are tried, and none of them worked :(

[Julian]

@fearofawhackplanet: No, it is not (and just to rule out the option 100%, I even emptied it but that didn't make it any better)...

[ThisIsTheDave]

For posterity, I had this problem and it was solved by adding the <GenerateResourceNeverLockTypeAssemblies>true</GenerateResou‌​rceNeverLockTypeAsse‌​mblies> element to my csproj file.

[Julian]

@ThisIsDave: as you can see from my question, this is one of the suggested solutions I found when searching, but it didn't work in my case.

[Tim Post]

Thanks for the heads up! I've protected the question and removed the 'me too' answers.

[Johan]

This solution did not work for me. Tried changing ether and both AssemblyVersion and AssemblyFileVersion.

[O. R. Mapper]

Something probably closely related (same MSBuild messages) in the SharpDevelop forums: thread

[jay_t55]

It's being used by another process. Sometimes, even if you close the project in Visual Studio, it still has a lock on the file. Exiting Visual Studio (and anything else that uses these files) should help.

[YazX]

pre-build even worked out perfectly, thanks

[Polyfun]

I agree--it is not necessarily VS that is locking the file. Virus checkers can be guilty of this. Try turning off your virus checker to see if that helps.

[Julian]

Sorry, I forgot to mention that I've already done that. And it says that is is Visual Studio (devenv.exe) that has a lock on the file ([ProjectName].vshost.exe). So that doesn't help me much either.

[Julian]

@ShellShock: disabling my anti virus (Avast) doesn't help either.

[Josh Robinson]

I've voted this up as this is what I've done in the past. I agree, it's a dirty solution but it does work. VS has had this problem for a few iterations. I'm loading my project from a network dir as well. It's been fully trusted, but it doesn't matter. It doesn't matter if it a drive mapping or a UNC either. Yeah, MS really needs to fix this one. They have a closed bug for it saying unable to reproduce. Lame!

[Julian]

That is one crazy idea, I'll give you that ;) What's even crazier, is that it actually seems to work! I have tested this several times now, and I can confirm that when using an assembly version such as "2.0.*" I get the error, but when I instead use "2.0.0" it works as a charm! I urge more people to test this, and if you find it working please vote up this answer, because this is something that needs to be known! Hope Microsoft picks up on this... Thank you drharris :)

[drharris]

I'm so glad it worked for you too! I still have no idea what could be causing this to happen. I made file and folder permissions wide open, removed as many .resx files as I could, used pre and post build actions, put that Lock line into the project file, created a whole new solution, and reverted to the previous version in subversion. None of it worked, and I just happened to try this, to put it back in as much a "default" state as possible. Sure enough, it worked, but I have no clue why.

[Julian]

I found this recent bug report about this exact issue: connect.microsoft.com/VisualStudio/feedback/details/558848/… That bug report provided a sample project that were able to reproduce the bug. The solution suggested by drharris worked there as well (see the workaround posted in the above link for a step-by-step solution to the sample project).

[Sharique]

this did not work for me, when I restarting VS I did not get error for sometime. Every time I get this error I have to restart VS 2010

[drharris]

Did you ensure that both AssemblyVersion and AssemblyFileVersion were set like this? Also, if you just make this change, you should restart Visual Studio before trying again. It more than likely has a lock on those files, and won't reset it until the next time. Doing a clean build may help too. You basically need to force VS to release those file handles.

[tbone]

fyi...this did not work for me. My settings have always been: [assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyFileVersion("1.0.0.0")]

[tbone]

For me, using Sysinternals ProcessExplorer, I can see a handle to that file, but when I click on it, no application is shown holding it, and when I try to close the handle, I get a "Error opening process: the handle is invalid." error in ProcessExplorer. Yet the lock still persists.

[Julian]

if you see at the very top of the question, there is a link to Microsoft Connect with a bug report and a sample project that reproduces the error: connect.microsoft.com/VisualStudio/feedback/details/558848/…

[Lazlo]

Argh! Such an annoying bug. Thanks for the fix. Has anyone reported this at MS side? Could we have a link on the follow-up?

[drharris]

I believe it was supposed to be addressed in SP1, but I don't have the guts to install it yet. Maybe someone can report back if they have installed it already.

[Frederick The Fool]

If you currently have [assembly: AssemblyVersion("1.0.0.0")], replace it with [assembly: AssemblyVersion("2.0.0.0")] (i.e. '2' instead of the '1'). It worked for me. Although I haven't checked, it's possible that simply changing the version to anything other than what you've got now can fix this problem.

[loverboy]

Works for dll too! VS says cannot copy the dll and after changing BOTH [assembly: AssemblyVersion] and [assembly: AssemblyFileVersion()] from 1.0.* to 2.0.0.0, it worked.

[Winger]

This is the only solution that worked for me as well. Thanks @Nailuj!

[NCCSBIM071]

I had this same problem. I had three projects under one solution, an asp.net website project, a vb.net library project and C#.net library project. Website project build successfully but other project did not build and gave the same exception as above. I tried changing the AssemblyVersion but it did not work. What i tried was changing the readonly property. Removed readonly property and it worked. Now all the three projects in the solution build successfully. Now i again see the readonly property of the two project folder and i see they are readonly still, but it works. :)

[jaywayco]

This works every time for me. It seems to be to do with the vshost process that is generated and started for services

[Seamus]

We recently experienced this on a WinPhone 8 project. Inexplicably, the cause was using the Tuple type. Removing the code that used a Tuple the problem went away. Add the code back the problem returned.

[Bob]

Even better: this isn't just the auto-increment. I can't change AssemblyVersion, whether with my own program, Notepad++, or even VS itself. On the other hand, it seems that only changes to AssemblyVersion trigger it. AssemblyFileVersion and AssemblyInformationalVersion can be freely changed.

[Dusty]

I have Avast installed and this morning I got a random MVC error saying that my dll had a virus in it. After the error, i could no longer build my MVC project. I added an exception to the Avast File System Shield and everything is working again.

[sawe]

unbelievable!!! it seems changing to a version other than the current one fixes the problem, thanx

[John S.]

If this works for you (as it did for me) I later found that it was because the copy command was not on the last project built. If you put the copy command on the last project (right click solution > build order) that will also correct this problem.

[Fopedush]

This worked for me as well. I'm not sure that I understand why, as process explorer showed devenv.exe was holding the locking handle. Nevertheless, turning off indexing fixed the problem.

[mizzle]

I had same issue with VS2012, closing VS did not do the trick - have to kill all the msbuild.exe tasks manually

[DJH]

@Fopedush I encountered this problem with the same solution, although I didn't see this question at the time. This answer has some explanation as to why it helps.

[Martin Capodici]

This one did it for me.

[Elvedin Hamzagic]

This is for sure easier than restarting VS.

[Coops]

"Page not found" for connect issue, did they just delete it out of embarrassment =S Was there ever a posted solution/workaround for this?

[Tomás]

+1 I previously tried everything else (1. task manager, 2. process explorer i.e. close handle which windows wouldn't let me do, 3. Disabling antivirus, 4. excluding APP_DATA/Local/Microsoft/Visual Studio from Windows Indexing service.) but this tip re: "Application Experience" service is the only one that saved me banging my head against the wall. I enabled it and the problem went away. Funny thing is, after I disabled it again everything was still OK. I haven't had any more problems. But definitely this is the only thing that sorted it for me.

[Drew Chapin]

Disabling the hosting process worked for me. It continues to work after re-enabling it as well. I spent 4 hours trying to fix this issue trying hundreds of solutions. This is the only one that even remotely seemed to work.

[Richard]

And here we are in 2015 and in VS2015 and the problem still occurs and the solution is still the same.

[ivan_pozdeev]

The solution may work, but you lose sane version information in your files as a result. comment36988469 looks closer to the root cause.

[fose]

I ran into the same problem using VS 2015 Enterprise with Update 1 on WIndows 8.1. I fixed the Problem on @Nailuj advice, but I want to point out that in my AsseblyInfo it said [assembly: AssemblyVersion("1.0.0.0")] and to make it work I changed it to [assembly: AssemblyVersion("1.0.0")]

[E_Blue]

Work for me too!!! The only other thing that work also is delete the bin folder before run the application, but you must to delete always before run, very annoying.

[Tim Sexton]

I'm using VS 2013 and I was able to just kill the "XDesProc.exe *32" process (Microsoft Visual Studio XAML UI Designer) in task manager prior to each build and that did the trick. No need to restart VS because the XAML UI designer seems to reload every time you open a *.xaml file in design view.

[ldobson]

Finally! Yes. This did the trick for me, too! Wonder why it was disabled in the first place. Thanks for the answer. I tried to fix this weeks ago but just took another look. Been using another dev machine in the meanwhile.