Ошибка: не удается получить доступ к файловому ящику /Debug/..., потому что он используется другим процессом

Ответ 1

Ух, это старая проблема, которая все еще появляется в Visual Studio время от времени. Это укусило меня пару раз, и я потерял часы, возобновляя и сражаясь с VS. Я уверен, что это обсуждалось здесь на SO более одного раза. Об этом также говорили на форумах MSDN. Реального решения нет, но есть несколько способов обхода. Начните исследование здесь.

Что происходит, так это то, что VS приобретает блокировку в файле, а затем не выпускает ее. Как ни странно, эта блокировка не позволяет VS самому удалять файл, чтобы он мог воссоздать его при перестройке приложения. Единственное очевидное решение - закрыть и перезапустить VS, чтобы он освободил блокировку файла.

Моим первоначальным обходом было открытие папки bin/Debug и переименование исполняемого файла. Вы не можете удалить его, если он заблокирован, но вы можете переименовать его. Таким образом, вы можете просто добавить номер в конец или что-то еще, что позволит вам продолжать работать без закрытия всех ваших окон и ждать перезагрузки VS. Некоторые люди даже автоматизировали это с помощью события предварительной сборки, чтобы добавить случайную строку в конец старого имени выходного файла. Да, это гигантский взлом, но эта проблема становится настолько расстраивающей и изнурительной, что вы все сделаете.

Позже я узнал после нескольких экспериментов, что проблема возникает только при создании проекта при открытии одного из дизайнеров. Таким образом, решение, которое долгое время работало для меня и не позволяло мне когда-либо сталкиваться с одной из этих глупых ошибок, заключается в том, что я всегда закрываю все окна дизайнеров перед созданием проекта WinForms. Да, это тоже несколько неудобно, но он уверен, что брюки не должны перезапускать VS два раза в час или более.

Я предполагаю, что это относится и к WPF, хотя я не использую его и лично не сталкивался с этой проблемой.

Я еще не пробовал воспроизвести его на VS 2012 RC. Я не знаю, было ли там исправлено или нет. Но мой опыт до сих пор заключался в том, что ему все еще удается появиться даже после того, как Microsoft заявила, что исправила его. Он все еще присутствует в VS 2010 SP1. Я не говорю, что их программисты - идиоты, которые не знают, что они делают, конечно. Я полагаю, что существует множество причин для ошибки и/или что очень трудно воспроизвести надежно в лаборатории. По той же причине я лично не подавал никаких сообщений об ошибках (хотя у меня + 1 были другие народы), потому что я не могу уверенно воспроизвести его, скорее, как отвратительный снеговик.

_{< end rant, который не ориентирован ни на кого конкретно >}

Ответ 2

У меня эта ошибка появилась на мне раньше, даже в Visual Studio 2008. Она вернулась и стала более распространенной в Visual Studio 2012.

Вот что я делаю.

Вставьте это в неприятное событие предварительной сборки проекта:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Ответ 3

Компьютер (щелкните правой кнопкой мыши) → Управление → Сервис и приложение → служба → Включить опыт приложения

Работал для меня!

Ответ 4

У меня была такая же проблема в Visual Studio 2013. Я не уверен, что вызвало это для моего проекта, но я смог исправить это, очистив решение и перестроив его.

• Сборкa > Чистое решение
• Создать > Восстановить решение

Ответ 5

По крайней мере, в моем случае я заметил, что в visual studio 2012 было создано по крайней мере два призрачных процесса msbuild.exe, которые не погибли после сборки. Очевидно, эти зомби вызывают появление файловых замков.

Killing msbuild.exe - одноразовое решение, оно должно выполняться на основе сборки.

Но потом я выясню, что я могу отключить параллельную сборку раз и навсегда - перешел в "Инструменты" > "Параметры" > "Проекты и решения" > "Сборка и запуск" ) "Максимальное количество параллельных проектов" - по умолчанию он имеет значение 8, я переключился на 1. Работает как шарм.

Конечно, сборки сейчас немного медленнее, но лучше безопасны, чем жаль. По крайней мере для этого небольшого проекта мне не нужно было больше одного потока сборки.

Ответ 6

См. мой ответ здесь, если у вас возникла эта проблема во время выполнения модульных тестов. Ответ скопирован ниже:

Основываясь на ответе Себастьяна, я добавил шаг до сборки для моего теста проект для автоматического уничтожения любых исполняемых файлов vstest.*Бег. Для меня работала следующая команда предварительной сборки:

taskkill /f /im vstest.*
exit 0

Команда exit 0 находится в конце, чтобы предотвратить сбой сборки, когда не выполняются исполняемые файлы vstest.*.

Ответ 7

Недавно у меня возникла проблема с Visual Studio 2012 с тем же описанием ошибки: "Процесс не может получить доступ к файлу, потому что он используется другим процессом..."

Чтобы исправить это, прежде всего вам нужно понять приложение, которое все еще использует его. Я отключил все процессы, такие как "MSBuild" и "MSBuild host". Но этого недостаточно. Если вы установили "Контракт кода" и включили его, иногда для проверки и зависания этой операции иногда требуются ваши DLL.

Итак, вам нужно остановить все процессы "CCCheck.exe" и все.

Наконец, чтобы понять, что этот процесс использует вашу DLL, вы всегда можете попробовать просто удалить папку "obj" в вашем Диспетчере файлов, и эта операция завершится с ошибкой, вы можете увидеть "Окно сообщений" с описанием операции висячего. Кроме того, в качестве варианта вы можете попробовать использовать приложение "Sys Internals Suite".

Ответ 8

Работал для меня. Диспетчер задач → Название проекта → Завершить задачу. (у меня было три процесса с моим именем проекта);

VS 2013; Выиграть 8;

Ответ 9

Убедитесь, что предыдущий запуск приложения (например, запуск без опции отладки) фактически остановлен. Я работал над WPF-приложением, начал без отладки и минимизировал его, когда получал ошибку. После закрытия приложения поведение VS вернулось к нормальному.

Ответ 10

Я испытывал эту проблему в Visual Studio 2017. Это началось около двух или трех недель назад и сильно поглотило мою производительность. Чистота и Ребулид не работали; даже перезагрузка моей машины не выполняет эту работу.

Один из способов решения этой проблемы - очистить сборку сбоев и построить (в отличие от перестроения) проект, который вы хотите запустить сразу после этого. Это работает примерно в 30% случаев.

Однако, вероятно, самым надежным решением, которое я нашел, является открытие командной строки Developer Command и непосредственное использование msbuild. Я делаю это в течение последних трех дней, и до сих пор проблема не была однажды.

Ответ 11

В моем случае я включил "Показать все файлы". Visual Studio 2017

Ответ 12

Это чистая спекуляция, а не ответ.

Однако у меня была эта проблема некоторое время.

Я пришел через некоторое время, чтобы заподозрить взаимодействие между VS и моими предосторожностями AV.

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

C:\Users [имя_пользователя]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

папка не была включена в защиту в режиме реального времени.

Похоже, что сборка фактически записывает DLL здесь сначала, а затем копирует ее в окончательное место сборки.

Ответ 13

Это может быть слишком поздно. Но я столкнулся с подобной проблемой, и в моем случае проект был самонаблюден. Следовательно, удаление его из ссылок работало как шарм!!!

Ответ 14

Я нашел самый быстрый способ без закрытия форм или перезапуска VisualStudio - перейти на страницу компиляции проекта и нажать кнопку "Дополнительные параметры компиляции...". Затем внесите какие-либо изменения в один из параметров (скажем, сменив "Генерировать информацию отладки" с "Полно" на pdb-only), затем нажмите "ОК". Он работает каждый раз и должен будет сделать, пока MS не исправляет эту ошибку (у меня никогда не было этой проблемы, пока я не переключился с VS2012 на VS2013)

Еще одно замечание: если вы не можете очистить проект или решение, оно не будет создано. Файлы, безусловно, заблокированы VS (не проблема с антивирусом, по крайней мере, не в моем случае)

Ответ 15

Я пробовал все эти предложения, а также другие предложения, найденные в другом месте, и единственное, что сработало для меня, - это перезагрузка моего компьютера. Затем я сделал чистое решение, а затем восстановил его. Я использую Visual Studio 2013 для справки.

Ответ 16

Я столкнулся с этой же проблемой, и я обнаружил, что в фоновом режиме есть фактически запущенное приложение формы Windows. Это происходит, когда ваше приложение имеет две формы, и вы закрываете вторую форму, которая не является вашей основной формой , поэтому приложение не будет полностью завершено.

Я обычно запускаю свое приложение

• через exe или
• выполняется без отладки

Решение закрывает другой экземпляр приложения формы Windows. Это один способ всегда закрывать экземпляр вашего приложения.

Ответ 17

Команда предварительной сборки

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Помогал

Ответ 18

[Исправлено] Ошибка: не удается получить доступ к файловому ящику /Debug/... потому что он используется другим процессом:

Я приближаюсь к тому, что вы получаете эту ошибку, когда пытаетесь запустить два окна один за другим, например, сначала загрузите форму, после чего она автоматически исчезнет, ​​а вторая форма загрузится на экран.

В принципе, вам нужно закрыть свою первую форму, которая работает в фоновом режиме и основная причина этой ошибки.

Чтобы закрыть первую форму, вы должны добавить эти две строки кода во обработчик события второй формы.

    Form1 form = new Form1();
    form.Close();

Это позволит полностью решить проблему.

Ответ 19

Одним простым решением является переход в папку bin\Debug, удаление всех файлов в этой папке, а затем восстановление. Если это не сработает, закройте Visual Studio, затем перейдите в папку bin\Debug с помощью проводника файлов, слева на конусе, нажмите "Файл" > "Открыть командную строку" > "Открыть командную строку" в качестве "Администратор" > Введите эту команду "DEL/F/Q/A *" > затем перестроить

Ответ 20

я нашел, что Cody Gray ответил частично полезным, поскольку он действительно направил меня к реальному источнику моей проблемы, который некоторые из вас также могут испытывать: выполнение визуального студийного теста остается открытым по умолчанию и поддерживает блокировку файлов.

Чтобы остановить это бесполезное поведение, следуйте инструкциям https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel

Снимите флажок в меню "Тест" → "Настройки теста" → "Продолжить запуск тестового исполнения"

Ответ 21

Моя проблема заключалась в том, что dotnet повесили трубку, и когда VS попытается создать новую dll или получить доступ к старой, процесс dotnet защелкнется на dll и перестанет визуализировать студию от клонирования DLL. Решение состоит в том, чтобы положить конец всем задачам dotnet в диспетчере задач (он фактически удалит только мертвый, если вы пытаетесь его закончить, и он не будет закрыт, это означает, что он работает).

Ответ 22

Другой kludge, тьфу, но это легко и работает для меня в VS 2013 года. Нажмите на проект. На панели свойств должна быть запись с именем Project File со значением

(название вашего проекта).vbproj

Измените название проекта - например, добавьте -01 в конец. Исходный .zip файл, который был заблокирован, все еще существует, но больше не ссылается... поэтому ваша работа может продолжаться. В следующий раз, когда компьютер перезагрузится, эта блокировка исчезнет, ​​и вы можете удалить ошибочный файл.