VisualStudio2010 Debugging - The process cannot access the file … because it is being used by another process

Question

I'm unable to debug a WinForms C# application using the released version of Visual Studio 2010 Prof.

I get the following error message after the second debugging run.

Error 9 Unable to copy file "obj\x86\Debug\Arrowgrass Reports.exe" to "bin\Debug\Arrowgrass Reports.exe". The process cannot access the file 'bin\Debug\Arrowgrass Reports.exe' because it is being used by another process.

I've tried a pre-build script to attempt to delete this file, but it's locked by Visual Studio.

There are a few references to this on the net so it is a know problem. Does anyone have a hotfix or effective work-around?

Answer 1

I have found this issue very easy to reproduce, and the fix for me is a variation on Richard Fors' answer. If I have a UserControl open in the designer, run the debugger, and then edit the UserControl, the subsequent rebuild will fail. If I close the UserControl before running the debugger I never get this error, so I just make sure to close the designer window before hitting F5.

Answer 2

As of October 2012, I still have that issue so the VS 2010 SP1 didn't solve the problem. What I did, and worked consistently, was disabling the hosting process in the projects.

To disable the hosting process:

.  Open a project in Visual Studio.

.  On the Project menu, click Properties.

.  Click the Debug tab.

.  Clear the Enable the Visual Studio hosting process check box.

Source: http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx

Answer 3

You can try to kill the vshost.exe process:

taskkill /F /IM "Arrowgrass Reports.vshosts.exe"

You might also be lucky and simply be able to move the file in question. Moving the file can be done by adding the following lines of code to the pre-build event of your project:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked" 

Answer 4

Disabling windows search did not fix for me. However disabling Antivirus did (our Antivirus is Symantec Endpoint Protection 11)

As such, I was able to fix this for myself by changing the Debug settings in the project to point the working folder to a path on the C: drive, and then excepting that path from the antivirus auto-protect scan settings.

I hope this helps someone.

Answer 5

I posted this answer in a similar question but figured I'd also say it here:

Alright... this might sound pretty crazy.

I've had this problem in VS2010 for the last couple of years. The workaround mentioned here works for me, but a lot of times I forgot to close all my forms/usercontrols first.

I've discovered that merely going to view the open files via:

Computer Management (compmgmt.msc)->Shared Folders->Open Files

will "Free up" whichever file is being locked. Very strange, but it works for me!

Answer 6

In my case, I did Project Properties-->Security Tab-->Uncheck Click-Once security settings (If it is checked). It worked for me. In my project, it was showing this error for a C++ dll being used in my C# project.

Answer 7

The condition described can also be caused by the offending DLL or EXE referencing itself; in which case the Process Explorer test described previously never returns a match (e.g. it's not running). This unexpected situation seems to be caused during some sequence of operations in VS2010 (and likely all previous versions) which insidiously adds the reference behind the scenes. The specific cause of this hasn't been tracked down (or resolved that I know of). To check for, and resolve this error simply make sure the offending DLL or EXE is not listed as a reference to itself.

Answer 8

Got the error ("The process cannot access the file … because it is being used by another process") when I modified the (Visual Studio 2010 C# Express with SP1) solution from two large (10 source files, ~500 lines per file) projects with one referencing the other, to lots (6) of smaller projects with lots of projects referencing other projects.

The references were to the dll- and exe files (the Debug versions of them), NOT to the projects even though the projects were in the same solution.

I then learned that references should be to projects, not files, for F12 to work properly. So I modified the references. That made F12 work (jump to the source file instead of some auto-generated interface description), and at the same time the "cannot access file" error during build disappeared.

I only got the "cannot access file" error when doing Release builds. The references were to the Debug versions of exe/dll's. I suspect that this mixing is what triggers the bug in VS.

Answer 9

I encountered this issue when developing windows services. I found out that it happens when the service is running. Thus, you only need to stop the service (from the services.msc console) and you're good to go !

Hope this helps. Tidjani.

Answer 10

Check Task Manager for the specified process and End the process explicitly. This solution worked for me.

Answer 11

I cant' write to a comment since not at 50 points but for me I excluded my project folder in ESET Enpoint Security ver 5. Seems like it blocked/hogged some files. My Error did not state which exe or file was in use so it took a long time to finally get to what JoeC said about Antivirus and tried it. Seems to be working now (Visual Studio 2010 SP1)

Answer 12

Closing recently changed User Controls solved the problem in my scenario. Hope this will help somebody out there.

Answer 13

Looks like this issue has (finally!) been fixed in the VS2010 SP1

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en

Answer 14

Please try uninstalling Windows Live SYNC. Does it still happen?

Answer 15

I think I just found the culprit and the solution.

Go to services and stop & disable the "windows search" service.

That solved the problem for me now.

Answer 16

For me the solution was to change the startup project to a dll (problem only occurs in debug mode when having an application as the startup project). If your solution contains several projects (and it will, and it will contain a .dll, else you would not get the problem), switch to that .dll, no .vshost.exe, no problem.

Also, killing .vshost.exe did not work for me, since immediately after starting again, it had locked the .dll.

Also, make sure to have your references clean, especially in more complex projects, and also prefer project references to assembly references, and so on. I suppose bad references (circular and similar) are bound to cause problems, at least so I have read.

A short article by me on this problem (and my solution)

How to "clean up" your references in a solution

Answer 17

Adding the following to the Pre-build event of the shared dll worked for me:

if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
  if defined exitprebuildfor$(ProjectName) goto :ok
  if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=

It's based on the solution given here but instead of just renaming the dll to .locked it keeps trying to rename it to .locked1, locked2. Using 10 I usually run into the problem once a day, but ant value can be used.

Answer 18

Simply make a copy of the whole project and run project from the new copy.... it will work fine. But you will have to end process of the debug somehow in-order to delete the older project.

Answer 19

Stop IIS service and try building it again or if you can afford to restart your pc, give it a try. Worked for me both ways.

Cheers

Answer 20

My problem was that Outlook 2010 (outlook.exe) was using the same port as my ASP.NET MVC project with IIS express.

Solution: close outlook.exe, run your solution and open outlook again (so that it uses another port).

Hopefully this helps somebody, because I received the same error message as described in this topic.

Answer 21

Try deleting .exe file in debug or release folder (whatever you working on) Windows will prompt that the process X has opened this and you can't delete it after that go to task manager and in details tab end task X process

Answer 22

Delete obj file.And stop your service and Restart again.Then you may solve the problem

Answer 23

The best solution for me was to move my project files out of My Documents - which is on a server managed by the IT department - and locate them locally on my C drive. Also working: unchecking the "Enable the Visual Studio hosting process" checkbox, as stated by other people.

Answer 24

If you are working on a C# project which is using reference of C DLL, then you can eliminate the error by checking the Allow unsafe code check box. I know I have not used pointers in my C# project but I was using some bitwise operator in C#. May be these C-like features morphed it as 'Unsafe' code.

Answer 25

What worked for me was removing "read only" status on the bin folder. Once I did that, it has worked ever since.

Answer 26

I've had this error when the project is on a remote share (like, if your $env:homepath is helpfully redirected by your IT department to a network share). Make sure your project is resident on a local drive.

Answer 27

My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).

A literally removed the whole source code regarding the custom control and last problem never stopped, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!

So: just check the references and remove the self-reference to the project.

Answer 28

Delete your Bin folder and run the application. This worked for me. :)

Answer 29

Simply turn off Visual Studio hosting in debug, run the project and again re on it and run project.

Open a project in Visual Studio.

. On the Project menu, click Properties.

. Click the Debug tab.

. Clear the Enable the Visual Studio hosting process check box

Answer 30

For Windows Project

The Visual Studio hosting process can hold the executable file pointer. To stop the host instance, open the Project properties and then go to Debug tab. Now uncheck the Enable the Visual Studio hosting Process option and then check the checkbox again to debug.

For web project

The IIS can hold the file pointer. Restarting the IIS can solve the issue.