Запрошена операція не може бути виконана у файлі з відкритим розділом, призначеним для користувача

Кожного разу, коли я намагався скопіювати 4 файли у свою папку біна, після зупинки основної служби я отримую помилку з одним файлом (TexteDll). Помилка:

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

Це може бути пов’язано з деяким блокуванням системи. Або, можливо, інший процес використовує цю DLL. Коли я google, я виявив, що перезавантаження системи може вирішити це.

Чи може хтось запропонувати причину чи рішення для цього? Я перевірив властивості TexteDll (загальна, версія, безпека тощо). Все здається нормальним.

У моєму випадку саме Провідник блокував DLL, який був зібраний у папку Налагодження ... Дивно, чи не так?

Я дізнався, використовуючи інструмент під назвою Unlocker.

Доводилося видаляти програму Unlocker, навіть коли вона казала, що блокування файлу не було, і я не міг видалити папку, поки не видалив цей єдиний файл ...

Після цього він склав.

Редагувати:

Я дізнався, чому в моєму випадку це відбувається. У мене було відкрито DLL у текстовому редакторі всередині Visual Studio ...

• Іноді, коли ви двічі клацніть на попередженні про невідповідність посилань на версію збірки між двома або більше проектами, ви забуваєте закрити вікно перегляду збірки, і воно залишається там серед інших вкладок ... тож ви закінчуєте, що збірка блокується самим VS і знадобилося мені досить багато часу, щоб зрозуміти це :)

  Будьте обережні з потужністю, яку забезпечує VS;)

• Ще один фіктивний сценарій. Іноді просто видаляючи всю папку obj або просто попереджений файл, оскільки заблокована допоможе у цій шаленій помилці.

закрити всі документи на VS та спробувати відновити його знову. Якщо це не працює, перезапустіть VS. Ця проблема пов'язана з блокуванням файлів DLL.

Закрийте візуальну студію, видаліть бін, папку випуску налагодження та знову запустіть проект візуальної студії. що вирішило мою проблему

У мене була така ж проблема, і в моєму випадку виявилося, що існуючий вихідний файл був заблокований іншим додатком.

Ви можете перевірити, яка програма блокує ваш вихідний файл за допомогою OpenedFilesView: http://www.nirsoft.net/utils/opened_files_view.html

Я розробник і не люблю додатків, які вводяться в Реєстр, як Unlocker. Я використовував SysInternals Process Explorer, який заблокував dll Find > Find Handle or Dll [Ctrl-F]і вбив процес.

Інші вже встановили, що ця помилка пов’язана з іншою програмою, що має блокування у файлі. Просто хотів зазначити, що git diffблокує файли також, поки ви не вийдете з нього. Саме це спричинило це в моєму випадку.

У мене було те саме питання. Як я це вирішив:

1. Відкрийте "Диспетчер завдань"
2. Закінчити завдання "Explorer.exe"
3. Клацніть «Файл» -> Створити нове завдання - Введіть «explorer.exe» -> ОК
4. Очистіть мій проект, і він працює

У вас працює якесь антивірусне програмне забезпечення. Можливо, що програмне забезпечення AV (або якесь інше програмне забезпечення) читало файл за допомогою API-файлів відображення файлів, що спричинило проблему.

У моєму випадку мені довелося вбити висячий MSBuild.exeпроцес, який блокував файл (він був там навіть після закриття Visual Studio).

Видалення папки obj та відновлення роботи працювали для мене

У мене була така ж проблема. Перезапуск для мене не працював. Був процес, який називається VBSCompiler, що працює в диспетчері завдань. Мені довелося закінчити процес, щоб виправити цю помилку.

Жодне з розміщених тут рішень не працювало для мене. Файл був заблокований devenv.exe (Visual Studio), але якби я його перезапустив, він повторно заблокував його.

Як не дивно, Windows не дозволила мені видалити файли (до кошика), але Shift + Delete (постійне видалення) спрацювало.

Закрийте Visual Studio і запустіть його як адміністратор. Виправлена ​​моя проблема.

Для мене рішенням було закрити всі екземпляри VS і вбити будь-які висячі процеси devenv.exe.

Для мене рішення було перезавантажити комп'ютер.

У 2016 році Ендрю Катберт зазначив, що git diff також блокує файли, поки ви не вийдете з нього.

Так не буде з Git 2.23 (Q3 2019)

Див. Комітет 3aef54e (11 липня 2019 р.) Йоганнеса Шинделіна ( dscho) .
^{(Об'єднав Хуніо С Хамано - gitster- в комісії d9beb46 , 25 липня 2019 р.)}

diff: munmap()вміст файлу перед запуском зовнішньої розл

Запускаючи зовнішній відмінність від, скажімо, a diff tool, можна з упевненістю припустити, що ми хочемо написати ці файли.
У Windows це означає, що не може бути жодного іншого процесу, який би тримав відкриту ручку до згаданих файлів, або навіть просто відображений регіон.

Тож давайте переконаємось, що git diffсам по собі не тримає жодної відкритої ручки щодо відповідних файлів.

Насправді ми просто випустимо пару файлів одразу, оскільки зовнішній diff використовує файли, які ми тільки що написали, тому нам більше не потрібно зберігати вміст файлу в пам'яті.

Це виправляє git-for-windows # 1315

Я бачив ці помилки під час створення додатків Dot Net із програмою Ant.

У моєму випадку це було наше корпоративне програмне забезпечення для резервного копіювання, агент Symantec DLO. Зупинення та виключення каталогу в моєму антивірусному програмному забезпеченні та закриття Visual Studio, здається, працює.

у моєму випадку видалив папку obj в корені проекту і відновити проект вирішив мою проблему !!!

Я зіткнувся з цією помилкою, і виявилося, що проблема FxCop проти мого проекту. Я закрив FxCop і потім міг знову компілювати.

Якщо це веб-додаток, видалення файлів у папці тимчасових файлів ASP.NET може бути рішенням.

Якщо ви використовуєте профілі на зразок AQ Time, вони також можуть блокувати файл. Рішенням у цьому випадку буде перезапустити профайлер або просто вивантажити / завантажити відповідну збірку з профілера. За час AQ я помітив, що він випускає файл через деякий час, але я не можу за все життя сказати, що це за час очікування. Здається, випадково

Я також отримав таку ж помилку сьогодні. Я вирішив це питання шляхом відновлення проекту.

У мене виникла помилка, викликана тим, що питання "більше" проти відповідного файлу залишається в іншій консолі. На жаль

Жодне із зазначеного не вирішило цього питання.

Хтось мав один проект у моєму наборі рішення використовувати x64 CPU у конфігурації збірки. Змінення його на будь-який процесор призвело до збірки для використання нової папки. Я досі не знаю, який процес мав блокування у цьому файлі.

У мене був цей самий випуск. Я видалив dll з папки temp, видалив доступ лише для читання та перезапустив машину і змусив її працювати.

У моєму випадку я просто закриваю весь екземпляр і копіюю свою папку кореневих додатків і вставляю її в інше місце, а потім відкриваю рішення в VS.

Мою проблему також було вирішено просіюванням через Провідник процесів. Однак процес, який мені довелося вбити, був MySQL Notifier.exe, який все ще працював після закриття всіх програм VS та SQL.