Подтвердить что ты не робот

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

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


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

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

Когда я столкнулся с этой проблемой, это связано с фактом, что проект, который я пытаюсь создать, задается как проект запуска в решении, делающий файл .exe в заблокированной папке obj (он также появляется в вашей задаче менеджер), щелкните правой кнопкой мыши другой проект в своем решении и выберите "set startup project". Это освободит блокировку, удалит ее из диспетчера задач и позволит вам создавать.

Ответ 6

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

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

Ответ 7

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

Ответ 8

Отключить "Включить хостинг Visual Studio" Параметры отладки проекта

Ответ 9

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

Ошибка Visual Studio:

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

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

Ответ 10

Использование 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

Ответ 11

Здесь другая возможность:

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

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


и еще одна возможная причина:

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

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

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

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

Чтобы проверить порядок сборки: щелкните правой кнопкой мыши Решение в Обозревателе решений и выберите "Заказ сборки проекта..." и убедитесь, что зависимости указаны для каждого проекта.

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 16

Это было подано несколько раз на сайте сообществ сообществ сообществ 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

Ответ 17

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

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

Ответ 18

Это обычно вызвано Avast.

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

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

Ответ 19

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

Я отменил выбор, а затем снова установите флажок "Включить настройки безопасности ClickOnce". Это было проблемой бесплатно в течение нескольких дней...

Ответ 20

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

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

Ответ 21

Если кто-то работает с этим при попытке отладки Unit Test или Run a Unit Test, мне пришлось убить следующие два процесса, чтобы он мог освободить файл:

процессы для уничтожения.

Ответ 22

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

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

Я использую Windows 7 x64 и общий командный элемент 7.56a 32 бит.

Ответ 23

Простые вещи сначала.

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

Например, я запускал "InstallUtil" в моей службе Windows (обычно я unit test с консоли).

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

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

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

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

Ответ 24

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

Ответ 25

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

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

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

#pragma warning(

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

Ответ 26

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

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

Ответ 27

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

Ответ 28

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

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

// 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", потому что он не был найден.

Ответ 29

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

Ответ 30

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

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

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

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

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