Помилка побудови Visual Studio: неможливо скопіювати exe-файл з obj \ debug в bin \ debug


193

Оновлення: Зразок проекту, що відтворює цю помилку, можна знайти тут у Microsoft Connect . Я також перевірив і перевірив, що рішення, наведене у прийнятій відповіді нижче, працює на цьому зразковому проекті. Якщо це рішення не працює для вас, напевно, у вас виникло інше питання (яке належить до окремого питання).


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

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

Проблема: На деякий час все було добре. Тоді Visual Studio не вдалося побудувати, коли я збирався запустити програму. Я отримав попередження "Неможливо видалити файл '... bin \ Debug \ [ProjectName] .exe'. Доступ до шляху '... bin \ Debug \ [ProjectName] .exe' заборонено."і помилка "Неможливо скопіювати файл 'obj \ x86 \ Debug \ [ProjectName] .exe" у "bin \ Debug \ [ProjectName] .exe". Процес не може отримати доступ до файлу' bin \ Debug \ [ProjectName] .exe "тому що він використовується в іншому процесі." (Я отримую як попередження, так і помилку під час запуску Перебудувати, але лише помилку під час запуску 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 , що блокування файлу.


4
Ви перевірили, чи правильно закривається ваш додаток? Чи показує менеджер завдань вам [ProjectName] .exe у списку процесів?
miensol

2
У мене це було раніше, і я просто перейменував файл на .old etc. і знову запустив збірку. Не точно виправлення, яке я знаю, але воно працювало на мене.
codingbadger

@miensol: Так, схоже, належним чином закривається. Я отримую "Програма" [1848] [ProjectName] .vshost.exe: Managed (v4.0.30319) "вийшла з кодом 0 (0x0)." @Barry: перейменування exe-файлу у bin \ Debug працює, але, як ви вже сказали, це насправді не рішення, і це буде дуже прикро робити щоразу. Трохи краще, ніж перезапуск Visual Studio, хоча ...
Джуліан

2
@Naliluj: Я наткнувся на цю статтю з форуму Microsoft, в якій пояснюється, що вона може бути пов’язана з файлами ресурсів. Якщо ви використовуєте Resx-файли, це може дати підказку.
Патрік

1
Для нащадків у мене була ця проблема, і вона була вирішена шляхом додавання елемента <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> у мій файл csproj.
ThisIsTheDave

Відповіді:


117

Це здасться дурним, але я спробував усі ці рішення, запустивши VS2010 на Windows 7. Жоден з них не працював, крім перейменування та побудови, що було ДУЖЕ нудно сказати. Врешті-решт я відшукав винуватця, і мені важко повірити. Але я використовував такий код у AssemblyInfo.cs ...

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

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


12
Це одна божевільна ідея, я дам вам це;) Що ще божевільніше, це те, що він насправді, здається, працює! Я вже кілька разів перевіряв це, і можу підтвердити, що при використанні збірної версії на зразок "2.0. *" Я отримую помилку, але коли замість цього використовую "2.0.0", це працює як шарм! Я закликаю більше людей перевірити це, і якщо ви вважаєте, що це працює, будь ласка, проголосуйте цю відповідь, тому що це щось, що потрібно знати! Сподіваюсь, Microsoft підходить до цього ... Дякую drharris :)
Джуліан

2
це не спрацювало для мене, коли я перезавантажував VS, я не помилявся колись. Щоразу, коли я отримую цю помилку, мені доводиться перезапускати VS 2010
Sharique

6
фій ... це для мене не вийшло. Мої налаштування завжди були: [зборка: AssemblyVersion ("1.0.0.0")] [асамблея: AssemblyFileVersion ("1.0.0.0")]
tbone

4
Якщо у вас зараз [Assembly: AssemblyVersion ("1.0.0.0")], замініть його на [Assembly: AssemblyVersion ("2.0.0.0")] (тобто '2' замість '1'). Це працювало для мене. Хоча я ще не перевірив, можливо, просто змінити версію на щось інше, ніж те, що у вас зараз, може вирішити цю проблему.
Фредерік Дурень

1
Працює і для dll! VS каже, що не може скопіювати dll і після зміни BOTH [Assembly: AssemblyVersion] та [Assembly: AssemblyFileVersion ()] з 1.0. * До 2.0.0.0, вона працювала.
AZ.

14

Оскільки я не отримав більше відгуків з цього питання, я подумав, що я просто поділюсь тим, що в результаті було моїм рішенням:

Як запропонував Баррі в коментарі до початкової публікації, вручну перейменувавши "... bin \ Debug [ProjectName] .exe" на щось інше (наприклад, "[ProjectName] 1.exe" ) - це одна обробка (я " м, однак мені не дозволяється видаляти файл самостійно, і я мушу сказати, що я вважаю, що це трохи дивно, як можна було б вважати, що той самий замок, що запобігає видаленню, також запобіжить перейменуванню ...). Це не гарне рішення, але це розумно швидко (принаймні після того, як ви зробили це пару разів, це майже стає рутиною), і, принаймні, швидше, ніж перезапуск Visual Studio, що я робив на початку.

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

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


Я проголосував за це, оскільки це я робив у минулому. Я згоден, це брудне рішення, але воно працює. У В. С. була ця проблема протягом кількох ітерацій. Я завантажую свій проект також з мережевого режиму. Йому повністю довіряють, але це не має значення. Не має значення, чи це привід відображення чи UNC. Так, MS справді потребує виправлення цього. У них закрита помилка, яка говорить про неможливість відтворення. Кульга!
Джош Робінсон

14

Я знайшов одне просте рішення, просто вимкніть службу індексування Windows для папки та підпапок проекту


2
Це працювало і для мене. Я не впевнений, що я розумію, чому, коли провідник процесів показав, що devenv.exe тримає ручку блокування. Тим не менш, вимкнення індексації вирішило проблему.
Фопедуш

1
@Fopedush Я зіткнувся з цією проблемою з тим же рішенням, хоча я цього часу не бачив цього питання. У цій відповіді є пояснення, чому це допомагає.
Даррен Хейл

1
Цей зробив це для мене.
Мартін Каподічі

12

У мене така ж проблема (MSB3021) з проектом WPF у VS2008 (у Windows 7 x32). Проблема, яка з’являється, якщо я спробую запустити програму занадто швидко після попереднього запуску. Через кілька хвилин exe-файл розблокується сам, і я можу знову запустити додаток. Але така тривала пауза мене злить. Єдине, що мені справді допомогло - це запуск VS в якості адміністратора.


1
Я знайшов останній звіт про помилку щодо цієї точної проблеми: connect.microsoft.com/VisualStudio/feedback/details/558848/… Цей звіт про помилку надав зразок проекту, який зміг відтворити помилку. Тут також працювало рішення, запропоноване drharris (див. Вирішення, розміщене у вищенаведеному посиланні, покрокове рішення зразкового проекту).
Джуліан

Це єдине рішення, яке працювало і для мене. Дякую @Nailuj!
Вінгер

Це точно простіше, ніж перезапустити VS.
Ельведін Гамзагіч

1
"Сторінку не знайдено" для проблеми з підключенням, вони просто видалили її збентеження = S Чи коли-небудь було розміщене рішення / вирішення цього питання?
Купи

9

Коли я зіткнувся з цією проблемою, це пов'язано з тим, що проект, який я намагаюся створити, встановлюється як проект запуску в рішенні, що робить .exe в папці obj заблокованою (вона також з’являється у вашому менеджері завдань,) клацніть правою кнопкою миші інший проект у своєму рішенні та виберіть встановити проект запуску. Це звільнить замок, видалить його з диспетчера завдань і дозволить вам будувати.


1
Це працює для мене кожен раз. Здається, це стосується процесу vshost, який створюється та розпочинається для послуг
jaywayco

8

Я спробував усі інші пропозиції у відповідях тут, жодна з яких не спрацювала. Врешті-решт я використовував Монітор процесів, щоб виявити, що мій .exe, який VS2010 не вдалося створити, був заблокований системним процесом (PID = 4). Пошук ТА щодо ситуацій, пов’язаних із цим, дав таку відповідь.

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


+1 Я раніше спробував усе інше (1. диспетчер завдань, 2. провідник процесів, тобто тісна ручка, вікна якої мені не дозволяли, 3. відключення антивірусу, 4. виключення APP_DATA / Local / Microsoft / Visual Studio з служби індексування Windows. ), але ця порада стосується: "Досвід застосування" - це єдиний, хто врятував мене, стукаючи головою об стіну. Я це дозволив, і проблема пішла. Смішна річ, після того, як я її знову відключив, все було все в порядку. У мене більше не було проблем. Але, безумовно, це єдине, що сортувало це для мене.
Томаш

Працюй і для мене !!! Єдине, що також працює - це видалити папку bin перед запуском програми, але перед запуском потрібно видаляти завжди, дуже дратує.
E_Blue

6

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


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


4

Я б запропонував завантажити Process Explorer щоб дізнатися, який саме процес блокує файл. Його можна знайти за адресою:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Я погоджуюся - це не обов'язково VS, що блокує файл. У цьому можуть бути винні перевіряючі віруси. Спробуйте вимкнути перевірку вірусів, щоб побачити, чи це допомагає.
Поліфун

Вибачте, я забув згадати, що я вже це зробив. І це говорить про те, що Visual Studio (devenv.exe) має блокування у файлі ([ProjectName] .vshost.exe). Тож і мені це не дуже допомагає.
Джуліан

@ShellShock: відключення мого антивірусу (Avast) також не допомагає.
Джуліан

Для мене, використовуючи Sysinternals ProcessExplorer, я бачу ручку до цього файлу, але коли я натискаю на нього, не відображається жодна програма, яка тримає його, і коли я намагаюся закрити ручку, я отримую "Процес відкриття помилки: ручка недійсний ". помилка в ProcessExplorer. Але замок все ще зберігається.
tbone

4

Використовуючи Visual Studio, я ніколи не міг придумати простий проект для відтворення помилки.

Моїм рішенням було відключити процес хостингу Visual Studio.

Для тих, хто цікавиться, я додав слід ручки для порушника:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

якщо ви бачите в самому верху питання, є посилання на Microsoft Connect із звітом про помилку та зразковим проектом, який відтворює помилку: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Джуліан

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

4

ЯКЩО ВАША ПРОБЛЕМА НЕ РЕШЕНА:

Помилка Visual Studio:

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

Отже, перейдіть до менеджера завдань Windows (Ctrl + Shift + Esc), знайдіть ім’я програми та змусіть її закритись Endprocces.


3

Ось ще одна можливість:

Отримавши цю помилку в vs2012 / win7, я пішов і спробував видалити файл у каталозі bin. Провідник вказав, що файлом користувався конструктор інтерфейсу XAML.

Я закрив усі відкриті вкладки в VS, закрив VS, а потім переконався вбити всі процеси MSBuild у менеджері завдань. Нарешті, після перезавантаження VS я зміг створити рішення.


та ще одна можлива причина:

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

Це вводить в оману візуальну студію, думаючи, що вона може будувати деякі проекти одночасно, створюючи таким чином файлові блоки.

EDIT: У мене це траплялося кілька разів, навіть недавно з VS2012, і це все виправляє, коли я встановлюю порядок складання на правильні залежності, вбиваю будь-які процеси побудови MSS, які VS залишився запущеним, а потім перезавантажую VS. Я вбиваю msbuild-процеси просто для того, щоб бути впевненим, але закриття VS також повинно вбити їх.

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

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


Нещодавно ми це переживали на проекті WinPhone 8. Незрозуміло, що причиною було використання типу Tuple. Видалення коду, який використовував канал, проблема усунулася. Додайте код назад, коли проблема повернулася.
Seamus

У мене була проблема з VS2012, закриття VS не робило хитрощів - доведеться вбити всі завдання msbuild.exe вручну
морда

Я використовую VS 2013, і мені вдалося просто вбити процес "XDesProc.exe * 32" (Microsoft Visual Studio XAML UI Designer) у менеджері завдань перед кожною збіркою, і це зробило трюк. Не потрібно перезапускати VS, оскільки дизайнер інтерфейсу XAML, здається, перезавантажується кожен раз, коли ви відкриваєте файл * .xaml у дизайнерському вікні.
Тім Секстон

3

Перезапуск IIS - може бути процесом, приєднаним до налагоджувача


3

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


3

Я зіткнувся з тією ж помилкою.

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

Ця помилка в основному відбувається через зміни версії.


2

Це було неодноразово подано на сайті Connect, Microsoft, який повідомляє про помилки у спільноті. FYI, я вважаю, що ця помилка постраждала від Visual Studio з 2003 року і її виправляли після RTM кожен раз. :( Одне з посилань:

https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0


1

Зробіть спочатку прості речі.

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

Наприклад, я запустив "InstallUtil" на моїй службі Windows (яку я зазвичай тестую з консолі).

Це заблокувало деякі з моїх dll у папці bin проекту Windows. Коли я здійснив перебудову, я отримав виняток у цьому випуску.

Я зупинив службу windows, відновив і це вдалося.

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

Тож, коли ви чуєте кроки, думайте, що коні не зебри! (від друга студента-медика)


1

У мене була така ж проблема. Він сказав, що не може скопіювати з bin \ debug в obj .....

Коли я будував веб-проект, я виявив, що мій dll був у папці bin, а не у bin \ debug. Під час публікації vs шукав файли у bin \ debug. Тому я відкрив файл веб-проекту в редакторі і шукав екземпляри bin \ debug, і я виявив, що всі dll були згадані як bin \ debug \ mylibrary.dll. Я видалив усі \ налагодження із шляху та опублікував знову. Цього разу vs вдалося знайти весь dll у папці bin і публікація вдалася.

Я поняття не маю, як цей шлях змінився у файлі веб-проекту.

Я витратив більше 5 годин на налагодження цього і, нарешті, знайшов рішення самостійно.

Це правильна відповідь .


1

Якщо жодне з перерахованих вище не працює, і ви розробляєте консольний додаток:

Спробуйте ввести будь-який символ у Program.cs, а потім видаліть його. Я поняття не маю, чому це працює, але, здається, кожен раз вирішувати проблему "Неможливо скопіювати".


1

Це досить часто спричинено Avast.

Зазвичай я можу запускати свої проекти в Release незалежно від цього, але при запуску налагодження це досить регулярно виходить з ладу.

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


1

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

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29; % 3dV4.0% 22% 29 & rd = вірно

Я знімаю прапорець, а потім повторно поставте прапорець "Увімкнути настройки безпеки ClickOnce". Це вже кілька днів без проблем ...


1

Для мене це було викликано відкриттям командної лінії в цільовій папці ( C:\users\username\source\repos\project\project\bin\debug\app.publish).

Не впевнений, чому DEBUGGING вимагає доступу до папки публікації, але закриття вікна команд вирішило проблему для мене.


1

У випадку, якщо хтось стикається з цим під час спроби налагодити тест одиниці чи запустити тест одиниці, мені довелося вбити наступні два процеси, щоб він випустив файл:

процеси вбивства.


0

Я спробував кілька запропонованих вами рішень, але час від часу я все-таки отримую цю помилку. Я впевнений, що мій процес не працює, і коли я намагаюся видалити виконуваний файл із Internet Explorer, він видаляється зі списку файлів, але потім натискаю F5 і вуаля, файл повертається. Його взагалі не видалено.

Але якщо я видалю файл через TotalCommander, файл EXE буде фактично видалений, і я можу успішно створити проект.

Я використовую Windows 7 x64 і загальний командир 7.56a 32 біт.


0

Жоден з інших відповідей не працював для мене, але закриття всіх відкритих вкладок у Visual Studio, схоже, вирішило проблему.


0

Я знаю, що це дуже давнє запитання, але нещодавно у VS 2012. виникла помилка "не можу копіювати з obj в bin". Кожен раз, коли я намагався відновити певний проект, мені надходило повідомлення. Єдиним рішенням було зробити прибирання перед кожною перебудовою.

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

У моєму випадку у верхній частині файлу було таке:

#pragma warning(

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


0

Коли я стикався з подібним питанням, єдине, що, здавалося, спрацювало:

  • Клацніть правою кнопкою миші проект, перейшовши в Налаштування та переконайтесь, що і налагодження, і версії випуску націлені на однакові налаштування, або там є налаштування, які програма намагається завантажити або зберегти.
  • Видалення папки C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Переконайтесь, що жоден файл, який у мене там, не вважався "Заблокованим". Клацнувши правою кнопкою миші файли мого проекту, я зрозумів, що одна піктограма заблокована та вважається поганою, оскільки її завантажено з Інтернету. Мені довелося натиснути кнопку Розблокувати (наприклад, перевірити це: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Цей файл прийшов з іншого комп'ютера і може бути заблокований, щоб допомогти захистити цей комп'ютер. ").

0

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


0

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

Проблема була насправді через збій збірки та неправильну помилку. Актуальною проблемою був недолік дизайну:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Після зміни обсягу "a" на поза функцією, або не використовуючи "a" після Task.Factory.StartNew(); , я зміг створити заново.

Це сталося під час використання VS2012 Update 4 на Windows7x64 sp1.

Повідомлення про помилку:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): помилка MSB3030: Не вдалося скопіювати файл "obj \ x86 \ Debug \ xxx.exe", оскільки його не знайдено .


0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.