114

I've got a C# webforms app, that until today had been working just swimmingly.

Now today, all of a sudden, every time I try run the app, I get a file locking error:

Unable to copy file "obj\Debug\MyProject.exe" to "bin\Debug\MyProject.exe". The process cannot access the file "bin\Debug\MyProject.exe" because it is being used by another process.

Googling the error doesn't come up with anything beyond the obvious, i.e. VS thinks the file is locked. And it is definitely Visual Studio itself that locks the file, because when I close VS and reopen it, the project executes fine - the first time. When I try to run it a second time, I get the file locking error.

Closing VS and reopening every time I want to run the app is not a viable workaround! How do I find out what's locking the file, and stop it from getting locked?

EDIT: Another interesting discovery: I don't even have to run the app. Just compiling it once causes the file locking; I cannot compile twice in a row!

This problem is specific to one project in my solution. All other projects work fine and can be executed as many times as I like. It's only this one project that gets itself locked up.

Mike G
  • 4,232
  • 9
  • 40
  • 66
Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • can you try killing the vshost.exe to see if that helps? – rene Feb 27 '11 at 15:55
  • @rene - there's no vshost.exe process. Did they rename that in VS 2010? – Shaul Behr Feb 27 '11 at 15:57
  • [name of your app].vshost.exe – rene Feb 27 '11 at 15:59
  • @rene - no, nothing shows up in the current processes by that name – Shaul Behr Feb 27 '11 at 16:01
  • currently you have the issue and the [app].vshost.exe is not running? – rene Feb 27 '11 at 16:03
  • 1
    @Shaul have you added an custom usercontrol to your form? try closing the designer before running: http://stackoverflow.com/questions/2690119/visualstudio2010-debugging-the-process-cannot-access-the-file-because-it-is – rene Feb 27 '11 at 16:23
  • @rene - Yes, I do have custom usercontrols. No, closing the designer doesn't help. I closed all windows, and still the error comes up. – Shaul Behr Feb 27 '11 at 16:26
  • did you checked the links in the answer from Bradly? Can you tell something more about that specific project? Does it reference stuff? thirdparty stuff? T4 generation going on? customized build file? clickonce? Can you compile the *.csproj file from the commandline twice? – rene Feb 27 '11 at 17:05
  • @rene - Tried links from @Bradley, no help. Project is a Winforms EXE, including several custom controls. Never done a command line compilation before. MS help on the subject is totally useless. How do you do it? – Shaul Behr Feb 28 '11 at 12:47
  • @rene - Found how to do it with MSBuild. Works fine from the command line, and it doesn't lock the file. File only locks when compiling within VS 2010. – Shaul Behr Feb 28 '11 at 13:11
  • Look at this SO: http://stackoverflow.com/questions/2895898/visual-studio-build-fails-unable-to-copy-exe-file-from-obj-debug-to-bin-debug – Boris Ivanov Mar 23 '17 at 20:02
  • Why is this question projected? There isn't really any acceptable solution to the problem in the answers. – Florian Winter Sep 14 '17 at 08:34
  • In my case, I changed the port on properties project/web/servers/Project url, then I put a different and free port – Luis Armando Feb 22 '23 at 21:16

36 Answers36

167

I have found a simple solution which works for me. It goes like this:

When the problem occurs, just change the building configuration at the top (if in “Release” to “Debug” and vice versa), build and then change back to previous configuration and build again.

screenshot

I suppose that changing the configuration releases the vcshost and devenv.

dakab
  • 5,379
  • 9
  • 43
  • 67
Yechiel B.D.
  • 2,011
  • 2
  • 13
  • 9
  • 3
    Best answer, IMO. (Ah- he gave himself the cred.) – Jason P Sallinger Aug 18 '15 at 15:06
  • This is a great workaround! Though sometimes it stops working for some reason (?). – Christopher Apr 15 '16 at 10:39
  • 4
    @ChrisEmerson I've noticed that too. I can switch to Release and build and run the app, but can't even build the project after switching back to Debug. – Zack May 18 '16 at 19:51
  • I ended up have to restart Visual Studio to get rid of the assembly. I tried to reset IIS, and the solution above but I can still see the dll file sitting in the folder C:\Windows\Microsoft.NET\assembly\GAC_MSIL – Weihui Guo May 23 '16 at 13:55
  • Thanks. In my case I don't even need to build it after I switch configuration. Just switch to Release and then back to Debug. It starts building. – dotNET Nov 18 '16 at 15:36
  • 3
    THis worked exactly once, then never again. Not even after restarting VS. No matter how much I switch between Release and Debug, it fails. – Frank H. May 08 '17 at 12:14
  • I can build project under 'release' but switching back to debug gives me same result - VS2015. Anyway at least I can use my service. – FrenkyB Jun 09 '17 at 04:48
  • This workaround cannot be used when building automatically using an automated build system. – Florian Winter Sep 14 '17 at 08:31
  • Still a valid workaround in Visual Studio 2022. – Dan May 25 '22 at 10:59
29

Well, I solved the problem myself - though I still have no clue why. I decided to isolate the problem by removing all files from the project, then re-adding them and determining that way which file was the source of my trouble. So, one by one I reintroduced files to the project, compiled & cleaned each step of the way... until... I added the last one...

... and everything still worked fine.

I did a compare to the source control of my original .csproj; no real differences. And even when I tried reverting to the previous version of the .csproj, it still worked.

Black magic. If it works, sometimes it's better not to ask why - just accept it and move on...

EDIT: The problem is a recurring one, and I believe I've isolated it to when I have the form designer open of an abstract/generic form at compile time.

Lesson learned: Make sure the Form Designer of any abstract or generic forms or controls is closed before you compile! If not, you have to close VS and reopen!

Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • 1
    Maybe it's because whatever file was having the issue wasn't being accessed by whatever process anymore since it was removed. Removing all of the files SHOULD solve that indeed. Good thinking. – Jeff LaFay Feb 28 '11 at 13:49
  • 2
    This still happens to command line only projects (no form), so I'm not sure you are really on to anything. – Zack May 18 '16 at 19:52
17

What we have discovered here, is the following: In the project properties page, Debug tab, uncheck the "Enable visual studio hosting process". I am unsure what this property is for, but it does the work once unchecked.

Yechiel B.D.
  • 2,011
  • 2
  • 13
  • 9
  • 4
    It does solve the issue but Console.WriteLine() no longer outputs strings in the Output window. – Pierre Fournier Jul 27 '15 at 17:15
  • 2
    The problem still persists after unchecking the box on a console app. – Zack May 18 '16 at 19:53
  • 2
    It works for me on a Windows client project. I unchecked the box, built successfully, and then re-checked it and built successfully again. – Fei-Xue Oct 27 '16 at 16:43
  • 1
    not working for me. Now app itself locked. not host app. – Boris Ivanov Mar 23 '17 at 19:54
  • Worked with me for a project containing an interface for a second WCF service project. The project DLL with the interface could not be copied/replaced. I unchecked the setting in the WCF project, and this released the hold on the project with the interface. Now I can build without issue. Another note, this project was set up to copy the DLLs to a third location from the obj folders, which is – Jonathan Walton Mar 29 '21 at 17:56
15

Solved by closing all instances of MSBuild.exe in the windows task manager

lloyd
  • 1,089
  • 1
  • 17
  • 39
9

Actually you should want "Enable the Visual Studio hosting process" checked. At least for VS2010 anyway. And I also have:

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

in the pre-build options. This problem has dogged me for a very long time and it wasn't until John W. mentioned this check box that I even took notice that it existed and low and behold it was already unchecked.

Also notice that -app-vshost.exe runs in the background even when not debugging. Which is what makes it successfully build and run every time I guess. It wasn't running before. And I also tried cleaning out the debug and release folders and changing the target type constantly and nothing worked except as described above. My solution before was to just wait 5 minutes between builds, which got super annoying and time-consuming to get anything done. I haven't seen any change in behavior where it mattered what tabs where open or XNA vs windows form or designers being opened. This issue occurred in 32-bit or 64-bit builds and didn't matter if I killed an app with ALT-F4 or killing it with task manager, which would, in theory, not allow the app to close or release resources. At first I thought it was a garbage collection issue.

Justin W
  • 91
  • 1
  • 2
8

I have overcome this problem by renaming the locked file (using Windows Explorer). I was not allowed to delete the file, but renaming the locked file works!

Ola Eldøy
  • 5,720
  • 7
  • 49
  • 82
6

Little late to answer, but I solved this by going to the properties of the project > tab "Debug" > unchecked "Enable the Visual Studio hosting process" option.

Thameem
  • 700
  • 1
  • 13
  • 38
John Willemse
  • 6,608
  • 7
  • 31
  • 45
5

I solved this by deleting the folder bin\Debug and, possibly, restarting VS

Johannes Wentu
  • 931
  • 1
  • 14
  • 28
  • The problem is you can not do this every time. For me, error happens every time I do rebuild and then try to run the app. – FrenkyB Oct 01 '19 at 16:36
4

Unfortunately none of the answers worked for me. This is what solved it:

Win Key + R and run resmon.exe. There you'll find the EXE process that VS claims to be using the file. Right click and end the process. Although you might get an Access Denied error message, it will be suspended and you'll be able to build again.

Alaa M.
  • 4,961
  • 10
  • 54
  • 95
  • 1
    Brilliant, worked a treat. Extra note for anyone trying this though - when I opened Resource Monitor it defaulted to the Disk tab, couldn't see the exe it was complaining about there, had to switch to the Memory tab – d219 Nov 12 '21 at 13:21
3

Run this command from the Run box:

net stop iisadmin /y

and then

iisreset

worked for me. vs 2003

toha
  • 5,095
  • 4
  • 40
  • 52
2

For me, it was a Windows Service that was installed and running. Once I stopped it, the build was successful.

Garrison Neely
  • 3,238
  • 3
  • 27
  • 39
2

I had a similar error but during the deployment of the UWP application. Finally, I found out the process that used a file that caused this error and stopped it. Credits to this link. Copy-pasted version is below.

How to Solve the Issue?

One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.

Identify what program is using a file

Using Process Explorer there is a simple way to find the program:

  1. Open Process Explorer (running as administrator).
  2. On the toolbar, find the gunsight icon on the right.
  3. Drag the icon and drop it on the open file or folder that is locked.
  4. The executable that is using the file will be highlighted in the Process Explorer main display list.

Identify which handle or DLL is using a file

  1. Open Process Explorer (running as administrator).
  2. Enter the keyboard shortcut Ctrl+F.
  3. Alternatively, click the “Find” menu and select “Find a Handle or DLL”. A search dialog box will open.
  4. Type in the name of the locked file or other file of interest. Partial names are usually sufficient.
  5. Click the button “Search”.
  6. A list will be generated. There may be a number of entries.

And then kill this process.

Alex Misiulia
  • 1,542
  • 17
  • 16
1

Recently ran into this problem when attempting to build a solution I am working on (not just a winforms proj).
In addition to build failure, I noticed that cleaning projects would quietly fail (checking the bin folder showed that the files had not actually been erased) and closing the Visual Studio did not end the devenv process - rather, it caused it to crash. Windows recovery process would then restart the Visual Studio.

After some trial and error, I found the problems only happened to me when I opened the solution from the "Recent" menu on starting up VS.
Opening the solution from File >> Open >> Project/Solution found it working as per usually.

Currently no idea why - will keep looking into this but for now, at least I can work!

Guy Passy
  • 694
  • 1
  • 9
  • 32
1

Just check the references and remove the self-reference to the project.

Explanation: 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).

I literally removed the whole source code regarding the custom control and the problem still remained, 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!!

David Silva-Barrera
  • 1,006
  • 8
  • 12
1

I had the same issue on my Xamarin application in visual studio and it was resolved by unplugging my test mobile device. The application was closed and the debugger was stopped but the error was still happening when trying to build or rebuild the solution. It only stopped after i unplugged the device because i had to receive a call.

Tomislav3008
  • 121
  • 9
1

Just to throw in my 2 cents. My issue was solved by opening Task Manager and killing the application. It was running in the background without any indication that it was running at all (no item in the task bar, no ui, nothing), but I am not sure why this happened. Obviously the debugger was not running and I only had a single instance of VS opened at the time. It amazes me that this is still happening in this VS 2017.

Perhaps I can add a build step that looks for the application running the background and kills it before starting the new one.

Benjamin McGill
  • 359
  • 3
  • 5
1

I had the same issue and could not rectify by using any of the methods mentioned in previous answers. I resolved the issue by killing all instances of "SSIS Debug Hist (32 bit)" in task manager and now working as normal.

B.M.
  • 251
  • 2
  • 11
1

I had this issue (and its an issue I have seen in other places not just VS).

It's caused by Dropbox (in my case). After editing some code and hitting run, sometimes dropbox immediately locks the file (so it can process it).

Solution 1. Just hit run again

Solution 2. Pause dropbox. (not good if your using dropbox as your cloud backup)

Solution 3. Remove the build folder from dropboxes sync list.

KevinLeeSmith
  • 49
  • 3
1

Deleting Obj, retail and debug folder of the .NET project and re-building again worked for me.

Siddhant Gupta
  • 86
  • 1
  • 4
1

This got me stuck for over two days, had to reclone the project and save the project folder in a different name, but today I found the solution from a microsoft dev forum.

solution:

Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:

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

This code will copy the file to a different name, and allows the build to continue successfully.

Chidi-Nwaneto
  • 634
  • 7
  • 11
0

What worked for me was restarting IIS

Beanwah
  • 1,290
  • 2
  • 17
  • 28
0

i had this same problem as well. changing the debug/release config didn't do the trick. at least not without building in between.

in my solution (winform) it was solved by opening the mainform of the winform in the designer. switching to code (F7). Then closing the code, closing the designer of the winform and rebuild all (ctrl-shift-B). This worked for me.

seems like some kind of handle from within the winform app (which runs a backgroundworker) still had a file handle on some of the other libraries used.

Obelix
  • 708
  • 11
  • 24
0

I had two instances of Visual Studio opened the same solution.

Janis S.
  • 2,526
  • 22
  • 32
0

In my case there were some vstest processes running (with various names but all containing the string vstest). I had to terminate them in taskmgr.

J T
  • 401
  • 1
  • 6
  • 11
0

Same error, solved by updating Google Nuget support packages

Gustavo Baiocchi Costa
  • 1,379
  • 3
  • 16
  • 34
0

How is your web app configured? Does it run under Cassini (the tray web server) or IIS?

This shouldn't happen normally though. I think ProcessExplorer can tell you what files a process has locked. If not process explorer one of the other sysinternals tools.

One thing to try before even downloading one of the SI tools is to stop the Cassini web server, and seeing if that frees up the file.

Andy
  • 8,432
  • 6
  • 38
  • 76
0

When I ended the process .Net Core Host, everything built fine. I didn't have to close Visual Studio or do change anything else.

slimeygecko
  • 630
  • 7
  • 13
0

For those who are developing in VS with Docker, restart the docker for windows service and the problem will be solved immediately.

Before restarting docker I tried all the mentioned answers, didn't find a msbuild.exe process running, also tried restarting VS without avail, only restarting docker worked.

Carlos
  • 153
  • 3
  • 9
0

One more solution: when the files get locked, blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)") with it's id in parentheses. To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".

TripleAccretion
  • 312
  • 3
  • 10
0

I recently ran into the issue when deploying to Service Fabric. The error is implying a 'file' is in use, however, I found that the port was being used by another IDE. By stopping a running service which was already hosting on the port, I was able to stop this exception from occurring.

osoclever
  • 373
  • 7
  • 16
0

I had faced the same issue. I tried Several Solutions listed above but they didn't work for me.

I solved this issue by Closing the Connection from the Server Explorer and closed all the Tabs which was open in the Visual Studio.

Jayesh Baviskar
  • 295
  • 4
  • 3
0

If this is an SSIS project, then open task manager and kill all instances of DtsDebugHost.exe, that should release the locked files.

HamsterWithPitchfork
  • 750
  • 1
  • 12
  • 21
0

I use Visual Studio Code and I received this error because the dev server was running (I ran the dev server by pressing Ctrl + F5).

Thus, I just clicked on the stop sign to stop it and the error went away.

Seif
  • 701
  • 4
  • 13
  • 32
0

I struggled with issue for 5 days and could get the source of the problem through Event Viewer Logs; Port 443, my application trying to access was in use, so I had to change the registry settings ; Basically you will b able to reach to source of issue thru error logs in event viewer.

user11078255
  • 21
  • 1
0

I think most people who answered are a bit clueless and have found a solution by trial and error. I too had this issue recently and looked at the various solutions in this thread and they did not make much sense. I looked in to my project's makefile (it is handmade by my project lead) and I found -j11 in there. I replaced that with -j1 and it fixed the problem. The hunch was that make was probably doing a bad job at running multiple jobs (threads) i.e. while one thread was working on a file, another thread was trying to use it.

For those who use an IDE to compile your code, you need to look for a build property where you can set the number of jobs and then try compiling your code with the number of jobs set to 1. You might also have to close and restart the IDE (it all depends on how the IDEs are programmed).

I understand that this might hinder the performance of your builds but there is probably no alternative to this until either make fixes this bug (if there is one, I haven't bothered to dig in) or the makefile generators become smart enough to prevent this situation.

RcnRcf
  • 356
  • 1
  • 8
0

Disabling my antivirus software simply solved the problem.

I tried almost every answers of this question but unfortunately none of the answers worked for me. Suddenly my antivirus software got into my head and I disabled it and everything worked fine. After that I added the path of my project to ignoring list of my antivirus.

Hossein
  • 1,640
  • 2
  • 26
  • 41