it-swarm.com.ru

Сбой сборки Visual Studio: невозможно скопировать exe-файл из obj\debug в bin\debug

Update: _ ​​Пример проекта, воспроизводящего эту ошибку, можно найти здесь, в Microsoft Connect . Я также проверил и подтвердил, что решение, приведенное в принятый ответ ниже работает над этим примером проекта. Если это решение не работает для вас, возможно, у вас другая проблема (которая относится к отдельному вопросу).


Этот вопрос задавался ранее, как здесь, в Переполнении стека, так и в других местах, но ни одно из предложенных мною предложений не помогло мне, поэтому мне просто нужно попробовать задать новый вопрос.

Сценарий: у меня есть простое приложение 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 ', поскольку он используется другим процессом. " (Я получаю как предупреждение, так и ошибку при запуске Rebuild, но только ошибку при запуске 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, и если да, то есть ли патч? Или я сделал что-то не так, есть ли у меня круговая ссылка или что-то подобное, и если да, то как я могу узнать?

Любые предложения высоко ценятся :)

Update: Как уже упоминалось в комментарии ниже, я также проверил с помощью Process Explorer, что он на самом деле is Visual Studio, которая блокирует файл.

185
Nailuj

Это будет звучать глупо, но я попробовал все эти решения, используя VS2010 на Windows 7. Ни одно из них не работало, кроме переименования и сборки, что было ОЧЕНЬ утомительно, если не сказать больше. В конце концов я разыскал виновника, и мне трудно в это поверить. Но я использовал следующий код в AssemblyInfo.cs ...

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

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

114
drharris

Я нашел одно простое решение, просто отключите службы индексирования Windows для папки и подпапок проекта

14
Pedro

Поскольку я не получил больше отзывов по этому вопросу, я подумал, что просто поделюсь тем, что оказалось моим решением:

Как предложил Барри в комментарии к исходному сообщению, вручную переименовывая '... bin\Debug [ProjectName] .exe' на что-то другое (например, '[ProjectName] 1.exe' ) Это один из обходных путей (однако мне не разрешено удалять файл самостоятельно, и я должен сказать, что нахожу это немного странным, поскольку можно было бы полагать, что та же самая блокировка, предотвращающая удаление, также предотвратит переименование ...). Это не очень хорошее решение, но оно достаточно быстрое (по крайней мере, после того, как вы это сделали пару раз, оно почти становится рутиной) и, по крайней мере, намного быстрее, чем перезапуск Visual Studio, что я и делал в начале.

В случае, если кто-то задается вопросом, я также могу добавить, что я вижу эту проблему только случайно. Обычно это происходит после того, как я сделал некоторые изменения в режиме дизайна формы (но не всегда). Обычно это не происходит, если я только изменяю код бизнес-логики или невизуальный код (но иногда это происходит ...). Разочарование действительно, но по крайней мере у меня есть взлом, который работает для меня - давайте просто надеяться, что мой следующий проект также не столкнется с этой проблемой ...

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

14
Julian

У меня та же проблема (MSB3021) с проектом WPF в VS2008 (в Windows 7 x32) . Проблема появляется, если я пытаюсь перезапустить приложение слишком быстро после предыдущего запуска . Через несколько минут exe-файл разблокирована сама по себе, и я могу перезапустить приложение снова. Но такая длинная пауза злит меня . Единственное, что действительно помогло мне, это запустить VS в качестве администратора.

12
Sergey

Когда я сталкиваюсь с этой проблемой, это связано с тем фактом, что проект, который я пытаюсь построить, устанавливается как проект запуска в решении, делающем заблокированный EXE-файл в папке obj (он также отображается в вашем диспетчере задач). щелкните правой кнопкой мыши другой проект в вашем решении и выберите «Установить стартовый проект». Это снимет блокировку, удалит ее из диспетчера задач и позволит вам построить.

9
Adrian Booth

Я попробовал все остальные предложения в ответах здесь, ни один из которых не сработал. В конце концов я использовал Process Monitor, чтобы обнаружить, что мой .exe, который не удалось собрать VS2010, был заблокирован системным процессом (PID = 4). Поиск SO ситуаций, связанных с этим, дал это ответ.

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

8
Eight-Bit Guru

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

6
Quinxy von Besiex

Отключить «Включить процесс размещения Visual Studio»  Project Debug Settings

5
BCS Software

ЕСЛИ ВАША ПРОБЛЕМА IS НЕ РЕШАЕТСЯ:

Ошибка Visual Studio:

«Процесс не может получить доступ к файлу« bin\Debug ** app.exe ** », так как он используется другим процессом».

Итак, зайдите в диспетчер задач Windows (Ctrl + Shift + Esc), найдите имя вашего приложения и заставить его закрыться с помощью Endprocces.

4
AmirHossein Rezaei

Используя 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
3
danielm

Я столкнулся с той же ошибкой.

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

Эта ошибка в основном происходит из-за изменения версии.

3
Utsav Dawn

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

3
Hassan_Jaffrani

Перезапустите IIS - это может быть процесс, связанный с отладчиком

3
Alan

Вот еще одна возможность:

После получения этой ошибки в vs2012/win7, я пошел и попытался удалить файл в каталоге bin, и Explorer указал, что файл использовался XAML Designer UI Designer.

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


и другая возможная причина:

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

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

Правка: у меня это случалось несколько раз, даже недавно с VS2012, и оно исправляет это, как только я устанавливаю порядок сборки на правильные зависимости, убиваю все процессы msbuild, которые VS оставил работающими, и затем перезапускаю VS. Я просто убиваю процессы msbuild, но закрытие VS также должно их убить.

Я обычно делаю для этого рефакторинг проекта таким образом, чтобы он опирался на другой проект в рамках решения, на который он не ссылался в прошлой сборке. Иногда кажется, что это сбивает с толку VS и не обновляет порядок сборки.

Чтобы проверить порядок сборки: Щелкните правой кнопкой мыши Решение в обозревателе решений и выберите «Порядок сборки проекта ...» и убедитесь, что зависимости правильно указаны для каждого проекта.

3
Kevin Shanahan

Это было зарегистрировано несколько раз на Connect, сайте сообщества по сообщению об ошибках Microsoft. К вашему сведению, эта ошибка затрагивает Visual Studio с 2003 года и исправляется после RTM каждый раз. :( Одна из ссылок выглядит следующим образом:

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

2
Michael

Я бы посоветовал скачать Process Explorer, чтобы точно узнать, какой процесс блокирует файл. Его можно найти по адресу:

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

2
Hans Olsson

Это довольно часто вызывается Avast. 

Я обычно могу запускать свои проекты в Release независимо, но при запуске в режиме отладки он довольно часто терпит неудачу. 

Я просто добавляю исключение для моей папки проектов, и проблема, похоже, исчезнет. Я предполагаю, что это также может быть вызвано другими антивирусами.

1
James Pusateri

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

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

1
Bassie

Переименование файлов .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;k%28TargetFramework22ORKFRAM % 2cVERSION% 3dV4.0% 22% 29 & rd = true

Я отменяю выбор, затем повторно устанавливаю флажок «Включить настройки безопасности ClickOnce». Уже несколько дней это без проблем ...

1
Yee

Если ничего из вышеперечисленного не работает, и вы разрабатываете консольное приложение:

Попробуйте ввести любой символ в Program.cs, а затем удалите его. Я понятия не имею, почему это работает, но, похоже, это решает проблему «Невозможно скопировать» каждый раз.

1
Greg

Когда я столкнулся с подобной проблемой, единственное, что, казалось, работало, было:

  • Щелкните правой кнопкой мыши по проекту, перейдите в «Настройки» и убедитесь, что сборки «Отладка» и «Выпуск» предназначены для одних и тех же настроек или содержат настройки, которые приложение пытается загрузить или сохранить.
  • Удаление папки C:\Users (YourUserAccount)\AppData\Local (YourAppName).
  • Убедиться, что никакие файлы, которые у меня были там, не считаются заблокированными. Щелкнув правой кнопкой мыши по файлам моего проекта, я понял, что одна иконка была фактически заблокирована и считается плохой, потому что она была загружена из Интернета. Мне пришлось нажать кнопку «Разблокировать» (например, проверьте это: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - «Этот файл пришел с другого компьютера и может быть заблокирован, чтобы защитить этот компьютер. ").
0
Alexandru

Одна вещь, которая действительно помогла мне, это добавить «.exe» в папку «Отладка» в «Исключения» на моем Антивирусе.

0
Ricardo Ferreira

Ни один из других ответов не работал для меня, но закрытие всех открытых вкладок в Visual Studio, похоже, решило проблему.

0
Ian Mercer

Я пробовал несколько решений, которые вы предоставили, но иногда я все еще получаю эту ошибку. Я уверен, что мой процесс не запущен, и когда я пытаюсь удалить исполняемый файл с помощью Internet Explorer, он удаляется из списка файлов, но затем я нажимаю F5 и вуаля, файл возвращается. Он не был удален вообще. 

Но если я удаляю файл через TotalCommander, exe-файл фактически удаляется, и я могу успешно построить проект.

Я использую Windows 7 x64 и Total Commander 7.56a 32 бит. 

0
Gico

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

0
ShaunnyBwoy

Сначала делай простые вещи.

Убедитесь, что часть вашего решения не заблокирована запущенным процессом.

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

Это заблокировало некоторые из моих библиотек в папке bin проекта службы Windows .... Когда я сделал перестройку, я получил исключение в этом вопросе.

Я остановил службу Windows, восстановил, и это удалось.

Проверьте диспетчер задач Windows для своего приложения, прежде чем выполнять какие-либо дополнительные действия в этом вопросе.

Поэтому, когда вы слышите шаги, думайте, что лошади не зебры! (от друга-студента-медика)

0
GregJF

В случае, если кто-то сталкивается с этим при попытке отладки юнит-теста или запуска юнит-теста, мне пришлось убить следующие два процесса, чтобы он освободил файл:

 processes to kill.

0
Haggis777

Я знаю, что это очень старый вопрос, но недавно я столкнулся с ошибкой «невозможно скопировать из obj to bin» в VS 2012. Каждый раз, когда я пытался перестроить определенный проект, я получал сообщение. Единственным решением было сделать чистку перед каждой перестройкой. 

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

В моем случае в верхней части файла было следующее:

#pragma warning(

Вот и все. Я предполагаю, что некоторое время назад пытался что-то сделать, отвлекся и не закончил процесс, но предупреждения VS об этой конкретной строке были потеряны в случайном порядке. В конце концов, я заметил предупреждение, удалил строку и восстановил работу каждый раз с тех пор.

0
Chris

У меня была такая же проблема. Он сказал, что не может скопировать из bin\debug в obj .....

Когда я строил веб-проект, я обнаружил, что все мои dll были в папке bin, а не в bin\debug. Во время публикации vs искал файлы в bin\debug. Поэтому я открыл файл веб-проекта в редакторе и посмотрел экземпляры bin\debug и обнаружил, что все библиотеки DLL упоминаются как bin\debug\mylibrary.dll. Я удалил все\debug с пути и опубликовал снова. На этот раз vs удалось найти все dll в папке bin, и публикация прошла успешно.

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

Я потратил более 5 часов на отладку этого и наконец нашел решение самостоятельно.

Это правильный ответ .

0
nccsbim071

[решено] Невозможно скопировать exe-файл из obj\debug в bin\debug:

Я подхожу к тому, что вы получаете эту ошибку, когда вы пытаетесь запустить два окна формы одно за другим, например, сначала загружая форму, а затем иногда она автоматически исчезает и вторая форма загружается на экран.

По сути, вам нужно закрыть свою первую форму, которая работает в фоновом режиме и основной причиной этой ошибки.

Чтобы закрыть первую форму, вы должны добавить эти две строки кода во второй обработчик события загрузки формы.

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

Это решит ошибку отлично.

0
Sabir Al Fateh

Повторное включение Application Experience службы Windows исправило такие проблемы для меня.

Смотрите следующие ссылки:

У меня была проблема с использованием Visual Studio 2008, 2010 и 2013 с Windows 7 64-битной.

0
Wollmich

Я нашел с VS2013, я получаю эту ошибку регулярно. Что-то, что, кажется, работает достаточно хорошо, - это выполнить решение Rebuild перед попыткой запустить приложение. Я обнаружил, что выполнение CLEAN иногда работает, но решение Rebuild, кажется, работает более последовательно.

0
mattpm

Это помогает мне после того, как я убрал флаг только для чтения из каталога bin . http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

0
Suhan
  1. Установить другой проект в качестве запуска
  2. Постройте проект (отобразится не проблемный проект)
  3. Перейдите в проблемную папку bin\debug
  4. Переименовать myservice.vshost.exe в myservice.exe
0
Peter PitLock

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

Проблема была на самом деле из-за сбоя сборки и неправильной ошибки . Фактической проблемой был недостаток проекта:

// 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(); 

После изменения области действия «а» за пределами функции или без использования «а» после 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
T.Coutlakis