The process cannot access the file during compile. RRS feed

  • 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?

    • Moved by Brittany Behrens Thursday, June 24, 2010 8:44 PM (From:Visual Studio Editor)
    Tuesday, June 22, 2010 6:53 PM

All replies

  • 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

    Tuesday, June 22, 2010 8:36 PM
  • Hi Brittany, I'm using C# with the 4.0 framework.
    Wednesday, June 23, 2010 6:34 PM
  • 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...


    Friday, June 25, 2010 4:18 AM
  • Hi Norm,

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


    Figo Fei
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com 

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, June 25, 2010 8:32 AM
  • 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

    • Marked as answer by Figo Fei Wednesday, June 30, 2010 8:10 AM
    • Unmarked as answer by Figo Fei Monday, July 12, 2010 2:56 AM
    Monday, June 28, 2010 1:53 PM
  • 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.


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

    Friday, July 9, 2010 6:11 PM
  • 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



    Figo Fei
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com 

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Monday, July 12, 2010 3:05 AM

    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.



    Friday, July 16, 2010 7:59 AM
  • // 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?


    Friday, July 16, 2010 2:48 PM
  • 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.



    • Proposed as answer by Andrew Skalkin Friday, October 8, 2010 7:47 PM
    Sunday, September 5, 2010 11:57 AM
  • Alex,

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


    Friday, October 8, 2010 7:46 PM
  • 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. 




    Wednesday, October 27, 2010 5:20 PM
  • 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( "" )] in AssemblyInfo.cs). Sounds weied but it seems to work :/


    Wednesday, January 19, 2011 4:08 PM
  • 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.


    Friday, July 15, 2011 3:48 PM
  • 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( "" )] in AssemblyInfo.cs).

    Sounds weird but it seems to work :/

    • Edited by joe mooney Wednesday, November 28, 2012 7:38 PM
    Wednesday, November 28, 2012 7:36 PM