Сбой сборки Visual Studio: невозможно скопировать exe-файл из obj\debug в bin\debug
Обновление: пример проекта, воспроизводящего эту ошибку, можно найти здесь, в 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, и если да, то есть ли патч? Или я сделал что-то не так, есть ли у меня круговая ссылка или что-то подобное, и если да, то как я могу узнать?
Любые предложения высоко ценятся:)
Обновление: Как упоминалось в комментарии ниже, я также проверил с помощью Process Explorer, что это на самом деле Visual Studio, которая блокирует файл.
36 ответов
Это будет звучать глупо, но я попробовал все эти решения, используя 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). Однако мне не разрешено удалять файл самостоятельно, и я должен сказать, что нахожу это немного странным, поскольку можно было бы полагать, что та же самая блокировка, предотвращающая удаление, также предотвратит переименование...). Это не очень хорошее решение, но оно достаточно быстрое (по крайней мере, после того, как вы сделали это пару раз, оно почти становится рутиной) и, по крайней мере, намного быстрее, чем перезапуск Visual Studio, что я и делал в начале.
В случае, если кто-то задается вопросом, я также могу добавить, что я вижу эту проблему только случайно. Обычно это происходит после того, как я сделал некоторые изменения в режиме дизайна формы (но не всегда). Обычно этого не происходит, если я только изменяю код бизнес-логики или невизуальный код (но иногда это происходит...). Разочарование действительно, но по крайней мере у меня есть взлом, который работает для меня - давайте просто надеяться, что мой следующий проект также не столкнется с этой проблемой...
@ Барри: если вы хотите получить кредит за ваш комментарий, пожалуйста, не стесняйтесь опубликовать его в качестве ответа, и я обязательно приму его:)
Я нашел одно простое решение, просто отключите службы индексирования Windows для папки и подпапок проекта
У меня та же проблема (MSB3021) с проектом WPF в VS2008 (на Windows 7 x32). Проблема появляется, если я пытаюсь перезапустить приложение слишком быстро после предыдущего запуска. Через несколько минут exe-файл разблокирован сам по себе, и я снова могу запустить приложение. Но такая долгая пауза злит меня.Единственное, что действительно помогло мне, это запустить VS от имени администратора.
Когда я сталкиваюсь с этой проблемой, это связано с тем фактом, что проект, который я пытаюсь построить, устанавливается как проект запуска в решении, делающем заблокированный EXE-файл в папке obj (он также появляется в вашем диспетчере задач). щелкните правой кнопкой мыши другой проект в вашем решении и выберите "Установить стартовый проект". Это снимет блокировку, удалит ее из диспетчера задач и позволит вам построить.
Я попробовал все другие предложения в ответах здесь, ни один из которых не работал. В конце концов я использовал Process Monitor, чтобы обнаружить, что мой.exe, который не удалось собрать VS2010, был заблокирован системным процессом (PID=4). Поиск SO для ситуаций, связанных с этим, дал этот ответ.
Подведем итог: если у вас отключена служба Application Experience (как я), то включите ее снова и запустите. Два года обострения закончились.
У меня также была проблема, очень похожая на эту, и я обнаружил, что причина в моем случае заключалась в том, что я сделал папку bin\debug доступной как общую папку под VMware и либо VMware, Explorer под гостевой виртуальной машиной, либо, возможно, даже антивирус Программа под гостем (хотя я не думаю, что у меня была установлена) держала дескриптор файла (ов).
ЕСЛИ ВАША ПРОБЛЕМА НЕ РЕШАЕТСЯ:
Ошибка Visual Studio:
"Процесс не может получить доступ к файлу" bin\Debug**app.exe** ", так как он используется другим процессом".
Итак, зайдите в диспетчер задач Windows(Ctrl+Shift+Esc), найдите имя вашего приложения и принудительно закройте его с помощью Endprocces.
Используя 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
Я бы предложил скачать Process Explorer чтобы точно узнать, какой процесс блокирует файл. Его можно найти по адресу:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Вот еще одна возможность:
После получения этой ошибки в vs2012 / win7 я пошел и попытался удалить файл в каталоге bin, а проводник указал, что файл использовался конструктором пользовательского интерфейса XAML.
Я закрыл все вкладки, открытые в VS, закрыл VS, а затем убил все процессы MSBuild в диспетчере задач. Наконец, после перезапуска VS я смог построить решение.
и еще одна возможная причина:
Я заметил еще одну возможную причину этой проблемы. После некоторого рефакторинга кода, перемещения проектов в решение и из него ссылки на мои проекты перестали ссылаться на проекты в решении, как ожидалось.
Это вводит в заблуждение визуальную студию, полагая, что она может создавать несколько проектов одновременно, создавая тем самым блокировки файлов.
РЕДАКТИРОВАТЬ: у меня это случалось несколько раз, даже недавно с VS2012, и он исправляет это, как только я устанавливаю порядок сборки на правильные зависимости, убиваю все процессы msbuild, которые VS оставил работающими, и затем перезапускаю VS. Я просто убиваю процессы msbuild, но закрытие VS также должно их убить.
Я обычно делаю так, чтобы это был рефакторинг проекта таким образом, чтобы он опирался на другой проект внутри решения, на который он не ссылался в прошлой сборке. Иногда кажется, что это сбивает с толку VS и не обновляет порядок сборки.
Чтобы проверить порядок сборки: Щелкните правой кнопкой мыши Решение в обозревателе решений и выберите "Порядок сборки проекта..." и убедитесь, что зависимости правильно указаны для каждого проекта.
Перезапустите IIS- это может быть процесс, связанный с отладчиком
Отключите антивирус и попробуйте. Я также столкнулся с этой проблемой... но в моем случае антивирус блокировал мое приложение, когда я отключил антивирус, он разрешился.
Я столкнулся с той же ошибкой.
Я решил проблему, удалив все содержимое папок bin всех зависимых проектов / библиотек.
Эта ошибка в основном происходит из-за изменения версии.
Это было зарегистрировано несколько раз на Connect, сайте сообщества по сообщению об ошибках Microsoft. К вашему сведению, я считаю, что эта ошибка затрагивала Visual Studio с 2003 года и каждый раз исправлялась после RTM.:(Одна из ссылок выглядит следующим образом:
Это довольно часто вызывается Avast.
Я обычно могу запускать свои проекты в Release независимо, но при запуске в режиме отладки он довольно часто терпит неудачу.
Я просто добавляю исключение для моей папки проектов, и проблема, похоже, исчезнет. Я предполагаю, что это также может быть вызвано другими антивирусами.
Для меня это было вызвано открытием командной строки в целевой папке (C:\users\username\source\repos\project\project\bin\debug\app.publish).
Не уверен, почему для отладки требуется доступ к папке публикации, но закрытие окна командной строки решило проблему для меня.
Если ничего из вышеперечисленного не работает, и вы разрабатываете консольное приложение:
Попробуйте ввести любой символ в Program.cs, а затем удалите его. Я понятия не имею, почему это работает, но, похоже, это решает проблему "Невозможно скопировать" каждый раз.
Переименование файлов.exe и.pub работало для меня, но действительно утомительно. Я также сталкиваюсь с проблемой, что я не мог сделать редактирование во время сеанса отладки. Наконец, я перешел на страницу "Дополнительные параметры безопасности" в соответствии с:
Я отменяю выбор, затем повторно устанавливаю флажок "Включить настройки безопасности ClickOnce". Уже несколько дней это без проблем...
Сначала делай простые вещи.
Убедитесь, что часть вашего решения не заблокирована запущенным процессом.
Например, я запустил "InstallUtil" в моей службе Windows (которую я обычно тестирую с консоли).
Это заблокировало некоторые из моих библиотек в папке 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 часов на отладку этого и, наконец, нашел решение самостоятельно.
Это правильный ответ.
В случае, если кто-то сталкивается с этим при попытке отладки юнит-теста или запуска юнит-теста, мне пришлось убить следующие два процесса, чтобы он освободил файл:
- Установить другой проект в качестве запуска
- Постройте проект (отобразится не проблемный проект)
- Перейти к проблемному
bin\debugпапка - переименовывать
myservice.vshost.exeвmyservice.exe
Когда я столкнулся с подобной проблемой, единственное, что, казалось, работало, было:
- Щелкните правой кнопкой мыши по проекту, перейдите в "Настройки" и убедитесь, что сборки "Отладка" и "Выпуск" предназначены для одних и тех же настроек или содержат настройки, которые приложение пытается загрузить или сохранить.
- Удаление папки C:\Users(YourUserAccount)\AppData\Local(YourAppName).
- Убедиться, что никакие файлы, которые у меня были там, не считаются заблокированными. Щелкнув правой кнопкой мыши по файлам моего проекта, я понял, что одна иконка на самом деле заблокирована и считается плохой, потому что она была загружена из Интернета. Мне пришлось нажать кнопку "Разблокировать" (например, проверьте это: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Этот файл пришел с другого компьютера и может быть заблокирован, чтобы помочь защитить этот компьютер.")
У меня была одна и та же проблема несколько раз, но два разных подхода помогли в сочетании. Во всех случаях интересен один факт, а именно то, что вы все равно можете переименовать файл. Если файл открыт процессом, его невозможно переименовать. Так что это должно быть что-то другое, чем простой дескриптор открытого файла.
- При компиляции решения, создающего IL-код, Защитник полностью заблокировал его, даже если оно содержало всего несколько команд. Даже добавление каталога в список исключений Защитника Windows не помогло. Я думаю, что антивирусная проверка Защитника Windows имеет недостаток и переходит в бесконечный цикл (или сбой?), если файл имеет определенное незавершенное состояние и блокирует файл. Но он никогда не восстанавливается, кроме как после перезагрузки ПК.
- У меня была ошибка отсутствия доступа после того, как мне пришлось убить свое решение во время отладки, потому что кнопка остановки отладчика не работала, или, может быть, также при обычной остановке с помощью кнопки остановки, я больше не могу вспомнить. Некоторые dll, казалось, оставались заблокированными, их невозможно было удалить, но я мог их переименовать (??). Затем я использовал «tasklist.exe», чтобы перечислить все процессы, и, к моему удивлению, в списке все еще был процесс с именем моего приложения. Без окна. И диспетчер задач не указал его в «Подробностях». Странный. Я мог использовать taskkill /PID:... /F (/F был необходим), и процесс пошел. После этого компиляция прошла успешно, и все вернулось в норму. Похоже, что этот exe хранил библиотеки DLL, но странным образом.
Это также происходило гораздо чаще, когда также работал Oracle VirtualBox. Не знаю, влияет ли это. Также может быть связано с исключениями «Недостаточно памяти», о которых иногда сообщается, когда VirtualBox потребляет много памяти.
Теперь я использую оба подхода вместе всякий раз, когда возникает проблема. И до сих пор время от времени случается.
Мое решение не имеет ничего общего с версиями, процессами, заблокированными, перезапуском или удалением файлов.
Проблема была на самом деле из-за сбоя сборки и неправильной ошибки. Актуальной проблемой был недостаток дизайна:
// 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", поскольку он не был найден,
Это помогает мне после того, как я удаляю флаг только для чтения из каталога bin. http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name
Повторное включение службы Application Experience в Windows устранило такие проблемы для меня.
Смотрите следующие ссылки:
- Разрешения выходного файла Visual Studio?
- При каких обстоятельствах системный процесс (PID 4) сохраняет дескриптор открытого файла?
У меня была проблема с использованием Visual Studio 2008, 2010 и 2013 с Windows 7 64-битной.
Ни один из других ответов не помог мне, но закрытие всех открытых вкладок в Visual Studio, похоже, решило проблему.