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

后端 未结 30 1841
青春惊慌失措
青春惊慌失措 2020-12-13 03:08

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 l

相关标签:
30条回答
  • 2020-12-13 03:57

    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.

    0 讨论(0)
  • 2020-12-13 03:58

    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.

    0 讨论(0)
  • 2020-12-13 04:00

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

    0 讨论(0)
  • 2020-12-13 04:00

    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.

    0 讨论(0)
  • 2020-12-13 04:02

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

    0 讨论(0)
  • 2020-12-13 04:05

    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.

    0 讨论(0)
提交回复
热议问题