Сбой сборки Visual Studio: невозможно скопировать exe-файл из obj \ debug в bin \ debug

Question

Обновление: Пример проекта, воспроизводящего эту ошибку, можно найти здесь, в Microsoft Connect . Я также проверил и подтвердил, что решение, приведенное в принятый ответ ниже , работает с этим примером проекта. Если это решение не работает для вас, возможно, у вас другая проблема (которая относится к отдельному вопросу).

---

Этот вопрос задавался ранее, как здесь, в Переполнении стека, так и в других местах, но ни одно из предложенных мною предложений не помогло мне, поэтому я просто должен попытаться задать новый вопрос.

Сценарий: у меня есть простое приложение Windows Forms (C #, .NET 4.0, Visual Studio 2010). Он имеет несколько базовых форм, от которых наследуется большинство других форм, он использует Entity Framework (и классы POCO) для доступа к базе данных. Ничего особенного, нет многопоточности или чего-то еще.

Проблема: некоторое время все было хорошо. Затем совершенно неожиданно Visual Studio не удалось собрать, когда я собирался запустить приложение. Я получил предупреждение "Невозможно удалить файл '... bin \ Debug \ [ProjectName] .exe'. Доступ к пути '... bin \ Debug \ [ProjectName] .exe' запрещен." * " 1019 * и ошибка "Невозможно скопировать файл 'obj \ x86 \ Debug \ [ProjectName] .exe' в 'bin \ Debug \ [ProjectName] .exe'. Процесс не может получить доступ к файлу 'bin \ Debug \ [ProjectName] .exe ', поскольку он используется другим процессом. " (Я получаю как предупреждение, так и ошибку при запуске Rebuild, но только ошибку при запуске Build - не думаю, что это актуально?)

Я прекрасно понимаю, что говорится в предупреждении и сообщении об ошибке: Visual Studio, очевидно, пытается перезаписать exe-файл, хотя в то же время он по какой-то причине заблокирован. Тем не менее, это не помогает мне найти решение проблемы ... Единственное, что я нашел, - это закрыть Visual Studio и запустить его снова. Затем работает сборка и запуск, пока я не внесу изменения в некоторые формы, затем у меня снова возникнет та же проблема, и мне придется перезагрузить компьютер ... Довольно неприятно!

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

• Создание нового чистого решения и просто скопировать файлы из старого решения.

• Добавление следующего к следующему событию перед сборкой проекта:

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

• Добавление следующего к свойствам проекта (файл .csproj):

  <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
  

Однако, ни один из них не работал для меня, так что вы, вероятно, можете понять, почему я начинаю немного расстраиваться. Я не знаю, где еще искать, поэтому я надеюсь, что кому-то есть, что мне дать! Это ошибка в VS, и если да, то есть ли патч? Или я сделал что-то не так, у меня есть круговая ссылка или что-то подобное, и если да, то как я могу узнать?

Любые предложения высоко ценятся:)

Обновление: Как уже упоминалось в комментарии ниже, я также проверил с помощью Process Explorer, что он на самом деле является Visual Studio, которая блокирует файл.

Answer 1

Это будет звучать глупо, но я попробовал все эти решения, используя VS2010 на Windows 7. Ни одно из них не работало, кроме переименования и сборки, что было ОЧЕНЬ утомительно, если не сказать больше. В конце концов я разыскал виновника, и мне трудно в это поверить. Но я использовал следующий код в AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Это довольно распространенное явление, но по какой-то причине изменение версии на 2.0.0.0 снова заработало. Я не знаю, является ли это специфической для Windows 7 (я использую ее только 3-4 недели), или это случайно, или что-то еще, но это исправило это для меня. Я предполагаю, что VS хранит дескриптор каждого сгенерированного файла, так что он знает, как увеличивать вещи? Я действительно не уверен и никогда не видел, чтобы это случилось раньше. Но если кто-то еще там вырывает свои волосы, попробуйте.

Answer 2

Я нашел одно простое решение, просто отключите службы индексирования Windows для папки и подпапок проекта

Answer 3

Поскольку я не получил больше отзывов по этому вопросу, я решил поделиться своим решением:

Как предложил Барри в комментарии к исходному сообщению, вручную переименовав '... bin \ Debug [ProjectName] .exe' во что-то другое (например, '[ProjectName] 1 .exe ') является одним из обходных путей (однако мне самому не разрешено удалять файл, и я должен сказать, что нахожу это немного странным, поскольку можно было бы полагать, что та же самая блокировка, предотвращающая удаление, также предотвратит переименование .. .). Это не очень хорошее решение, но оно достаточно быстрое (по крайней мере, после того, как вы сделали это пару раз, оно почти становится рутиной) и, по крайней мере, намного быстрее, чем перезапуск Visual Studio, что я и делал в начале.

В случае, если кто-то задается вопросом, я мог бы также добавить, что я вижу эту проблему только случайно. Обычно это происходит после того, как я сделал некоторые изменения в режиме дизайна формы (но не всегда). Обычно этого не происходит, если я изменяю только код бизнес-логики или невизуальный код (но иногда это происходит ...) Разочарование действительно, но по крайней мере у меня есть взлом, который работает для меня - давайте просто надеяться, что мой следующий проект также не столкнется с этой проблемой ...

@ Барри: если вы хотите получить кредит за ваш комментарий, пожалуйста, не стесняйтесь опубликовать его как ответ, и я обязательно приму его:)

Answer 4

У меня та же проблема (MSB3021) с проектом WPF в VS2008 (в Windows 7 x32). Проблема появляется, если я пытаюсь перезапустить приложение слишком быстро после предыдущего запуска. Через несколько минут exe-файл разблокируется сам по себе, и я снова могу запустить приложение. Но такая долгая пауза злит меня. Единственное, что действительно помогло мне, это запустить VS от имени администратора.

Answer 5

Когда я сталкиваюсь с этой проблемой, это связано с тем фактом, что проект, который я пытаюсь создать, устанавливается как проект запуска в решении, делающем заблокированный EXE-файл в папке obj (он также появляется в вашей задаче). Менеджер,) щелкните правой кнопкой мыши другой проект в вашем решении и выберите установить запуск проекта. Это снимет блокировку, удалит ее из диспетчера задач и позволит вам собрать.

Answer 6

Я попробовал все остальные предложения в ответах здесь, ни один из которых не сработал. В конце концов я использовал Process Monitor, чтобы обнаружить, что мой .exe, который не удалось собрать VS2010, был заблокирован системным процессом (PID = 4). Поиск SO для ситуаций, связанных с этим, дал этот ответ.

Подведем итог: если у вас отключена служба Application Experience (как я), то включите ее снова и запустите. Два года обострения закончились.

Answer 7

У меня также была проблема, очень похожая на эту, и я обнаружил, что причина в моем случае заключалась в том, что я сделал папку bin \ debug доступной как общую папку под VMware и либо VMware, Explorer под гостевой виртуальной машиной, либо, возможно, дажеантивирусная программа под гостем (хотя я не думаю, что она была установлена) держала дескриптор файла (ов).

Answer 8

Отключить «Включить процесс размещения Visual Studio» * * 1004

Answer 9

ЕСЛИ ВАША ПРОБЛЕМА НЕ РЕШЕНА, то:

Ошибка Visual Studio:

"Процесс не может получить доступ к файлу bin \ Debug ** app.exe ** ', так как он используется другим процессом."

Итак, зайдите в диспетчер задач Windows (Ctrl + Shift + Esc), найдите название вашего приложения и принудительно закрываем его с помощью Endprocces.

Answer 10

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