Сбои сборки Visual Studio: не мог скопировать EXE-файл от obj\debug до bin\debug
Обновление: демонстрационный проект, воспроизводящий эту ошибку, может быть найден здесь в Microsoft Connect. Я также протестировал и проверил что решение, данное в принятом ответе ниже работ над тем демонстрационным проектом. Если это решение не работает на Вас, у Вас, вероятно, есть другой вопрос (который принадлежит отдельного вопроса).
Это - вопрос, который задают прежде, и здесь на Переполнении стека и других местах, но ни одно из предложений я нашел настолько далеко, помог мне, таким образом, я просто должен попытаться задать новый вопрос.
Сценарий: у Меня есть простое приложение Windows Forms (C#.NET 4.0, Visual Studio 2010). Это имеет несколько основных форм, которым наследовалось большинство других форм, это использует Платформу Объекта (и ПОСТЕПЕННО классы) для доступа к базе данных. Ничто не полагает, никакая многопоточность или что-либо.
Проблема: Все были в порядке некоторое время. Затем все внезапно, Visual Studio не удалось создать, когда я собирался запустить приложение. Я получил предупреждение, "Не могущее удалить файл '... bin\Debug \[ProjectName].exe'. Доступ к пути '... bin\Debug \[ProjectName].exe' запрещен". и ошибка, "Не могущая скопировать файл 'obj\x86\Debug \[ProjectName].exe' к 'bin\Debug \[ProjectName].exe'. Процесс не может получить доступ к файлу 'bin\Debug \[ProjectName].exe', потому что он используется другим процессом". (Я получаю и предупреждение и ошибку, когда выполнение Восстанавливает, но только ошибка при выполнении Сборки - не думает, что это релевантно?)
Я понимаю превосходный, что говорят предупреждающее сообщение и сообщение об ошибке: 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 файл):
true
Однако ни один из них не работал на меня, таким образом, можно, вероятно, видеть, почему я начинаю становиться немного расстроенным. Я не знаю, где еще посмотреть, таким образом, я надеюсь, что у кого-то есть что-то, чтобы дать мне! Действительно ли это - ошибка в VS, и раз так существует ли патч? Или я сделал что-то не так, у меня есть циклическая ссылка или подобный, и раз так как я мог узнать?
Любые предложения высоко ценятся :)
Обновление: Как упомянуто в комментарии ниже, я также проверил Проводник Процесса использования, что это на самом деле - Visual Studio, которая блокирует файл.
3 ответа
Это прозвучит глупо, но я попробовал все эти решения, запустив VS2010 в Windows 7. Ни одно из них не работало, кроме переименования и сборки, что было ОЧЕНЬ утомительно, если не сказать больше. В конце концов, я нашел виновного, и мне трудно в это поверить. Но я использовал следующий код в AssemblyInfo.cs ...
[assembly: AssemblyVersion("2.0.*")]
Это довольно распространено, но по какой-то причине изменение версии на 2.0.0.0 заставило все снова заработать. Я не знаю, относится ли это к Windows 7 (я использую его всего 3-4 недели), или это случайно, или что-то еще, но он исправил это для меня. Я предполагаю, что VS хранит дескриптор для каждого файла, который он сгенерировал, чтобы он знал, как увеличивать значения? Я действительно не уверен и никогда раньше не видел, чтобы это происходило. Но если кто-то еще вырывает себе волосы, попробуйте.
Поскольку я больше не получил отзывов по этой проблеме, я подумал, что просто расскажу, что в итоге стало моим решением:
Как предложил Барри в комментарии к оригиналу сообщение, вручную переименовав '... bin \ Debug [ProjectName] .exe' во что-то другое (например, '[ProjectName] 1.exe' ) - это одно решение ( Однако мне не разрешено удалять файл самостоятельно, и я должен сказать, что нахожу это немного странным, поскольку можно было бы подумать, что та же самая блокировка, предотвращающая удаление, также предотвратит переименование ...). Это не очень хорошее решение, но оно достаточно быстрое (по крайней мере, после того, как вы сделали это пару раз, это почти становится рутиной) и, по крайней мере, намного быстрее, чем перезапуск Visual Studio, что я делал вначале.
Если кому-то интересно, я мог бы также добавить, что я вижу эту проблему только наполовину случайным образом. Обычно это происходит после того, как я внес некоторые изменения в режим дизайна формы (но не всегда). Обычно этого не происходит, если я изменяю только код бизнес-логики или невизуальный код (но иногда это происходит ...). Действительно разочаровывает, но, по крайней мере, у меня есть хак, который мне подходит - будем надеяться, что мой следующий проект тоже не столкнется с этой проблемой ...
@Barry: если вы хотите получить признание за свой комментарий, пожалуйста, не стесняйтесь публиковать его в качестве ответа, и я обязательно его приму :)
Я бы посоветовал загрузить Process Explorer , чтобы точно узнать, какой процесс блокирует файл. Его можно найти по адресу:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx