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


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

2
У меня было это раньше, и я просто переименовал файл в .old и т. Д. И перезапустил сборку. Не совсем то, что я знаю, но у меня это сработало.
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 05

Ответы:


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
Шарик,

6
fyi ... это не сработало для меня. Мои настройки всегда были
такими

4
Если в настоящее время у вас есть [assembly: AssemblyVersion ("1.0.0.0")], замените его на [assembly: AssemblyVersion ("2.0.0.0")] (т.е. «2» вместо «1»). У меня это сработало. Хотя я не проверял, возможно, что простое изменение версии на любую другую, кроме той, что у вас есть сейчас, может решить эту проблему.
Фредерик Дурак

1
Работает и для dll! VS говорит, что не может скопировать dll, и после изменения ОБЕИХ [assembly: AssemblyVersion] и [assembly: AssemblyFileVersion ()] с 1.0. * На 2.0.0.0 это сработало.
АЗ.

14

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

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

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

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


Я проголосовал за это, потому что это то, что я делал в прошлом. Я согласен, это грязное решение, но оно работает. В VS эта проблема возникала несколько раз. Я также загружаю свой проект из сетевого каталога. Ему полностью доверяют, но это не имеет значения. Неважно, отображение дисков или UNC. Да, MS действительно нужно это исправить. У них есть закрытая ошибка, говорящая о невозможности воспроизведения. Ламе!
Джош Робинсон

14

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


2
Это сработало и для меня. Я не уверен, что понимаю, почему, как показал проводник процессов, devenv.exe держал дескриптор блокировки. Тем не менее, отключение индексации устранило проблему.
Fopedush

1
@Fopedush Я столкнулся с этой проблемой с тем же решением, хотя в то время я не видел этого вопроса. В этом ответе есть объяснение, почему это помогает.
Даррен Хейл

1
Этот сделал это за меня.
Мартин Каподичи,

12

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


1
Я нашел этот недавний отчет об ошибке, касающийся именно этой проблемы: connect.microsoft.com/VisualStudio/feedback/details/558848/… В этом отчете об ошибке был представлен образец проекта, в котором удалось воспроизвести ошибку. Решение, предложенное drharris, также работало там (см. Обходной путь, опубликованный в приведенной выше ссылке, для получения пошагового решения для примера проекта).
Julian

Это единственное решение, которое сработало и для меня. Спасибо, @Nailuj!
Winger

Это наверняка проще, чем перезапуск VS.
Эльведин Хамзагич 05

1
«Страница не найдена» для проблемы с подключением, они просто удалили ее из-за смущения = S Было ли когда-либо опубликовано решение / обходной путь для этого?
Coops

9

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


1
У меня это работает каждый раз. Похоже, это связано с процессом vshost, который генерируется и запускается для сервисов
jaywayco

8

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

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


+1 Раньше я пробовал все остальное (1. диспетчер задач, 2. обозреватель процессов, т.е. закрыть дескриптор, который мне не разрешали окна, 3. Отключение антивируса, 4. исключение APP_DATA / Local / Microsoft / Visual Studio из службы индексирования Windows. ), но вот этот совет: служба "Application Experience" - единственная, которая спасла меня, когда я бился головой об стену. Я включил его, и проблема исчезла. Забавно, но после того, как я снова отключил его, все было по-прежнему в порядке. У меня больше не было проблем. Но определенно это единственное, что меня решило.
Tomás

Работай и у меня !!! Единственное, что также работает, - это удалить папку bin перед запуском приложения, но вы должны удалять всегда перед запуском, что очень раздражает.
E_Blue

6

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


У меня установлен Avast, и сегодня утром я получил случайную ошибку MVC, в которой говорилось, что в моей DLL был вирус. После ошибки я больше не мог создавать свой проект MVC. Я добавил исключение в Avast File System Shield, и все снова работает.
Дасти


4

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

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


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

Извините, я забыл упомянуть, что уже сделал это. В нем говорится, что это 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/…
Julian,

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

4

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

Ошибка Visual Studio:

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

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


3

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

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

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


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

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

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

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

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

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


Мы недавно испытали это на проекте WinPhone 8. Необъяснимым образом причина заключалась в использовании типа Tuple. Удаление кода, который использовал кортеж, проблема исчезла. Добавьте код обратно, чтобы вернуть проблему.
Seamus

У меня была такая же проблема с VS2012, закрытие VS не помогло
мне

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

3

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


3

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


3

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

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

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


2

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


1

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

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

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

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

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

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

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


1

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

Когда я создаю веб-проект, я обнаружил, что все мои DLL находятся в папке bin, а не в bin \ debug. Во время публикации vs искал файлы в bin \ debug. Итак, я открыл файл веб-проекта в редакторе и поискал экземпляры bin \ debug, и я обнаружил, что все dll были упомянуты как bin \ debug \ mylibrary.dll. Я удалил все \ debug из пути и снова опубликовал. На этот раз 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;k%28TargetFramework%3 % 3dV4.0% 22% 29 & rd = true

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


1

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

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


1

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

процессы убить.


0

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

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

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


0

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


0

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

После долгих исследований выяснилось, что в одном из моих файлов было неполное предупреждение прагмы, которое не препятствовало успешной компиляции, но каким-то образом сбивало 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(); 

После изменения области действия «а» за пределы функции или отказа от использования «а» после 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 я регулярно получаю эту ошибку. Что-то, что, кажется, работает достаточно хорошо, - это выполнить Rebuild Solution перед попыткой запустить приложение. Я обнаружил, что выполнение CLEAN иногда работает, но Rebuild Solution работает более стабильно.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.