peter
peter

Reputation: 8682

The requested operation cannot be performed on a file with a user-mapped section open

Whenever I tried to copy 4 files into my bin folder, after stopping the main service, I am getting an error with one file (TexteDll). The error is:

Cannot copy TexteDll: The requested operation cannot be performed on a file 
with a user-mapped section open

It may be due to some system locking. Or perhaps another process is using this DLL. When I googled, I found that rebooting the system may resolve this.

Can anybody suggest a cause or solution for this? I inspected the properties of TexteDll (general, version, security, etc). Everything appears normal.

Upvotes: 287

Views: 335353

Answers (30)

Emre Bener
Emre Bener

Reputation: 1462

This issue used to randomly come up back in .NET 5-6 and I would fix it by running this command in CMD: taskkill /f /im MSBuild.exe (otherwise I would have to restart the PC). I have never seen it happen in .NET 7 and above.

Upvotes: 0

TJRawlins
TJRawlins

Reputation: 1

This happened to me, but after closing all opened tabs and files, exiting VS, then opening it back up, running a new build, I still got the error. I had to clean solution, then build for the error to go away.

Build >> Clean Solution

Upvotes: 0

Rishu Ranjan
Rishu Ranjan

Reputation: 574

I tried the above solutions but they did not work for me. Few steps that I followed:

  • Closing all VS instances and opening again.
  • Killing build.exe and explorer.exe processes.
  • Deleting bin folder in projects.

What worked for me is - Restarting My Machine.

Another solution:

  • go to the solution folder.
  • check the properties, and remove read-only property if there.
  • click and apply to all the subfolders.
  • open VS again, clean + build solutions.

Upvotes: 2

user17983115
user17983115

Reputation: 55

In my case there was still an "invisible" instance of VS2022 (devenv.exe) running. It was listed in Task Manager with Status=Suspended but no corresponding window was visible on the taskbar or anywhere else. After killing that process the problem was solved.

Upvotes: 0

Abdullah Khilji
Abdullah Khilji

Reputation: 493

Somehow a simple restart solved the issue for me.

Upvotes: 2

bobt
bobt

Reputation: 11

Happens to me on Window 10, Visual Studio 2022, Visual Basic project. Process Explorer "Find Handle/DLL" shows me 4 lines of devenv.exe locking the file.

Besides killing devenv.exe, I can also fix the issue by simply deleting the folder that contains the locked file (in this case it's bin\Debug). It's strange because I'm not allowed to deleted the locked file, but I can delete the whole folder.

Upvotes: 0

VonC
VonC

Reputation: 1328152

It has been pointed out in 2016 by Andrew Cuthbert that git diff locks files as well until you quit out of it.

That is still the case for git diff, but it won't be the case with Git 2.23 (Q3 2019), for external diff tools (as reported by Burkart in the comments).

See commit 3aef54e (11 Jul 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit d9beb46, 25 Jul 2019)

diff: munmap() file contents before running external diff

When running an external diff from, say, a diff tool, it is safe to assume that we want to write the files in question.
On Windows, that means that there cannot be any other process holding an open handle to said files, or even just a mapped region.

So let's make sure that git diff itself is not holding any open handle to the files in question.

In fact, we will just release the file pair right away, as the external diff uses the files we just wrote, so we do not need to hold the file contents in memory anymore.

This fixes git-for-windows#1315


Running "git diff"(man) while allowing external diff in a state with unmerged paths used to segfault, which has been corrected with Git 2.30 (Q1 2021).

See commit d668518, commit 2469593 (06 Nov 2020) by Jinoh Kang (iamahuman).
(Merged by Junio C Hamano -- gitster -- in commit d5e3532, 21 Nov 2020)

diff: allow passing NULL to diff_free_filespec_data()

Signed-off-by: Jinoh Kang
Signed-off-by: Junio C Hamano

Commit 3aef54e8b8 ("diff: munmap() file contents before running external diff", Git v2.22.1) introduced calls to diff_free_filespec_data in run_external_diff, which may pass NULL pointers.

Fix this and prevent any such bugs in the future by making diff_free_filespec_data(NULL) a no-op.

Fixes: 3aef54e8b8 ("diff: munmap() file contents before running external diff")

Upvotes: 8

Ahmed Elmasry
Ahmed Elmasry

Reputation: 3

In my case, I was trying to publish API to my local IIS, I fixed it by simply deleting the causing file in the IIS target folder and publish the API again, it seemed like it corrupted or something.

Upvotes: 0

DrMaxB
DrMaxB

Reputation: 650

In my case, the issue was with visual micro on Visual Studio 2019. It was complaining about the \_vm\compile.vmps.xml file. Unable to delete/modify it perhaps. I fixed this issue by deleting the _vm folder in the root directory of the project and rebuilding the solution.

Upvotes: 0

dgo
dgo

Reputation: 3937

This is a different one. Seems like it can happen due to a file handle being in use. This is why this answer works, I believe. For me, I had type more project.csproj from the command line, and forgotten I had left it open. So the handle was locked for reading.
Sysinternals has a neat command line tool called handle if you are partial to the command line. You can type handle <partial name of whatever file or folder you want> and it will tell you what program (if any) is using it.

Handle by Sysinternals

Upvotes: 1

Jonathan Applebaum
Jonathan Applebaum

Reputation: 5986

Happened to me after I have changed the project target CPU from 'Any CPU' to 'X64' and then back to 'Any CPU'.
Solved it by deleting the Obj folder (for beginners: don`t worry about deleting the obj folder, it will be recreated again in the next compile).

Upvotes: 1

C.M.
C.M.

Reputation: 1561

None of the above solved this issue.

Someone had one project in my solution set to use x64 CPU in the build configuration. Changing it to Any CPU caused the build to use a new folder. I still don't know what process had (has) a lock on that file.

Upvotes: 0

user10991945
user10991945

Reputation: 271

I had the same issue. How I resolved it was:

  1. Open "Task Manager"
  2. End task "Explorer.exe"
  3. Click "File" --> Create new task -- Type in "explorer.exe" --> OK
  4. Clean my project and it works

Upvotes: 27

JN88
JN88

Reputation: 21

My issue was also solved by sifting through the Process Explorer. However, the process I had to kill was the MySQL Notifier.exe that was still running after closing all VS and SQL applications.

Upvotes: 0

Ali Rasouli
Ali Rasouli

Reputation: 1911

in my case deleted the obj folder in project root and rebuild project solved my problem!!!

Upvotes: 1

komodosp
komodosp

Reputation: 3658

Deleting the obj folder and rebuilding worked for me

Upvotes: 3

makhdumi
makhdumi

Reputation: 1328

None of the solutions posted here worked for me. It was devenv.exe (Visual Studio) locking the file, but if I restarted it, it would re-lock it.

Bizarrely, Windows wouldn't let me Delete the files (to Recycle Bin), but Shift+Delete (permanent delete) worked.

Upvotes: 4

Nirjhar Vermani
Nirjhar Vermani

Reputation: 1245

I had the same problem. Restart did not work for me. There was a process called VBSCompiler was running in task manager. I had to end the process to fix this error.

Upvotes: 3

user2338408
user2338408

Reputation: 182

The solution for me was to close out of all instances of VS and to kill any hanging devenv.exe processes.

Upvotes: 2

Arman
Arman

Reputation: 5336

  • Sometimes when you double click on a warning about the referenced assembly version mismatch between two or more projects you forget to close the assembly view window and it stays there among other tabs... so you end up with the assembly being locked by VS itself and it took me quite a lot of time to figure that out :)

    Be careful with the power VS provides ;)

  • Another dummy scenario. Sometimes simply deleting the whole obj folder or just the file warned as the locked one helps out with this crappy error.

Upvotes: 80

memory of a dream
memory of a dream

Reputation: 1267

If you're using profilers like AQ Time, these may also be locking the file. The solution in this case would be to restart the profiler or simply unload/load the assembly in question from the profiler. For AQ Time I noticed that it's releasing the file after some time, but I can't for the life of me tell what that timeout is. Seems to be random

Upvotes: 0

drew.cuthbert
drew.cuthbert

Reputation: 1015

Others have already established that this error is due to another application having a lock on the file. Just wanted to point out that git diff locks files as well until you quit out of it. That's what caused this in my case.

Upvotes: 10

suphero
suphero

Reputation: 517

If it is a web application deleting files in Temporary ASP.NET Files folder could be a solution.

Upvotes: 0

guneysus
guneysus

Reputation: 6502

I am a developer and do not like apps injected to Registery like Unlocker. I used SysInternals Process Explorer which process locked my dll Find > Find Handle or Dll [Ctrl-F] and killed the process.

Upvotes: 17

t3chb0t
t3chb0t

Reputation: 18724

In my case I had to kill a hanging MSBuild.exe process that was locking the file (it was there even after I closed Visual Studio).

Upvotes: 8

Daniel Lobo
Daniel Lobo

Reputation: 2211

In my case it was the Explorer that was locking the DLL that was been compiled in the Debug folder... Strange, isn't it?

I found out using a tool called Unlocker.

Had to delete with Unlocker, even when it was saying that there was no lock over the file, and I couldn't delete the folder until I didn't delete that single file...

After that it compiled.

EDIT:

I found out why in my case this was happening. I had the DLL opened in a text editor inside Visual Studio...

Upvotes: 199

Tim
Tim

Reputation: 1874

I encountered this error and it turned out the issue was FxCop was running against my project. I closed FxCop and then I could compile again.

Upvotes: 0

Robert Bratton
Robert Bratton

Reputation: 435

I was seeing these errors when building Dot Net applications with Ant.

In my case it was our corporate backup software, the Symantec DLO Agent. Stopping it and excluding the directory in my antivirus software and closing Visual Studio seems to work.

Upvotes: 1

Sanjay Ghinaiya
Sanjay Ghinaiya

Reputation: 156

Close the Visual Studio and Run it as administrator. It's fixed my problem.

Upvotes: 3

user2038221
user2038221

Reputation: 181

Close visual studio, delete bin , debug release folder, and start visual studio project again. that fixed my problem

Upvotes: 18

Related Questions