Nie można skopiować pliku - odmowa dostępu do ścieżki


238

Korzystam z programu Visual Studio 2005. Po pobraniu kodu z kontroli wersji aplikacja c # .net działa poprawnie. Ale po wprowadzeniu pewnych modyfikacji po kompilacji pojawia się następujący błąd:

Błąd 383 Nie można skopiować pliku „.. \ root \ leaf \ Bin \ Debug \ test.Resources.xml” do „Bin \ Debug \ test.Resources.xml”. Odmowa dostępu do ścieżki „Bin \ Debug \ test.Resources.xml”. li.rollmodel

Czy ktoś wie, dlaczego występuje ten problem?

Edycja Widzę, że cały folder kodu źródłowego projektu jest tylko do odczytu i nie jestem w stanie usunąć właściwości tylko do odczytu.

Po pierwsze, czy ktoś może mi powiedzieć, jak usunąć właściwość Tylko do odczytu dla tego folderu? Próbowałem go usunąć, ale właściwość tylko do odczytu nadal występuje. Próbowałem też od strony kontroli wersji i to też nie działało.


Czy to jest udział sieciowy? Czy masz dostęp administracyjny do swojego komputera? To pytanie może lepiej pasować do błędu serwera lub administratora.
arunkumar,

nie ,, korzystam z własnego komputera mam dostęp administracyjny
ricky,

Rozwiązałem ten problem, ręcznie kopiując plik z jednej lokalizacji do wymaganej lokalizacji, prawdopodobnie problem związany jest z MSBUILD z plikiem tylko do odczytu
ricky,

Odpowiedzi:


277

Rozwiązałem ten problem, usuwając sporne pliki z folderu bin i odbudowując projekt.


50
stary post, wiem, ale miałem teraz ten sam problem. Upewnij się, że VS jest również zamknięty, ponieważ w niektórych przypadkach odmówi dostępu do usunięcia folderu
Eon

1
Mała uwaga: na początku nie rozumiałem, że muszę usunąć te pliki w folderze wyjściowym głównego projektu, a nie w folderze wyjściowym dll. Ostrzegam tutaj :)
Piero Alberto

6
W moim przypadku nawet zamknięcie VS nie wystarczyło, aby zwolnić folder i pozwolić mi go usunąć - ProcessExplorer pokazał, że „VBCSCompiler.exe” nadal go używa. W tym przypadku wylogowanie się z systemu Windows (lub po prostu zabicie procesu) załatwiło sprawę, pozwalając mi na przebudowanie rozwiązania i przywrócenie wszystkiego do działania.
S. Jensen,

2
w moim przypadku przyczyną, dla której folder i rozwiązanie zmieniły się w ReadOnly, a następnie VS miał problem z jego zbudowaniem, było to, że niektóre pliki nie zsynchronizowały się z GoogleDrive i zostały w jakiś sposób zablokowane przez ten proces. Tak więc, aby poprawnie przebudować, musiałem zamknąć GoogleDrive, a potem wszystko poszło dobrze.
konrad

1
Uważam, że winowajcą jest Bitdefender Antivirus Free.
Warwick,

123

Tylko upewnij się, że folder NIE jest tylko do odczytu i odbuduj rozwiązanie


12
Próbuję usunąć pole wyboru „Tylko do odczytu” wypełnione kolorem zielonym. Kiedy kliknę „Zastosuj”, a następnie „Ok”, a następnie ponownie sprawdzę właściwości tego folderu, ponownie widzę w poprzednim stanie (ponownie mając pole wyboru „Tylko do odczytu” wypełnione kolorem zielonym). Czy ktoś ma na to rozwiązanie?
Vikram

Upewnij się również, że plik nie jest zablokowany. W moim przypadku plik był udostępniony i ktoś inny go otworzył.
Dan Bechard

Zamknij Visual Studio przed usunięciem atrybutu tylko do odczytu. Ponieważ dany plik może być używany (zablokowany)
Gautam Jain,

4
Utworzono rozszerzenie Visual Studio do czyszczenia atrybutu ReadOnly i Hidden bibliotek dll, które blokują kompilację. UnBlockDllExtension: marketplace.visualstudio.com/…
vrnithinkumar

69

Rozwiązałem ten problem: zamknij Visual Studio, otwórz go ponownie i załaduj rozwiązanie, przebuduj swoje rozwiązanie. Mój problem wystąpił podczas korzystania z TFS i VIsual Studio 2010.


22
Dodaj ten sam problem w VS2013. Klasyczna obudowa The IT Crowd. „Cześć, to jest IT, czy próbowałeś to wyłączyć i włączyć ponownie?”.
Maxime Rouiller,

1
Ten sam scenariusz: TFS i VS 2010. Ten sam problem. To samo rozwiązanie. +1
ajeh 12.04.16

2
Stało się to również w VS2015: p
Yoo Matsuo

4
I to samo w VS2017
arame3333

1
Już zwariowałem, próbując to naprawić, okazałem się dobrą starą metodą, jeśli coś nie działa, uruchom ponownie, działa dobrze
Mykhailo Seniutovych

50

Zabij proces VBCSCompiler.exei odbuduj.


3
To właśnie dla mnie to rozwiązało. Dziękuję miły nieznajomy: D
Morsus 10.10.17

tak, to jest to.
kal kokah

Dziękuję bardzo, uprzejmy nieznajomy! : D
Agent007

czasami to zadziałało dla mnie nie zawsze, muszę powiedzieć, że rozwiąże część tego problemu, jest też coś innego, co powoduje ten problem
Amit Bisht

Wypróbuj to również może pomóc Ci stackoverflow.com/a/12740768/2445111
Amit Bisht

23

Włączyłem się również w ten problem.

Najpierw sprawdź i sprawdź, czy folder bin i obj został zmapowany do programu kontroli źródła.

Może to oznaczać przekształcenie plików z folderów binarnych w archiwa tylko do odczytu, co uniemożliwia Visual Studio nadpisanie ich podczas kompilacji kodu.

Idź i usuń mapowanie z tych folderów, sprawdź zmiany i spróbuj ponownie.

Mój problem wystąpił przy użyciu TFS (serwer fundacji zespołu) i programu Visual Studio 2010.

Mam nadzieję, że to komuś pomoże.


1
Chciałem tylko dodać, że odpowiedź Heitorolecarte rozwiązała mój problem i może to wystąpić w Visual Studio 2012 i TFS2010.
Rodney

20

Uruchom program Visual Studio jako administrator


1
Uwaga: oto krótki i prosty sposób, aby zawsze domyślnie uruchamiać się jako administrator stackoverflow.com/questions/12257110/…
wmebane

Ta odpowiedź powiedziała mi wystarczająco, że wiedziałem, aby po prostu dodać uprawnienia do zapisu do „Użytkowników” w moim folderze wyjściowym - i to natychmiast rozwiązało mój problem (który polegał na tym, że nie mogłem opublikować nawet za pierwszym razem).
X Goodrich

9

Używam Visual Studio 2013. Napotkałem ten problem 2 razy:

  1. Za pierwszym razem uruchomiłem Visual Studio bez uprawnień administratora. Więc zamknąłem VS i uruchomiłem go za pomocą opcji „ Uruchom jako administrator ”. To rozwiązało mój problem.

  2. Za drugim razem wielokrotnie restartowałem VS, za każdym razem upewniając się, że działam jako administrator. Ponadto wielokrotnie przebudowywałem rozwiązanie. Mimo to dostałem błąd. Następnie usunąłem dany plik z lokalizacji docelowej (plik był już obecny, może pochodzić z poprzedniej kompilacji w lokalizacji, w której próbuje się skopiować) i przebudowałem rozwiązanie . Potem błąd zniknął i wszystko poszło gładko!



7

Wróciło to ponownie do głowy w Visual Studio 2017, w tym przypadku przyczyną jest proces Application Insights ServiceHub.DataWarehouseHost.exe.

W ostrzeżeniu o wątku MSB3026 omówiono obejście : Nie można skopiować „obj \ Debug \ netcoreapp1.1 \ src.pdb” do „bin \ Debug \ netcoreapp1.1 \ src.pdb” , aby dodać wersję wstępną zdarzenie w projekcie, aby zabić proces za każdym razem, gdy projekt jest budowany. Cytowanie z tego linku:

  • Kliknij prawym przyciskiem myszy właściwości w projekcie
  • Wybierz właściwości
  • Twórz wydarzenia
  • Wiersz polecenia zdarzenia przed kompilacją
taskkill /IM ServiceHub.DataWarehouseHost.exe /F 2>nul 1>nul
Exit 0
  • Zapisz i buduj

6

Czy ktokolwiek może wiedzieć, dlaczego ten problem nadchodzi?

Patrząc na twoją odpowiedź, że rozwiązałeś problem przez ręczne kopiowanie, powiedziałbym, że kod, nad którym pracowałeś, został stworzony przez innego użytkownika (również z uprawnieniami administratora), więc został dla ciebie zablokowany. Wykonując kopię -? wklej, utworzyłeś własną kopię źródła ze wszystkimi wymaganymi prawami dostępu. Jedyną rzeczą do zauważenia jest to, że w tym przypadku, jeśli ten inny programista będzie musiał pracować nad twoją kopią, on / ona wskoczy w taki sam problem, jak wcześniej.


6

Najpierw przejdź do lokalizacji pliku. Następnie kliknij prawym przyciskiem myszy folder pliku -> Właściwości -> Odznaczona opcja tylko do odczytu i zastosuj do plików i jego podfolderów. Rozwiązało to mój problem. Happy Coding!


3

Ponownie dodałem wszystkie moje zależności / referencje inne niż .NET i załatwiłem sprawę.


3

Sam rozwiązałem ten problem. Problem polegał na tym, że otworzyłem rozwiązanie w innym miejscu. Po zamknięciu działa


Ja też to zrobiłem. Zawsze najpierw sprawdzaj oczywiste łatwe rzeczy, moje miejsce docelowe znajdowało się na dysku sieciowym, ponieważ debugowałem na innym komputerze.
Simon Unsworth

3

Miałem ten sam problem, ale ponowne uruchomienie programu Visual Studio za każdym razem nie było dla mnie opcją , ponieważ problem występuje czasami bardzo często.

Poradziłem sobie z tym, instalując Unlocker ( próbuje zainstalować dowolny pasek narzędzi podczas instalacji, więc nie zapomnij odznaczyć tego ), ta aplikacja daje mi szybki dostęp do zmiany nazwy / usunięcia zablokowanego pliku „.xml” . Wiem, że to tylko obejście, ale dla mnie było to najszybsze rozwiązanie tego problemu.


Dzięki za to. Miałem ten problem przez ostatni rok i myślałem, że to dlatego, że przełączałem się między Administratorem a nie, ale teraz wiem, że jest to głupi proces krytyczny związany z Panda Antivirus (PSANHost.exe, nieobecny w Menedżerze zadań), który zablokował pliki.
yeejuto,

3

Stary post, ale ten zombie uderza VS 2017 (nie zastanawiałem się, dlaczego to tylko „niektóre” projekty). W tym przypadku nie są to uprawnienia użytkownika , a raczej proces IIS Express nadal korzysta z plików.

Zobaczysz ikonę na pasku zadań Ikona IIS Express

  1. Kliknij prawym przyciskiem myszy
  2. Wyjście
  3. Powinieneś być w stanie rebuildbez tej irytującej wiadomości „odmowa zgody”.

Z tego powodu „ponowne uruchomienie programu Visual Studio” naprawi problem. W ten sposób zatrzymuje IIS Express.

Hth ...


2

Stworzyłem ten problem, kiedy dodałem nowy projekt instalacyjny do rozwiązania, a następnie dodałem pliki bezpośrednio z folderu / bin / release głównego projektu aplikacji do folderu plików aplikacji projektu instalacyjnego. Kontrola źródła projektu instalacyjnego konsekwentnie blokowała mnie przed ukończeniem kompilacji projektu głównego aplikacji.

Rozwiązanie: utwórz osobny folder zrzutu poza dowolnym projektem, który będzie zawierał wszystkie pliki, które mają zostać uwzględnione w instalacji, i dodaj je stamtąd. To bolesne, ponieważ teraz muszę pamiętać, aby skopiować wszystkie pliki dla każdego nowego pakietu instalacyjnego. Mogę zobaczyć, czy mogę coś zrobić z działaniami po kompilacji, naszą automatyczną kompilacją, aby proces był płynniejszy.


2

Jeśli skopiujesz jakieś pliki do rozwiązania, upewnij się, że pliki nie są w trybie tylko do odczytu. Kliknij plik prawym przyciskiem myszy i odznacz opcję atrybutu, aby rozwiązać mój problem.


2

Miałem ten sam błąd, ale używam kontroli wersji Perforce . Oto jak to naprawiłem.

  1. Zamknięty klient Perforce P4V
  2. Uruchomiono ponownie Visual Studio 2010 (może nie być konieczne)
  3. Odbudowano projekt, który się powiódł
  4. Czułem się wyjątkowo szczęśliwy i jednocześnie oburzony

1
Mam taką samą konfigurację, ale nie mogłem przejść do kroków 3 i 4 :(
user3260977,

2

Też miałem ten sam problem. Otrzymałem komunikaty o błędach, których nie można skopiować, ponieważ odmówiono dostępu do ścieżki. W moim przypadku wszystkie moje pliki dll i xml i tak dalej znajdują się w folderze D: \ TFS \ Example \ Bin \ Debug.

Kliknąłem prawym przyciskiem myszy folder Bin, kliknąłem Właściwości i zobaczyłem, że pole wyboru Tylko do odczytu jest zaznaczone w obszarze Atrybuty.

Nie zaznaczyłem pola wyboru Tylko do odczytu, kliknąłem Zastosuj i kliknąłem OK w wyświetlonym nowym oknie podręcznym.

Wróciłem do Visual Studio i zbudowałem swoje rozwiązanie, które wyświetlało mi komunikaty o błędach.

Voilaa .. Tym razem kompilacja zakończyła się powodzeniem bez błędów.

Nie wiem, czy to jest idealne, ale zrobiłem to, aby rozwiązać problem.



2

Przejdź do ścieżki pliku, a następnie usuń zaznaczenie pola wyboru tylko do odczytu tego pliku.


1

Wiem, że to stary wątek, ale dla tych, którzy szukają odpowiedzi, takich jak ja kilka minut temu, zalecam najpierw ponowne uruchomienie komputera. To samo dla mnie naprawione. Wcześniej nie można nawet ręcznie skopiować do folderu.


1
też mi pomógł. Gang 2020
Vitor Ceolin

1

Wystarczy kliknąć prawym przyciskiem myszy projekt MVC i kliknąć opcję czyszczenia. Miałem podobny problem i wyczyszczenie projektu przed przebudową rozwiązało go dla mnie.


1

Miałem też ten sam problem. Naprawiłem to, usuwając zaznaczenie właściwości folderu głównego tylko do odczytu.


Czasami rozwiązanie jest tak proste i oczywiste jak to. Zamiast walić w głowę i pracować nad złożonymi i niekończącymi się procedurami, po prostu sprawdź tego rodzaju proste możliwości, a twoje życie stanie się znacznie łatwiejsze. Jestem wdzięczny StackOverflow za udostępnienie nam tak dużej społeczności ekspertów, którzy mogą zaoferować nam niezbędną pomoc w desperackich momentach.
Choudhury Saadmaan Mahmid

1

Też miałem ten problem. Oto jak to rozwiązać

  • Wyklucz binfolder z projektu.
  • Zamknij studio wizualne.
  • Oczyszczanie dysku z dysku C.
  • Ponownie otwórz projekt w studio wizualnym.
  • A następnie przebuduj rozwiązanie.
  • Uruchom projekt.

Ten proces działa dla mnie.



1

Byłem w stanie rozwiązać problem, usuwając plik docelowy, który narzeka (w twoim przykładzie „Bin \ Debug \ test.Resources.xml”) z folderu bin docelowej strony internetowej i ponownie go skompilowałem. To naprawiło to dla mnie.


1

1) zamknij rozwiązanie studia wizualnego

2) przejdź do wiersza polecenia -> uruchom jako administrator -> iisreset / stop

3) przejdź do c -> Windows -> Microsoft.Net -> Framework64 -> v4.030319 -> Tymczasowe pliki Asp.NET -> Usuń wszystkie pliki i foldery z tej ścieżki.

4) Wróć do wiersza poleceń -> iisreset / start

5) Teraz otwórz studio wizualne -> uruchom jako administrator -> wyczyść rozwiązanie i skompiluj je (nie przebudowuj .. tylko kompilacja działała dla mnie)


0

Nie należy zmieniać atrybutu folderu na „tylko do odczytu”. Powodem, dla którego pojawia się ten komunikat o błędzie, jest to, że kontrola źródła zakłada, że ​​przechowujesz różne pliki w innym miejscu niż folder bin, ponieważ jest zarezerwowane dla plików, które są automatycznie tworzone przez .Net i nie chce ich dodawać do źródła kontrola.

Sugeruję, aby zamiast używać Environment.CurrectDirectory(zakładam, że obecnie używasz), utwórz folder o nazwie „MyProjectName” w adresie% appdata%, a następnie użyj:

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


0

Właśnie natknąłem się na ten sam problem, z mojego powodu, udostępniono mój folder programistyczny, dzięki czemu mogłem używać komputera Mac jako hosta kompilacji dla aplikacji IOS przy użyciu Xamarina. Projekt działał na komputerze Mac, który przejął własność biblioteki dll, dlatego nie mogłem wprowadzać zmian w tej bibliotece z żadnego innego miejsca. Po prostu zatrzymanie aplikacji na Macu zwróciło mi własność, co pozwoliło ponownie na pełny dostęp. Mam nadzieję, że tak się stanie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.