Блокировка файлов при создании в Visual Studio 2010
Привет, Stackoverflow.
В последнее время, когда я программировал в Visual Studio 2010, у меня возникала проблема с VS, которая блокировала файл bin/Debug/(ProjectName).exe при попытке сборки и давала мне ошибку ниже, пытаясь постройте проект 10 раз:
Невозможно скопировать файл "obj\x86\Debug\TileEngine.exe" в "bin\x86\Debug\TileEngine.exe". Процесс не может получить доступ к файлу 'bin\x86\Debug\TileEngine.exe', потому что он используется другим процессом.
Проблема возникает, когда я редактирую источник, а затем пытаюсь отлаживать.
Я проверил использование разных программ, и единственной программой, использующей этот файл, является Visual Studio.
Если я подождал около 10 минут, прежде чем пытаться построить, он работает нормально, но при попытке разного типа не стоит ждать 10 минут, прежде чем что-то попробовать.
Я пробовал разные решения как на этом сайте, так и везде, где я могу найти в Google.
Некоторые решения, которые я нашел, но не работали для меня
Решение 1 - Использование предварительной сборки script
В некоторых разных вопросах здесь, в Stackoverflow, я нашел одно решение: вы заходите в Project Properties > Build Events
, а затем в командной строке события Pre-build добавьте:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Это позволило мне построить проект еще раз, чем я обычно мог, но при повторном редактировании кода, а затем при создании произошла ошибка.
Примечание.. Попытка создания версии вместо сборки отладки, похоже, разбивает предварительную сборку script и выходит из нее с кодом "1", что, похоже, делает VS неспособным построить должным образом. Удаление pre-build script заставляет его работать как "нормальный" снова, но с той же ошибкой.
Решение 2 - запуск Visual Studio в качестве администратора
Это еще одно решение, которое я нашел, но havent работал либо для меня, поэтому я предполагаю, что Visual Studio уже имеет все необходимые разрешения и работает, поскольку администратор на самом деле не имеет никакого значения.
Решение 3 - Изменение AssemblyVersion
В этом вопросе Ошибка сборки Visual Studio: невозможно скопировать exe файл из obj\debug в bin\debug, я нашел другое решение, которое включало изменение AssemblyVersion
, в файле Properties\AssemblyInfo.cs
, до "2.0.0.0"
.
Это, однако, не имело для меня никакого значения.
Решение 4 - Закрытие конструкторов UserControl до сборки
В соответствии с некоторыми различными ответами здесь и там в Интернете Visual Studio, по-видимому, использует встроенный исполняемый файл проекта для рендеринга конструктора UserControl
(?). В моем случае, вероятно, это не так, поскольку я использую XNA в основном и не использует конструктор UserControl
.
Решение 5 - Очистка ресурсов при закрытии приложения
Это может быть решение, которое я не смог реализовать должным образом. Я просто думаю, что если это решение, то почему я не должен был это делать раньше. Я предполагаю, что XNA выгружает все, что загружается через конвейер Content
, поэтому это решение не будет иметь никакого реального смысла.
Если есть кто-то, кто может рассказать о проблеме, это было бы действительно потрясающе, поскольку это мешает мне программировать что-нибудь действительно, потому что мне не нравится ждать 10 минут, потому что я сделал 2 секунды все время меняются.
Ответы
Ответ 1
Я столкнулся с этой проблемой несколько раз.
Моя может быть не по той же причине, что и ваша, но я расскажу вам, что со мной не так, и как я ее исправил, надеюсь, это будет полезно для вас.
В принципе, моя программа никогда полностью не выходила должным образом, даже когда она появилась. Он будет продолжать работать и, таким образом, продолжать блокировать файл.
Быстрое грязное исправление, которое я использовал первоначально (и способ доказать, что это так):
- Откройте диспетчер задач (Ctrl-Alt-Del)
- Нажмите вкладку "Процессы"
- Найдите имя своей программы (TileEngine.exe)
- Примечание. Вероятно, будет name_vshost.exe(TileEngine_vshost.exe). Что-то вроде VisualStudio, игнорируйте это, это не актуально.
- Если вы его нашли, это означает, что ваша программа не полностью вышла полностью.
- Если он есть, нажмите на него и нажмите "Завершить процесс"
Итак, если это так, то по какой-то причине ваша программа не закрылась, как моя.
Часто это из потока, запускаемого и забытого, или задачи Async, которая никогда не завершается, или что-то в этом роде.
Убедитесь, что в вашей функции OnExiting (..) void вы убиваете все запущенные потоки.
Если ваша программа все еще работает, несмотря на лучшие попытки закрыть все потоки и другие блокираторы, вы можете использовать очень грязный плохой метод:
В OnExiting (...) запустите код "System.Diagnostics.Process.GetCurrentProcess(). Kill();" - это приведет к тому, что команда taskmanager запустит текущий процесс... это только как экстренный метод I-can't-make-it-work-any-other-way.
Ответ 2
Думаю, я нашел решение сам.
В свойствах проекта "Включить процесс хостинга Visual Studio" не было проверено. Проверка, кажется, устраняет проблемы, по крайней мере на данный момент.
Напомнил об этом из сообщения mcmonkey4eva. Так спасибо за это =)
И спасибо за ответ, который у меня есть. Stackoverflow - это потрясающе!
Ответ 3
Вы проверили, заблокированы ли какие-либо файлы вашим брандмауэром? Когда я перешел на полную версию Avast, я обнаружил, что мне нужно отключить File System Shield. Мне очень хочется удалить мои исполняемые файлы, когда я пытаюсь запустить проекты своей визуальной студии.
У меня возникли проблемы при обновлении до VS2012 Professional. (SDK,.NET, Visual С++ распространяемый пакет)
ОБЕСПЕЧИВАЙТЕ ВСЕ ЭТИ, СОВЕРШЕННЫЕ С ТОЧНОЙ ВЕРСИЕЙ ВАС ИСПОЛЬЗУЯ
Что я сделал, было , я закончил удаление ВСЕГО, связанного с загрузкой в Visual Studio. Если вы можете удалить и сохранить файлы проекта в другом месте, а затем вернуть их. Пройдите через все ваши программные файлы, чтобы увидеть, есть ли что-то скрытое в неправильной папке и проверьте ваш диск C.
Это означало загрузку и переустановку (свежий):
Я думаю, что если вы очищаете файлы своей программы, все должно быть в порядке. Я бы не рекомендовал заходить в ваш реестр, если вы не уверены в том, что делаете. Если вы уже внесли изменения в регистр, тогда мы рассмотрим этот и другие параметры (если это не решит вашу проблему).
Ответ 4
Попробуйте удалить проверку на чтение с вашего решения, сняв флажок на уровне папки.
Ответ 5
Я столкнулся с этой проблемой, и в моем случае это было связано с включением bin в решение; как только я исключил папку bin из моего решения, проблема исчезла.
Ответ 6
Ничего не помогло, а не команды prebuild, ни дизайнеры не закрывались, но я понял способ, который помог мне, просто перейдя от отладки к выпуску и наоборот выпустив заблокированные файлы, и вы можете удалить их, не закрывая IDE.
Ответ 7
Я регулярно получаю эту проблему, если я переключаюсь с Debug на Release, а затем сразу F5 компилируется. Сумасшедший, поскольку это звучит, ожидая, скажем, через минуту после переключения между режимами, это предотвратит это.
Если он заблокирован, единственным решением является закрытие Visual Studio и повторное открытие.
Ответ 8
Я решил эту проблему, организуя свои ресурсы для решения. Я заметил эту ошибку, когда я поместил некоторые изображения в свое приложение в ту же папку решений.
Итак,
- Я удалил все изображения и ресурсы из приложения, сохранил без него.
- Перемещено изображения во внешнюю папку Solution.
- Откройте решение и снова добавьте это изображение, используя кнопку "Импорт" на элементах управления.
Если вы попробуете это, не забудьте сделать это с помощью значка приложения, в настройках проекта.
Теперь все отлично работает для меня.
Надеюсь, это поможет.
Ответ 9
Вам нужно отключить Windows Indexer, поскольку он блокирует файл
Следуйте этому руководству, как отключить
Ответ 10
В моем случае проблема, похоже, вызвана удаленным отладчиком. Он запускается на локальном компьютере при компиляции с параметром "x64". Попытайтесь изменить настройку проекта (свойства/buid), пока не достигнете окончательной версии.
Ответ 11
Измените цель сборки платформы с x86 на любой CPU.