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

У мене є webformsдодаток C # , який до сьогодні працював просто плавно.

Зараз сьогодні раптово, коли я намагаюся запустити програму, я отримую помилку блокування файлу:

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

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

Закриття VS і повторне відкриття кожного разу, коли я хочу запустити програму, не є життєздатним обхідним шляхом! Як дізнатись, що блокує файл, і зупинити його блокування?

EDIT: Ще одне цікаве відкриття: мені навіть не потрібно запускати програму. Просто його компіляція викликає блокування файлу; Я не можу скласти двічі поспіль!

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

Я знайшов просте рішення, яке мені підходить. Це виглядає так:

Коли проблема виникає, просто змініть конфігурацію будівлі у верхній частині (якщо в «Випуск» на «Налагодження» і навпаки), побудуйте, а потім поверніться до попередньої конфігурації та будуйте знову.

Я припускаю, що зміна конфігурації звільняє vcshost та devenv.

Що ж, я вирішив проблему сам - хоча досі не знаю, чому. Я вирішив відокремити проблему, видаливши всі файли з проекту, потім повторно додавши їх та визначивши, який саме файл був джерелом моїх проблем. Отже, по черзі я повторно вводив файли в проект, компілював і очищав кожен крок ... до ..., поки не додав останній ...

... і все ще працювало нормально.

Я зробив порівняння з контролем джерела мого оригінального .csproj; реальних відмінностей немає. І навіть коли я спробував повернутися до попередньої версії .csproj, він все одно працював.

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

РЕДАКТУВАТИ: Проблема є періодичною, і я вважаю, що я виділив її, коли відкриваю конструктор форм абстрактної / загальної форми під час компіляції.

Вивчений урок: Переконайтесь, що конструктор форм будь-яких абстрактних або загальних форм або елементів керування закритий перед компіляцією! Якщо ні, вам доведеться закрити VS і знову відкрити!

Ми виявили тут наступне: На сторінці властивостей проекту, на вкладці Налагодження, зніміть прапорець біля пункту «Увімкнути процес хостингу Visual Studio». Я не впевнений, для чого призначена ця властивість, але вона виконує роботу, коли не перевіряється.

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

якщо існує "$ (TargetPath) .locked" del "$ (TargetPath) .locked" якщо існує "$ (TargetPath)", якщо не існує "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .locked "

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

Також зауважте, що -app-vshost.exe працює у фоновому режимі, навіть коли не налагоджено. Саме це змушує його успішно будувати та запускати кожного разу, коли я здогадуюсь. Раніше він не працював. І я також спробував очистити папки налагодження та випуску та постійно змінювати цільовий тип, і нічого не працювало, крім описаного вище. Моє рішення раніше було просто зачекати 5 хвилин між збірками, що надзвичайно дратує і вимагає багато часу, щоб щось зробити. Я не бачив жодної зміни в поведінці, коли це мало значення, які вкладки відкриваються чи XNA проти форм Windows або відкриваються дизайнери. Ця проблема виникла у 32-розрядних або 64-розрядних збірках, і не мало значення, чи я вбив програму за допомогою ALT-F4, чи вбив її за допомогою диспетчера завдань, що теоретично не дозволило б програмі закрити або звільнити ресурси. Спочатку я думав, що це проблема вивезення сміття.

VS2017 - вирішено шляхом закриття всіх екземплярів MSBuild.exe у диспетчері завдань Windows

Трохи пізно відповісти, але я вирішую це, перейшовши до властивостей проекту> вкладка «Налагодження»> зніміть прапорець «Увімкнути процес хостингу Visual Studio».

Я подолав цю проблему, перейменувавши заблокований файл (за допомогою Провідника Windows). Мені не дозволили видалити файл, але перейменування заблокованого файлу працює!

Я вирішив це, видаливши папку bin \ Debug і, можливо, перезапустивши VS

Для мене це була служба Windows, яка була встановлена ​​і працювала. Як тільки я його зупинив, збірка була успішною.

Запустіть цю команду з вікна Виконати:

net stop iisadmin /y

і потім

iisreset

працював у мене. проти 2003 року

Нещодавно зіткнувся з цією проблемою при спробі побудувати рішення, над яким я працюю (а не лише про WinForms proj).
На додаток до buildвідмови, я помітив, що проекти очищення будуть тихо провалюватися (перевірка папки bin показала, що файли насправді не були стерті), а закриття Visual Studio не закінчило devenvпроцес - швидше, це призвело до його збою. Потім процес відновлення Windows перезапустить Visual Studio.

Після деяких спроб та помилок я виявив, що проблеми трапились зі мною лише тоді, коли я відкрив рішення з меню "Нещодавні" при запуску VS.
Відкривши рішення, File >> Open >> Project/Solutionвиявилося, що воно працює, як зазвичай.

В даний час не уявляю, чому - продовжуватиму вивчати це, але наразі я принаймні можу працювати!

Просто перевірте посилання та видаліть самозсилання на проект.

Пояснення: Моя проблема почалася після створення користувацького елемента керування та перетягніть його на палітру панелей інструментів для використання у формах дизайну. Спочатку з’явилося попередження про те, що між користувацьким вихідним файлом керування (.cs) та виконуваним файлом проектів (.exe) є надмірність. При виконанні / налагодженні з'явилася помилка: неможливість отримати доступ до (.exe), оскільки він використовується (і це було правдою).

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

У мене була та сама проблема з моєю програмою Xamarin у візуальній студії, і вона була вирішена відключенням мого тестового мобільного пристрою. Додаток було закрито, а налагоджувач зупинено, але помилка все ще траплялася під час спроби побудувати або відновити рішення. Він зупинився лише після того, як я відключив пристрій, тому що мені довелося отримати дзвінок.

Просто кинути мої 2 центи. Мою проблему було вирішено відкриттям диспетчера завдань та вбивством програми. Він працював у фоновому режимі без жодних ознак того, що він взагалі працював (жодного елемента на панелі завдань, жодного інтерфейсу користувача, нічого), але я не впевнений, чому це сталося. Очевидно, що налагоджувач не працював, і на той момент у мене був відкритий лише один екземпляр VS. Мене вражає, що це все ще відбувається у цій VS 2017.

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

У мене була та сама проблема, і я не зміг її виправити, використовуючи жоден із методів, згаданих у попередніх відповідях. Я вирішив проблему, вбивши всі екземпляри "SSIS Debug Hist (32 bit)" у диспетчері завдань і тепер працюю як зазвичай.

Видалення Obj, роздрібної та налагоджувальної папки проекту .NET та відновлення знову працювали для мене.

Як налаштовано ваш веб-додаток? Він працює під Cassini (веб-сервер лотка) або IIS?

Однак це не повинно відбуватися нормально. Я думаю, що ProcessExplorer може сказати вам, які файли заблокував процес. Якщо не обробити Explorer, один із інших інструментів sysinternals.

Одне, що потрібно спробувати перед тим, як навіть завантажити один із інструментів SI, - це зупинити веб-сервер Кассіні та перевірити, чи це звільняє файл.

У мене спрацював перезапуск IIS

у мене була така сама проблема. зміна налаштування налагодження / випуску не зробила трюку. принаймні не без побудови між ними.

у моєму рішенні (winform) це було вирішено шляхом відкриття основної форми winform у конструкторі. перехід на код (F7). Потім закриваємо код, закриваємо конструктор winform і відновлюємо все (ctrl-shift-B). Це спрацювало для мене.

здається, що якийсь дескриптор із програми winform (яка запускає фонову роботу) все ще мав дескриптор файлу в деяких інших використовуваних бібліотеках.

У мене два екземпляри Visual Studio відкривали одне і те ж рішення.

У моєму випадку були запущені деякі процеси vstest (з різними іменами, але всі містять рядок vstest). Мені довелося припинити їх у taskmgr.

Та сама помилка, вирішена оновленням пакетів підтримки Google Nuget

Коли я закінчив процес .Net Core Host, все склалося чудово. Мені не довелося закривати Visual Studio або щось інше змінювати.

Для тих, хто розробляє VS за допомогою Docker, перезапустіть докер для служби Windows, і проблема буде негайно вирішена.

До перезапуску докера я спробував усі згадані відповіді, не знайшов запущеного процесу msbuild.exe, також спробував перезапустити VS без користі, працював лише перезапуск докера.

Ще одне рішення: коли файли блокуються, повідомляється про процес блокування (щось на зразок "ServiceHub.Host.CLR.x64 (7764)") з його ідентифікатором у дужках. Щоб позбутися процесу, відкрийте PowerShell (x + Win + I) і введіть: "Stop-Process -Id idNumber".

Нещодавно я зіткнувся з проблемою під час розгортання в Service Fabric. Помилка означає, що використовується "файл", однак я виявив, що порт використовувався іншою IDE. Зупинивши працюючу службу, яка вже розміщувалась у порту, я зміг зупинити цей виняток.

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

Я вирішив цю проблему, закривши підключення з Провідника серверів і закривши всі вкладки, які були відкриті у Visual Studio.

Якщо це проект SSIS, відкрийте диспетчер завдань і вбийте всі екземпляри DtsDebugHost.exe, які повинні звільнити заблоковані файли.

Я використовую Visual Studio Code і отримав цю помилку, оскільки працював сервер розробників (я запустив сервер розробників, натиснувши Ctrl + F5 ).

Таким чином, я просто натиснув на знак зупинки, щоб зупинити його, і помилка зникла.

У мене була ця проблема (і її проблема я бачив в інших місцях, не лише проти VS).

Це викликано Dropbox (у моєму випадку). Після редагування коду та натискання кнопки запуску іноді dropbox негайно блокує файл (щоб він міг його обробити).

Рішення 1. Просто знову натисніть біг

Рішення 2. Призупиніть dropbox. (не добре, якщо ви використовуєте dropbox як хмарну резервну копію)

Рішення 3. Видаліть папку збірки зі списку синхронізації dropboxes.