Невозможно скопировать файл - доступ к пути запрещен

Сначала перейдите в расположение файла. Затем щелкните правой кнопкой мыши папку с файлом -> Свойства -> Не отмечен флажок только для чтения и примените к файлам и их подпапкам. Это решило мою проблему. Удачного кодирования!

Это снова подняло голову в Visual Studio 2017, в данном случае причиной является процесс Application Insights ServiceHub.DataWarehouseHost.exe.

Обходной путь обсуждается в ветке предупреждение MSB3026: не удалось скопировать «obj \ Debug \ netcoreapp1.1 \ src.pdb» в «bin \ Debug \ netcoreapp1.1 \ src.pdb», то есть добавить событие предварительной сборки в проект в убивайте процесс каждый раз при построении проекта. Цитата из этой ссылки:

• Щелкните правой кнопкой мыши свойства в проекте
• Выбрать свойства
• Сборка событий
• Командная строка события перед сборкой

taskkill /IM ServiceHub.DataWarehouseHost.exe /F 2>nul 1>nul
Exit 0

• Сохранить и построить

Может ли кто-нибудь знать, почему возникает эта проблема?

Глядя на ваш ответ о том, что вы решили проблему путем ручного копирования, я бы сказал, что код, над которым вы работали, был создан другим пользователем (также с правами администратора), поэтому он был заблокирован для вас. Выполняя копирование -? paste, вы сделали свою СОБСТВЕННУЮ копию источника со всеми необходимыми правами доступа. Единственное, на что следует обратить внимание, это то, что в этом случае, если этому другому разработчику нужно будет поработать над вашей копией, он / она столкнется с той же проблемой, что и вы раньше.

Старый пост, но этот зомби попадает в VS 2017 (я не вникал, почему это просто «некоторые» проекты). В данном случае это не разрешения пользователя, а скорее процесс IIS Express по-прежнему использует файлы.

Вы увидите значок на панели задач

1. Щелкните правой кнопкой мыши
2. Выход
3. Вы должны иметь возможность rebuild без этого раздражающего сообщения «В разрешении отказано».

По этой же причине «перезапуск Visual Studio» «решит» проблему. При этом IIS Express останавливается.

Hth ...

Я повторно добавил все мои зависимости / ссылки, не относящиеся к .NET, и это помогло.

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

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

Я справился с этим, установив Unlocker (< em> пытается установить любую панель инструментов при установке, поэтому не забудьте снять этот флажок), это приложение дает мне быстрый доступ для переименования / удаления заблокированного файла ".xml". Я знаю, что это тоже всего лишь обходной путь, но для меня это было самое быстрое решение этой проблемы.

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

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

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

У меня была та же ошибка, но я использую контроль версий Perforce. Вот как я это исправил.

1. Закрытый клиент Perforce P4V
2. Перезапустил Visual Studio 2010 (может не понадобиться)
3. Перестроил проект, что получилось
4. Чувствовал себя одновременно исключительно счастливым и испытывал отвращение

У меня тоже была такая же проблема. Я получил сообщения об ошибках, связанные с невозможностью копирования, поскольку доступ к пути запрещен. В моем случае все мои файлы dll, xml и так далее находятся в папке D: \ TFS \ Example \ Bin \ Debug.

Я щелкнул правой кнопкой мыши папку Bin, выбрал «Свойства» и увидел, что в разделе «Атрибуты» установлен флажок «Только для чтения».

Я снял флажок «Только для чтения», щелкнул «Применить» и щелкнул «ОК» в появившемся всплывающем окне.

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

Вуаля .. На этот раз сборка прошла успешно, без ошибок.

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

Проверьте диспетчер задач и убедитесь, что у вас не зависает процесс devenv.exe. Завершите процесс убегания и попробуйте еще раз.

Перейдите по пути к файлу и снимите флажок только для чтения для этого файла.

Большинство ответов, которые я видел, объективно исследуют возможные проблемы со средой, что, вероятно, верно для 99% людей, столкнувшихся с этой проблемой (невозможно скопировать файл из ... в ... доступ запрещен).

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

Я написал программу пакетного переименования файлов, которую использую для обработки десятков тысяч файлов, и мой Антивирус интерпретировал ее как троян и автоматически поместил в карантин. Поскольку этот путь находится в черном списке моего Антивируса, Visual Studio никогда не сможет скопировать * .exe в папку bin, что приведет к невозможности скопировать .exe.

Я решил внести этот путь в белый список, и проблема решена.

Ваше здоровье.

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

Просто щелкните правой кнопкой мыши свой проект MVC и выберите вариант очистки. У меня была аналогичная проблема, и очистка проекта перед восстановлением решила ее для меня.

У меня тоже была такая же проблема. Я исправил это, сняв флажок "Только для чтения" корневой папки.

У меня тоже была эта проблема. Вот как решается это

• Исключить папку bin из проекта.
• Закройте визуальную студию.
• Очистка диска C.
• Повторно откройте проект в Visual Studio.
• А затем восстановите решение.
• Запустить проект.

Этот процесс работает для меня.

В Visual Studio 2015 у меня сработало изменение пути вывода. Это должно помочь - Каталог вывода сборки

Мне удалось решить проблему, удалив целевой файл, который жалуется (в вашем примере «Bin \ Debug \ test.Resources.xml»), из папки bin целевого веб-сайта и перестроил его. Это исправило это для меня.

1) закройте решение Visual Studio

2) перейдите в командную строку -> запустить от имени администратора -> iisreset / stop

3) перейдите в c -> Windows -> Microsoft.Net -> Framework64 -> v4.030319 -> Temporary Asp.NET Files -> Удалите все файлы и папки в этот путь.

4) Вернитесь в командную строку -> iisreset / start.

5) Теперь откройте визуальную студию -> запустите от имени администратора -> очистите решение и создайте его (не перестраивайте ... просто сборка сработала для меня)

У меня была такая же проблема. Чтобы решить эту проблему, я проверил / сделал несколько вещей.

Что не сработало

1) Read/write permissions were given to directory 
2) Restarted visual studio
3) Tried deleting visual studio temp files

Что в итоге сработало

Просто вставьте команду, данную Фредом Моррисоном, в «Консоль диспетчера пакетов»:

Get-Process | Where-Object -Property Name -EQ 'VBCSCompiler' | Stop-Process -Force -Verbose

Примечание. Просто наблюдение. Перезапуск Visual Studio может не работать в этом случае, но перезапуск системы может, потому что остановка процесса "VBCSCompiler" была решением, поэтому мы можем сделать это в любом случае.

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

Я предлагаю вместо использования Environment.CurrectDirectory (который, как я предполагаю, вы используете в настоящее время) вы создаете папку с именем «MyProjectName» в адресе% appdata%, а затем используйте:

System.IO.Path.Combine(Environment.GetEnvironmentVariable("appdata"),"YourProjectName").

Итак, я столкнулся с той же проблемой, причиной которой была моя, у меня была общая папка разработки, поэтому я мог использовать Mac в качестве узла сборки для приложения IOS с использованием Xamarin. Проект был запущен на Mac, который стал владельцем библиотеки dll, поэтому я не мог вносить изменения в эту dll из любого другого места. Простая остановка приложения на Mac вернула мне право собственности, что снова позволило получить полный доступ. Я надеюсь это получится с тех пор.

Очистите все библиотеки, на которые есть ссылки, в «bin \ debug» и щелкните правой кнопкой мыши «Решение» в проводнике решений после нажатия «Очистить решение».

И восстановите !!

Я сталкивался с этой проблемой несколько раз, и решение, которое я нашел, - это удалить папку отладки, а затем перестроить ваше решение / проект. Сработало у меня !!

Убедитесь, что вы добавили имя файла после имени пути (путь \ имя_файла.расширение). Я не замечал этого больше часа.

Это может быть странным побочным продуктом первоначальной загрузки исходного кода из системы управления версиями (TFS и т. Д.), Где все файлы и папки защищены от записи. Перейдите в каталог верхнего уровня и проверьте свойства. Вы можете обнаружить, что установлен флажок Только для чтения. Снимите этот флажок, и система спросит вас, хотите ли вы, чтобы все каталоги на верхнем уровне были доступны для записи. Это должно исправить.

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

В моем случае я перенес проект из Windows в OSX, используя Visual Studio Community 7.1.5 для Mac. Какая уловка заключалась в отключении опции Use MSBuild engine (recommended for this type of project) в настройках проекта:

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

Ручное копирование последней зарегистрированной версии .dll из другой папки bin проекта в папку bin в проекте, в котором возникла ошибка, устранило проблему.

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

Я перепробовал все здесь, каким-то образом удаление всех папок bin и obj в моем проекте не сработало. Освобождение папок из других процессов ничего не дало. Перезапуск ничего не сделал. Удаление только для чтения из каждого файла путем снятия флажка в основной папке не помогло.

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

Вы знаете, что сработало?

dotnet clean

попробовав почти все, просто скопируйте, вставил проект в другое место и построил проект ... и это сработало.

Моя началась после установки Центра обновления Windows KB5003637. Мой проект VS2019 раньше работал нормально, но после установки Центра обновления Windows возникла эта ошибка. Удалил его, и проект снова работает.

Простое решение:

Просто обновите следующие пакеты

Microsoft.CodeDom.Providers.DotNetCompilerPlatform v1.0.5 to v1.0.7

Это решит проблему.

Если кому-то нужно дополнительное простое решение, прежде чем пробовать что-то еще.

Просто перезагрузите компьютер. Откройте Visual Studio, попробуйте снова собрать.