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

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 has 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 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 works, untill 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 comment below, I've also checked using Process Explorer that it actually is Visual Studio that is locking the file.

Answer 1

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

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

Answer 3

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.

Answer 4

The answer from drharris worked for me too. I can't believe it! Thanks for posting this.

Answer 5

drharris' answer worked for me too! This bug has been annoying the hell out of me for the last couple of weeks. I tried all the other workarounds you mentioned, most of them either didn't work or were way too tedious to be of practical use. Since I edited the Assembly.cs file a couple of hours ago, it hasn't come back once.

I would have posted a comment with a thank you to drharris's answer if I'd had enough reputation here to do so. I do have enough for a vote up to the answer and the question though.

Answer 6

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

Answer 7

The answer from drharris worked for me too!!

Changing from AssemblyVersion("2.0.*") to AssemblyVersion("2.0.0.0") solved the VS 2010 bug -- Unable to copy file "obj\Debug\XXXX.dll" to "bin\Debug\XXXX.dll". The process cannot access the file 'bin\Debug\XXXX.dll' because it is being used by another process --

I hope Microsoft guys will fix this item soon!