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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибка Visual Studio:

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: У меня это случалось несколько раз, даже недавно с VS2012, и он исправляет это, как только я устанавливаю порядок сборки на правильные зависимости, убиваю все процессы msbuild, которые VS оставил запущенными, а затем перезапускаю VS. Я убиваю процессы msbuild на всякий случай, но закрытие VS должно убить и их.

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

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

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

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

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

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

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

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

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

В первую очередь делайте простые вещи.

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно это вызвано Avast.

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

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

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

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

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

Не уверен, почему ОТЛАДКА требует доступа к папке публикации, но закрытие командного окна решило проблему для меня.

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

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

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

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

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

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

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

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

#pragma warning(

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

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

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

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

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

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

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

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