Помилка: не вдається отримати доступ до файлу bin / Debug /…, оскільки він використовується іншим процесом

Коли я налагоджую проект, я отримую таку помилку:

"Неможливо скопіювати файл" obj \ Debug \ My Dream.exe "у" bin \ Debug \ My Dream.exe ". Процес не може отримати доступ до файлу" bin \ Debug \ My Dream.exe ", оскільки його використовує інший процес ".

Використовуючи Провідник процесів, я бачу, що MyApplication.exe був відсутній, але системний процес все ще використовує його, хоча я відмовився від налагодження раніше. Щоразу, коли я змінюю свій код і починаю налагоджувати, це станеться. Якщо я скопіюю проект на USB та налагоджую, він працює добре.

Чому? Як я можу виправити цю помилку?

Я використовую Window 7 Professional. З Xp я ніколи не отримував цієї помилки.

Фу, це стара проблема, яка все ще з’являється у Visual Studio раз у раз. Мене це покусало пару разів, і я втратив години перезавантаження та боротьби з VS. Я впевнений, що це обговорювалося тут на SO не раз. Про це також говорили на форумах MSDN. Немає фактичного рішення, але є кілька шляхів вирішення. Почніть дослідження тут .

Що відбувається, це те, що VS отримує блокування файлу, а потім не випускає його. За іронією долі, цей замок не дозволяє самому VS видалити файл, щоб він міг відтворити його під час відновлення програми. Єдине явне рішення - закрити та перезапустити VS, щоб він звільнив замок у файлі.

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

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

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

Я також ще не намагався відтворити його на VS 2012 RC. Я не знаю, чи це там ще зафіксовано чи ні. Але мій досвід до цього часу полягає в тому, що він все ще вдається вискочити навіть після того, як Microsoft заявила, що це виправили. Він все ще є у VS 2010 SP1. Я не кажу, що їхні програмісти - це ідіоти, які, звичайно, не знають, що роблять. Я вважаю, що в помилках є лише кілька причин і / або їх дуже важко відтворити в лабораторії. Це та сама причина, що я особисто не подавав жодних повідомлень про помилки (хоча я ще +1 до інших народів), тому що я не можу надійно відтворити його, швидше, як Гнучка Сніговик.

_{<кінцева рента, яка спрямована ні на кого особливо>}

У мене ця помилка виявлялася раніше, навіть у 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"

Комп'ютер (клацніть правою кнопкою миші) -> керуйте -> Сервіс та додаток -> послуга -> Увімкнути досвід роботи з програмою

Працювали для мене!

У мене був такий самий випуск у Visual Studio 2013. Я не впевнений, що спричинило це для мого проекту, але мені вдалося виправити його, очистивши рішення та відновивши його.

1. Збірка> Чистий розчин
2. Збірка> Перебудова рішення

Принаймні в моєму випадку я помітив, що візуальна студія 2012 створювала щонайменше два привидні msbuild.exe процеси, які не загинули після збирання. Ці зомбі, очевидно, спричиняють появу блокування файлів.

Вбивство msbuild.exe - це разове рішення, це потрібно робити за кожну збірку.

Але потім я зрозумів, що можу відключити паралельну збірку раз і назавжди - зайшов в Інструменти> Параметри> Проекти та рішення> Збірка та запуск> "Максимальна кількість паралельних збірок проектів" - за замовчуванням воно має значення 8, я перейшов на 1. Працює як шарм.

Звичайно, збірки зараз трохи повільніші, але краще безпечні, ніж шкода. Принаймні для цього маленького проекту мені не потрібно було більше ніж одна збірка ниток.

Я розумію, це старе питання. На жаль, я зіткнувся з тим же питанням зі своєю .net core 2.0заявою в visual studio 2017. Отже, я подумав поділитися рішенням, яке працювало на мене. Перед цим рішенням я спробував наступні кроки.

1. Перевтілена візуальна студія
2. Закрили всю програму
3. Очистіть моє рішення і відновіть

Жоден із перерахованих вище кроків не вирішив проблему.

А потім я відкрив свій Task Managerі вибраний dotnetпроцес, а потім натиснув кнопку Закінчити завдання. Пізніше я відкрив свою візуальну студію, і все працювало чудово.

Дивіться мою відповідь тут, якщо у вас є ця проблема під час запуску одиничних тестів. Відповідь скопійовано нижче:

Спираючись на відповідь Себастьєна, я додав крок перед складанням до свого тестового проекту, щоб автоматично знищити будь-які vstest.*виконувані файли, які все ще запущені. Наступна команда перед складанням працювала для мене:

taskkill /f /im vstest.*
exit 0

exit 0Команда в кінці , щоб запобігти збій збірки , коли немає vstest.*виконуваних файлів працює.

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

Щоб виправити це перш за все, вам потрібно зрозуміти програму, яка все ще його використовує. Я вимкнув усі процеси, такі як "MSBuild" і "MSBuild хост". Але цього недостатньо. Якщо ви встановили "Код контракти" та ввімкнули, то іноді потрібні DLL-файли для перевірки та припинення роботи цієї операції.

Отже, вам потрібно зупинити всі процеси "CCCheck.exe" і це все.

Нарешті, щоб зрозуміти, що процес використовує вашу DLL, ви завжди можете спробувати просто видалити папку "obj" у вашому файловому менеджері, і ця операція не вдасться, ви можете побачити "Вікно повідомлення" з описом висячої операції. Також як варіант ви можете спробувати використовувати додаток "Sys Internals Suite".

Працювали для мене. Диспетчер завдань -> Назва проекту -> Кінцеве завдання. (у мене було 3 однакові процеси з моєю назвою проекту);

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

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

Мене натрапило на цю проблему у Visual Studio 2017. Він розпочався приблизно два-три тижні тому і сильно з'їв мою продуктивність. Clean і Rebulid не працювали; навіть перезапуск моєї машини не справляється з цим.

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

Однак, напевно, найнадійнішим рішенням, яке я знайшов, є відкриття командного рядка розробника та використання msbuildбезпосередньо. Я займався цим останні три дні, і поки що ця проблема не виникала жодного разу.

У моєму випадку було те, що я ввімкнув "Показати всі файли". Візуальна студія 2017

Біжи taskmanager.
Знайдіть netcoreі видаліть його.
Потім можна видалити файл вручну або запустивши Clean.

Це чисті спекуляції, а не відповідь.

Однак у мене ця проблема була певний час.

Я прийшов через час підозрювати взаємодію між VS та моїми запобіжними засобами.

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

C: \ Користувачі [ім'я користувача] \ AppData \ Місцеві \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

папка не була включена до захисту в режимі реального часу.

Схоже, що збірка фактично спочатку записує DLL сюди, а потім копіює її до остаточного місця збирання.

Це може бути пізно Але я зіткнувся з подібною проблемою, і в моєму випадку проект мав самонавіювання. Отже, видалення його з посилань спрацювало як шарм !!!

Я знайшов найшвидший спосіб без закриття форм або перезавантаження VisualStudio - перейти на сторінку компіляції проекту та натиснути кнопку «Розширені параметри компіляції ...». Потім внесіть будь-які зміни в один із варіантів (скажімо, змінивши Згенерувати інформацію про налагодження з Full на лише pdb) і натисніть кнопку OK. Він працює щоразу і доведеться робити, поки MS не виправить цю помилку (у мене ніколи не було цієї проблеми, поки я не перейшов з VS2012 на VS2013)

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

Я спробував усі ці пропозиції, а також інші пропозиції, знайдені в інших місцях, і єдине, що працювало для мене, - це перезавантажити комп'ютер. Потім я зробив чисте рішення з подальшим відновленням. Я використовую Visual Studio 2013 для довідки.

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

Зазвичай я запускаю свою заявку

• через його exe або
• запускати без налагодження

Рішення закривається іншим екземпляром програми для форми Windows . Це один із способів завжди закривати екземпляр програми.

Попередньо скласти команду

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

Допомогли

[Вирішено] Помилка: Неможливо отримати доступ до файлу bin / Debug /…, оскільки він використовується іншим процесом:

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

По суті, вам потрібно закрити свою першу форму, яка працює у фоновому режимі, і головна причина цієї помилки.

Щоб закрити першу форму, вам потрібно додати ці два рядки коду до обробника подій завантаження другої форми.

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

Це дозволить вирішити помилку ідеально.

Одне з простих рішень - перейти до папки bin \ Debug, видалити всі файли у цій папці та відновити її. Якщо це не працює, закрийте Visual Studio, потім перейдіть до папки bin \ Debug за допомогою файлового провідника, на лівому конер натисніть Файл> Відкрити командний рядок> Відкрити командний рядок як адміністратор> Введіть цю команду "DEL / F / Q / A * "> потім відновіть

Я знайшов відповідь Коді Грея частково корисною тим, що вона спрямовувала мене до справжнього джерела моєї проблеми, який деякі з вас також можуть відчути: тестове виконання візуальної студії залишається відкритим за замовчуванням і підтримує блокування файлів.

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

Зніміть прапорець меню Тест -> Налаштування тестування -> "Тримайте двигун тестового виконання"

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

Закрийте VisualStudio, ctrl-alt-delete, виберіть диспетчер завдань, знайдіть і закінчіть всі процеси MSBuild - VisualStudio в основному має досить серйозну помилку, де він втрачає контроль над налагоджувачем, і налагоджувач підтримує блокування у файлі .pdb у відладці / біні. папку. Після того, як ви закінчите всі процеси MSBuild (налагоджувач), видаліть папку / debug / bin і заново відкрийте своє рішення у Visual Studio. Ти добре піти зараз. Майкрософт повинен виправити це лайно.

Я відкрив окреме питання щодо VS 2017, яке мало подібну поведінку після одного оновлення. Здається, проблема була породжена антивірусною програмою.

Я додав папку bin до списку виключення антивірусів, перезапустив машину і тепер, здається, працює.

Я вирішив цю проблему ..

біля налагодження ви бачите спадне меню з деякою конфігурацією. За замовчуванням був будь-який процесор. Виберіть x86 і запустіть програму, яка буде працювати. Якщо x86 там немає, перейдіть до диспетчера налаштувань і додайте x86

Ще одна хижак, так, але це просто і працює для мене в VS 2013. Клацніть на проект. На панелі властивостей має бути запис з назвою Файл проекту зі значенням

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

Змініть назву проекту - наприклад, додайте -01 до кінця. Оригінальний .zip-файл, який був заблокований, все ще є, але більше не посилається ... так що ваша робота може продовжуватися. Наступного разу, коли комп'ютер перезавантажиться, цей замок зникає, і ви можете видалити файл помилки.