The process cannot access the file during compile.

Question

I have a solution loaded in VS2010 with a form open. In the same solution I have user controls that appear on that form. When I try to recomplie i get error messages saying the process cannot access the file ...dll. This was possible in VS2008. The only work around is to exit Visual Studio. Has anyone know why visual studio is locking files itself?

Answer 1

Hi Norm - Which language are you coding in?  Errors on compilation are typically investigated by language teams, not the core text editor team, so I'll move this into the appropriate forum once you specify your language (VB, C#, etc.).

Thanks for posting,

Brittany Behrens | Program Manager | Visual Studio Platform - Editor | The Visual Studio Blog | @VSEditor on Twitter

Answer 2

Hi Brittany, I'm using C# with the 4.0 framework.

Answer 3

Hi Brittany,

I'm experiencing the exact same problem. I'm building against .NET 3.5 and I'm getting the"7    Unable to copy file "obj\Debug\PowerPack.dll" to "bin\Debug\PowerPack.dll". The process cannot access the file 'bin\Debug\PowerPack.dll' because it is being used by another process.

In that project, I have forms that contain custom controls which are part of the same project. If those forms are closed in the designer, debugging starts just fine (assuming the file hasn't been locked before). I vaguely remember that this problem existed in VS2008 but I think they've fixed it in SP1.

Restarting VS2010 after each debugging session "solves" the issue, but it's very frustrating...

Regards,
Andrew

Answer 4

Hi Norm,

Can you reproduce this problem, reproduce steps help us better clarify and investigate this issue.

Thanks.

---

Figo Fei
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [e-mail] 

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 5

I've seen problems like this in the past but it was related to a program outside VS.  Anti-virus programs and the PDB service were common culprits.  I'd recommend that when you replicate the issue again you run Process Explorer to determine if VS or some other app has the binary locked.  This will give you a better idea of what is going on.  You should also consider disabling any addins until you've identified the program.

Michael Taylor - 6/28/2010
http://msmvps.com/blogs/p3net

Answer 6

Hi Michael,

I forgot to mention that I did use Process Explorer and it is VS that has the binary locked. The only installed add-in I have is Resharper.

Regards,
Andrew

P.S. Just wondering why Michael's reply was marked as an answer? It definitely is not.

Answer 7

Hi Andrew,

Feel free to unmark if the problem persists, and can you please also try to do the troubleshooting steps mentioned at http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/0376db8f-4761-4ae5-9af2-98c53216318a#VS_IDE_unexpected_problems

HTH.

Thanks.

---

Figo Fei
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [e-mail] 

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 8

 

I also run into the problem. It seems that this happens only when one of the user controls is open in a designer window while debugging.

Regards

Erwin

Answer 9

// Wrote a lengthy post yesterday, hit "Submit", the page refreshed but my post is not there :(

I disabled all extensions, rebooted, but the problem is still there. It is reproducible on both my dev machines (XP 32 and XP 64). Unfortunately, I can't reproduce it with the simple WinForms project/library. My real project has dependencies on few MC++ and C++/CLI dlls, don't know if that matters or not.

Is there any additional information I can provide?

Thanks!
Andrew

Answer 10

I don't know why Visual Studio is locking the target dlls itself but I had the same problem with a WF-project. Unfortunately this behavior is very hard to reproduce. But there is a workaround for this problem: http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project.

Regards

Alex

Answer 11

Alex,

Thanks a lot, this workaround works just fine and it now saves me a lot of time and nerves :)

-Andrew

Answer 12

I just wanted to say that this problem started with me today.  (VS 2010, C#) I have been working on this program for a month without this problem, now today it started.  I start VS, change code, compile and test and quit program.  Make another change, compile and BOOM Unable to copy file "obj\x86\Debug\progname.exe" to "bin\Debug\progname.exe" because if is being used by another process.  

ProcExp shows only Visual Studio (actually devenv.exe) using this file. There is only one instance of VS running. There are two listing on my debug\progname.exe, one is a Type DLL, the other is a Type handle.

 

Using devenv /ResetSettings  did not resolve anything, but wasted 10 minutes putting everything back to my desired view. 

 

Using the file delete trick mentioned above 

( http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project )

solves the problem for one change, but on the next change the "exe.locked" file is locked and cannot be deleted.  Then the rename fails.  

 

The debug\progname.exe file name remains locked even after closing the project. 

 

Closing VS, manually delete the files in the debug folder, opening VS and my solution, then Build->Clean Solution seems to work for me, at least its working now after I did all of that stuff. 

 

 

 

Answer 13

It seems to be a known issue: https://connect.microsoft.com/VisualStudio/feedback/details/568672

The workaround is to disable the auto-incrementing of the assembly version (change [assembly: AssemblyVersion( "1.0.*" )] to [assembly: AssemblyVersion( "1.0.0.0" )] in AssemblyInfo.cs). Sounds weied but it seems to work :/

 

Answer 14

I searched everywhere for the solution to this problem.

I then started analyzing the problem and found the culprit and the solution:

Stop and disable the "WINDOWS SEARCH" service.

 

Answer 15

Sure enough this solved the problem for me too. Thanks Al3x3

It seems to be a known issue: 
https://connect.microsoft.com/VisualStudio/feedback/details/568672

The workaround is to disable the auto-incrementing of 
the assembly version (change [assembly: AssemblyVersion( "1.0.*" )] 
to [assembly: AssemblyVersion( "1.0.0.0" )] in AssemblyInfo.cs). 
Sounds weird but it seems to work :/