Error Cannot access file bin Debug because it is being used by another process

Question

When I debug my project  I get following error       Unable to copy file  obj Debug My Dream exe  to  bin Debug My Dream exe   The process cannot access the file  bin Debug My Dream exe  because it is being used by another process     Using Process Explorer  I see that MyApplication exe was out but System process still uses it although I stopped debug before  Whenever I change my code and start debug it is going to happen  If I copy project to USB and debug  it runs OK   Why  How can I fix this error   I use Window 7 Professional  With Xp I have never got this error

User · Answer

I have faced the same issue  but none of the answers above helped me  I just simply closed my Visual Studio 2017 then re-run it  and It worked

User · Answer

I ve had this error crop up on me before  even in Visual Studio 2008   It came back and more prevalent in Visual Studio 2012   Here is what I do   Paste this in the troublesome project s pre-build event   if exist    TargetPath  locked  del    TargetPath  locked  if exist    TargetPath   if not exist    TargetPath  locked  move    TargetPath      TargetPath  locked

User · Answer

Solved  Error  Cannot access file bin Debug     because it is being used by another process   I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen   Basically  you need to close your first form which is running in the background and the main reason behind this error   To close the first form you have to add these two lines of code in the second form load event handler       Form1 form   new Form1        form Close      This will solve the error perfectly

User · Answer

Pre build command   if exist    TargetDir  old pdb  del    TargetDir  old pdb    amp   if exist    TargetDir   pdb  ren    TargetDir   pdb    old pdb    Helped

User · Answer

I have run to this same issue  and what I found is there are actually running mulitple Windows form application in the background  It happens when your application has two forms and you close the 2nd form which is not your main form so the application will not totally exited    I usually run my application    through its exe or run without debugging   Solution is close the other instance of Windows form application  This is one way to always close your application instance

User · Answer

This is pure speculation  and not an answer    However  I have been having this problem for a while    I came after a time to suspect an interaction between VS and my AV precautions   After some playing  it seems that it may have gone away when I modified my antivirus so that everything under the   C  Users username  AppData Local Microsoft VisualStudio 10 0 ProjectAssemblies   folder was not included in the real-time protection    It looks as if the build actually writes the DLL here first  then copies it to the final build location

User · Answer

Ugh  this is an old problem  something that still pops up in Visual Studio once in a while  It s bitten me a couple of times and I ve lost hours restarting and fighting with VS  I m sure it s been discussed here on SO more than once  It s also been talked about on the MSDN forums  There isn t an actual solution  but there are a couple of workarounds  Start researching here  What s happening is that VS is acquiring a lock on a file and then not releasing it  Ironically  that lock prevents VS itself from deleting the file so that it can recreate it when you rebuild the application  The only apparent solution is to close and restart VS so that it will release the lock on the file  My original workaround was opening up the bin Debug folder and renaming the executable  You can t delete it if it s locked  but you can rename it  So you can just add a number to the end or something  which allows you to keep working without having to close all of your windows and wait for VS to restart  Some people have even automated this using a pre-build event to append a random string to the end of the old output filename  Yes  this is a giant hack  but this problem gets so frustrating and debilitating that you ll do anything  I ve later learned  after a bit more experimentation  that the problem seems to only crop up when you build the project with one of the designers open  So  the solution that has worked for me long term and prevented me from ever dealing with one of those silly errors again is making sure that I always close all designer windows before building a WinForms project  Yes  this too is somewhat inconvenient  but it sure beats the pants off having to restart VS twice an hour or more  I assume this applies to WPF  too  although I don t use it and haven t personally experienced the problem there  I also haven t yet tried reproducing it on VS 2012 RC  I don t know if it s been fixed there yet or not  But my experience so far has been that it still manages to pop up even after Microsoft has claimed to have fixed it  It s still there in VS 2010 SP1  I m not saying their programmers are idiots who don t know what they re doing  of course  I figure there are just multiple causes for the bug and or that it s very difficult to reproduce reliably in a laboratory  That s the same reason I haven t personally filed any bug reports on it  although I ve  1 ed other peoples   because I can t seem to reliably reproduce it  rather like the Abominable Snowman   lt end rant that is directed at no one in particular gt

User · Answer

Make sure that any previous run of the application  for example  start without debugging option  is actually stopped  I was working on a WPF application  started without debugging and had it minimized when I kept getting the error  After closing the application VS behavior got back to normal

User · Answer

I had the same issue in Visual Studio 2013   I m not sure what caused this for my project  but I was able to fix it by cleaning the solution and rebuilding it    Build   Clean Solution Build   Rebuild Solution

User · Answer

Computer  right-click  -  manage -  Service  amp  Application -  service -  Enable Application experience   Worked For me

User · Answer

I solved this problem   near the debug you see drop down menu with some configuration  Default there was Any CPU  Select x86 and run the program it will work  If x86 not there go to configuration manager and add the x86

User · Answer

In my case was that I have enable  Show All Files   Visual Studio 2017

User · Answer

See my answer here if you re having this problem while running unit tests  Answer copied below      Building upon S  bastien s answer  I added a pre-build step to my test   project to automatically kill any vstest   executables still   running  The following pre-build command worked for me   taskkill  f  im vstest   exit 0       The exit 0 command is at the end to prevent build failure when there   are no vstest   executables running

User · Answer

i found Cody Gray  s answer partially helpful  in that it did direct me to the real source of my problem which some of you may also be experiencing  visual studio s test execution stays open by default and maintains a lock on the files   To stop that predominantly useless behaviour  follow the instructions from https   connect microsoft com VisualStudio feedback details 771994 vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel  Uncheck Test menu -  Test Settings -   Keep Test Execution Engine Running

User · Answer

At least in my case I ve noticed that visual studio 2012 was creating at least two msbuild exe ghost processes  which did not perish after build  These zombies apparently are causing file locks to appear   Killing msbuild exe s is one time solution  it needs to be done per build basis   But then I ve figure out that I could disable parallel build once and for all - went into Tools   Options   Projects and Solutions   Build and Run    maximum numbers of parallel project builds  - by default it has value of 8  I ve switched to 1  Works like charm   Of course builds are bit slower now  but better safe than sorry  At least for this particular small project I did not need more than one build thread

User · Answer

I have been plagued by this issue in Visual Studio 2017  It started about two or three weeks ago  and has severely eaten into my productivity  Clean and Rebulid haven t worked  even restarting my machine doesn t do the job   One way to deal with the issue is to clean the offending assembly  and to build  as opposed to rebuild  the project you want to run immediately afterwards  This works about 30  of the time   However  probably the most reliable solution I ve found is to open a Developer Command Prompt  and use msbuild directly  I ve been doing this for the last three days  and so far the problem hasn t happened once

User · Answer

Recently I ve been in a trouble with Visual Studio 2012 with same error description   The process cannot access the file because it is being used by another process      To fix this first of all you need to understand the application which still use it  I ve shutdown all processes like  MSBuild  and  MSBuild host   But this is not enough  If you have installed  Code Contracts  and turned on then it sometimes takes your DLLs for checking and hanging up on this operation   So  you need to stop all processes of  CCCheck exe  and that s all   Finally  to understand that process is using your DLL you always may try to just Delete  obj  folder in your File Manager and this operation will fail  you may see the  Message Window  with description of the hanging operation  Also  as a variant  you can try to use  Sys Internals Suite  application

User · Answer

I tried all these suggestions as well as other suggestions found elsewhere and the only thing that worked for me was restarting my computer  Then I did a clean solution followed by rebuilding  I am using Visual Studio 2013 for reference

User · Answer

I have opened a separate question regarding VS 2017 that had a similar behavior after one update  The problem seemed to be generated by the antivirus program although   I have added the bin folder to the antivirus exclude list  restarted the machine and now it seems to work

User · Answer

Another kludge  ugh  but it s easy and works for me in VS 2013   Click on the project   In the properties panel should be an entry named Project File with a value    your project name  vbproj  Change the project name - such as adding an -01 to the end   The original  zip file that was locked is still there  but no longer referenced     so your work can continue   Next time the computer is rebooted  that lock disappears and you can delete the errant file

User · Answer

Worked for me   Task Manager -  Name of project -  End task   i had 3 same processes with my project name    VS 2013  Win 8

User · Answer

Run taskmanager  Locate netcore and delete it  You can then delete the file manually or by running Clean

User · Answer

Close VisualStudio  ctrl-alt-delete  select Task Manager  find and end all MSBuild processes - VisualStudio basically has a pretty severe bug where it loses control of its debugger and the debugger maintains a lock on the  pdb file in the debug bin folder   After you end all the MSBuild  debugger  processes  delete the  debug bin folder and reopen your solution in Visual Studio   You re good to go now   Microsoft needs to fix this crap

User · Answer

It could be too late  But  I encountered similar problem and in my case the project had self reference  Hence  deleting it from the References worked like a charm

User · Answer

My problem was dotnet got hung up and whenever VS would try to make a new dll  or access an old one  the dotnet process would latch onto the dll and stop visual studio from cloning the dll  Solution is just to end all dotnet tasks in task manager it will only actually remove the dead one  if you are trying to end one and it won t shut down  that means it s working

User · Answer

I ve found the quickest way without closing forms or restarting VisualStudio is go to the project s compile page and click  Advanced Compile Options     button  Then make any change to one of the options  say  changing Generate Debug Info from Full to pdb-only   then click OK  It works every time and will have to do until MS fixes this bug  I ve never had this problem until I switched from VS2012 to VS2013   Another note  if you can t clean the project or solution  it won t build  The files are definitely locked by VS  not a antivirus problem  at least not in my case

User · Answer

One simple solution is you go to bin Debug folder  delete all the files in that folder  then rebuild  If it doesn t work  close Visual Studio then go to bin Debug folder using file explorer  on the left coner  click on File  Open Command Prompt  Open Command Prompt as Administrator   Enter this command  DEL  F  Q  A      then rebuild

User · Answer

I understand this is an old question  Unfortunately I was facing the same issue with my  net core 2 0 application in visual studio 2017  So  I thought of sharing the solution which worked for me  Before this solution I had tried the below steps    Restarted visual studio  Closed all the application Clean my solution and rebuild   None of the above steps didn t fix the issue    And then I opened my Task Manager and selected dotnet process and then clicked End task button  Later I opened my Visual Studio and everything was working fine

[visual-studio] Error: Cannot access file bin/Debug/... because it is being used by another process

Examples related to visual-studio

Examples related to debugging

Examples related to projects-and-solutions

Examples related to locked-files