Build error: "The process cannot access the file because it is being used by another process"

Question

I have a C # webforms application that until today has worked smoothly.

Now today, all of a sudden, every time I try to start the application, I get a file lock 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.

An error when starting an error brings nothing but the obvious, i.e. VS thinks the file is locked. And definitely , Visual Studio itself locks the file, because when I close VS and open it again, the project runs fine - for the first time. When I try to run it a second time, I get a file lock error.

Closing VS and re-opening every time I want to run the application is not a viable solution! How to find out what is blocking a file and not blocking it?

EDIT: Another interesting discovery: I don't even need to run the application. Just compiling it once causes a file lock; I can not 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. This is only one project that itself is locked.

Answer 1

Well, I myself solved the problem, although I still don't know why. I decided to isolate the problem by deleting all the files from the project, then re-adding them and determining how the file was the source of my problem. So, one by one, I again entered the files into the project, compiled and cleared every step of the path ... to ... I added the last ...

... and everything is still working fine.

I compared the source control of my source .csproj; no real differences. And even when I tried to revert to the previous version of .csproj, it worked anyway.

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

EDIT: The problem is recurring, and I believe I isolated it when I got the abstract / general form constructor at compile time.

Lesson learned: Make sure that the form constructor of any abstract or general forms or controls is closed before compilation! If not, you need to close VS and reopen.

Answer 2

I found a simple solution that works for me. This happens as follows:

If a problem occurs, simply change the configuration of the building at the top (if in the "Vacation" section to "Debug" and vice versa), complete the assembly, and then return to the previous configuration and create again.

I assume that changing the configuration releases vcshost and devenv.

Answer 3

We found the following here: On the project properties page, on the Debug tab, uncheck the Enable visual studio process box. I'm not sure what this property is for, but it does the job right away without checking.

Answer 4

In fact, you need to check the box "Enable Visual Studio Hosting". At least for VS2010. And I also have:

if "$ (TargetPath) exists." del "$ (TargetPath) is blocked." if "$ (TargetPath) exists; if" $ (TargetPath) does not exist. "move" $ (TargetPath) "" $ (TargetPath ). blocked "

in the pre-assembly options. This problem reproached me for a very long time, and only after John W. mentioned this flag did I even notice that it exists and is low, and now it is no longer marked.

Also note that -app-vshost.exe runs in the background, even if it is not debugged. This is what makes it successfully build and run every time I guess. It wasn’t before. And I also tried to clear the debug files and delete the folders and constantly change the target type, and nothing worked except as described above. My solution used to be to just wait 5 minutes between builds, which became very annoying and took a lot of time to do something. I have not seen any changes in behavior when it is important which tabs open or open XNA or windows or designers. This problem arose in 32-bit or 64-bit builds and it does not matter if I killed the application with ALT-F4 or killed it with the task manager, which theoretically did not allow the application to close or release resources. At first I thought it was a garbage collection problem.

Answer 5

A bit late for anwer, but I solve this by going to the project properties> Debug tab> uncheck the box next to “Enable Visual Studio Hosting”.

Answer 6

VS2017 - Solved by closing all instances of MSBuild.exe in the Windows Task Manager

Answer 7

I overcame this problem by renaming a locked file (using Windows Explorer). I could not delete the file, but renaming the locked file works!

Answer 8

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

Answer 9

For me, it was a Windows service that was installed and running. As soon as I stopped it, the assembly was successful.

Answer 10

Run this command from the Run window:

 net stop iisadmin /y 

and then

 iisreset 

worked for me. vs 2003

Answer 11

Just check the links and remove the project’s self-esteem.

Explanation: My problem started after creating a custom control and dragging it into the tool palette to use it in design forms. First, a warning appeared that there was redundancy between the source user control (.cs) file and project executable files (.exe). An error occurred during execution / debugging: it is impossible to access (.exe) because it is being used (and this was true).

I literally deleted all the source code for the custom control, and the problem still remained until I checked the links, and it referenced itself to "be able" to get the old user control. I deleted the link and did !!

Answer 12

I had the same problem on my Xamarin app in visual studio and this was resolved by disabling my test mobile device. The application was closed and the debugger was stopped, but the error still occurred while trying to build or rebuild the solution. He stopped only after I turned off the device because I needed to call.

Answer 13

Just throw your 2 cents. My problem was solved by opening the task manager and killing the application. It worked in the background without any indication that it was running at all (there is no item in the taskbar, no ui, nothing), but I do not know why this happened. Obviously, the debugger was not working, and at that time I only had one instance of VS. It amazes me that this is still happening in this VS 2017.

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

Answer 14

How is your web application configured? Is it running under Cassini (tray web server) or IIS?

This should not be normal. I think ProcessExplorer can tell you which files the process blocked. If not a process handler, then one of the other sysinternals tools.

One thing to try before downloading one of the SI tools is to stop the Cassini web server and see if it frees the file.

Answer 15

IIS reboot worked for me

Answer 16

I had the same problem. changing the debug / release configuration did not help. at least not without intermediate between themselves.

in my solution (winform) it was solved by opening the main winform form in the designer. switching to code (F7). Then close the code, close the winform constructor, and rebuild everything (ctrl-shift-B). It worked for me.

It seems that some kind of handle from the winform application (which works with the background) still had a file handle for some of the other libraries used.

Answer 17

I recently encountered this problem when trying to build a solution that I am working on (and not just the winforms project).
In addition to the build failure, I noticed that cleanup projects would fail silently (checking the bin folder showed that the files were not actually deleted), and closing Visual Studio did not finish the devenv process - rather, it caused a crash. After that, the Windows recovery process will restart Visual Studio.

After some trial and error, I found that the problems only occurred to me when I opened the solution from the Recent menu when starting VS.
Opening the solution from File >> Open >> Project/Solution showed that it works as usual.

I don’t know why at the moment - I will continue to study this, but for now, at least I can work!

Answer 18

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

Answer 19

In my case, some vstest processes were launched (with different names, but all containing the vstest string). I had to complete them in taskmgr.

Answer 20

After weeks of stretching my hair, I finally found what works for me, and decided that I would send it for some other poor soul, there it could help. I don't know why this works, but for me, but it does:

I changed the line of code that explicitly closes my application from Application.Exit to System.Windows.Forms.Application.Exit and now it works. Perhaps this will work for you too. Greetings.

Answer 21

Same error resolved by updating Google Nuget Support Packs

Answer 22

When I finished the .Net Core Host process, everything was fine. I did not need to close Visual Studio or change anything.

Answer 23

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

Before restarting docker, I tried all the answers mentioned, did not find a working msbuild.exe process, also tried restarting VS to no avail, only restarting docker worked.

Answer 24

Another solution: when the files are locked, a blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)" with an identifier in brackets. To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".

Answer 25

I recently encountered a problem when deploying to Service Fabric. The error implies that the “file” is being used, however I found that the port is using a different IDE. By stopping a running service that was already hosted in the port, I was able to prevent this exception from occurring.

Answer 26

I had the same problem and could not fix it using any of the methods mentioned in previous answers. I solved the problem by killing all instances of "SSIS Debug Hist (32 bit)" in the task manager and now working as usual.

Answer 27

The same problem arose, so I opened the task manager (since the error said that it was used by the process), my exe file was launched. I finished the task, after that she returned to normal life