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.

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...

• 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.

close all documents on VS and try to rebuild again. If it doesn't work restart VS. This problem is related to lock of DLL files.

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

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

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.

I had same problem and in my case it appeared that existing output file was locked by other application.

You can check which application is locking your output file with OpenedFilesView: http://www.nirsoft.net/utils/opened_files_view.html

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.

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

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")

Are you running any Anti-virus software. It's possible that the AV software (or some other piece of software) was reading the file using the file mapping APIs which caused the problem.

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.

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.

Deleting the obj folder and rebuilding worked for me

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

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

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.

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

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

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

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.

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

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

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.

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.

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.

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.

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.