Visual Studio Could not write to output file '...\obj\Debug\Foo.Bar.dll"

Question

I've got this error while compiling a big c# solution in Visual Studio 2010. Each time after compilation I had to delete obj folder of one the projects used by this solution. Otherwise I got the following error:

Could not write to output file '...\obj\Debug\Foo.Bar.dll'
The process cannot access the file because it is being used by another process

I've was looking for a solution all over the Internet and actually found/tried few of them.

For example : a lot of people on dev forums were suggesting not to start the compilation while UserControl (in some other sources From) designer is opened.

Some other people used pre-build scripts for obj folder removal, this particular solution is acceptable, but if the issued project is a widely used library its recompilation will cause recompilation of "parent" projects.

Yowl

Answer 1

Finally I've discovered a solution for this VS2010 (SP1 too) "bug" and I want to share it with stackoverflow users.

In my case the problem was that csproj file was SELF-REFERENCING the locked '...\obj\Debug\Foo.Bar.dll' file. Crazy I know. So I solved this annoying issue by removing the following line from .csproj file:

<Reference Include="Foo.Bar">
  <HintPath>obj\Debug\Foo.Bar.dll</HintPath>
</Reference>

Yowl

I was thinking of filling a bug for this issue, but since VS12 is already out Microsoft guys will probably mark it as "won't fix" :D Oh, have your guys checked if VS12 (mis)behaves in the same way? – Yowl

Just had same problem with VS2012 and this fixed it following a full rebuild. It was definitely related to the use of custom user controls but not sure exactly which aspect. – Burroughs

I agree with @shakinfree, I click-dragged a user control onto my form and this caused VS to add a self-reference to the project. Silly bug – Estivate

Answer 2

I initially found another solution to the problem as VS seems to lock the assembly in the obj\debug folder. I added a pre-build script to the project which fixed my problem.

del "$(ProjectDir)obj\*.*" /S /F /Q

After seeing the answer given by Salaros, that was indeed the problem. I created a new usercontrol that uses a Server control from another project. For some reason VS sometimes creates a self-references to itself when you view the usercontrol in design mode. Even removing the self-reference fixes it until VS thinks its time to add the reference again. Haven't found an exact pattern for that part.

PS: I'm using vs2012

Westfalen

please read my original question: "[talking about your solution]...this particular solution is acceptable, but if the issued project is a widely used library, its recompilation will cause recompilation of "parent" projects." this slows down debug dramatically – Yowl

Answer 3

This problem happened to me when I:

1. Opened Visual Studio
2. Ran debug
3. Went to C: and used system cleanup

If you try to build again, you will find this error.

Solution:

1. Close Visual Studio
2. Do system cleanup
3. Restart your computer
4. Open Visual Studio as administrator
5. Choose your project
6. Clean
7. Rebuild

Illimani

Answer 4

In my case for me somehow the exe file was missing from release. Not sure how this happened. I replace it with a copy from debug and all was fine. I should have checked this sooner but never thought that the file would just turn up missing.

Improvised