[windows] 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.

I fixed the issue as below:

1. Restart machine
2. Delete bin and obj folders from respective project path.
3. Open visual studio
4. Clean and build the solution.

There you go issue resolved:)

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

That won't be the case with Git 2.23 (Q3 2019).

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

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

Deleting the obj folder and rebuilding worked for me

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

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.

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

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

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

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.

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

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

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

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.

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.

I also got same error today. I have resolved this issue by re-building the project.

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

I had this same issue . I removed dll from temp folder, remove read only access and restarted machine and got it working.

I had this error caused by a 'more' vs file in question left running in another console. Oops.

In my case, I just close all instance and copy my root application folder and paste it in different location then open solution in VS it works....

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

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.

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.

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.

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

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

The solution for me was to restart the computer.

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.