Nu se poate copia fișierul – accesul la calea de acces este refuzat (Programare, C#, Visual Studio 2005, Acces Refuzat)

ricky a intrebat.

Folosesc Visual Studio 2005. După ce am preluat codul din controlul versiunilor mai întâi, aplicația c#.net rulează corect. Dar, după ce am făcut câteva modificări, când construiesc primesc următoarea eroare:

Eroare 383 Nu se poate copia fișierul „..rootleafBinDebugtest.Resources.xml” în „BinDebugtest.Resources.xml”. Accesul la calea „BinDebugtest.Resources.xml” este interzis. li.rollmodel

Știe cineva de ce apare această problemă?

Editați Văd că întregul folder de cod sursă al proiectului meu este Read-only și nu reușesc să elimin proprietatea read-only.

În primul rând, îmi poate spune cineva cum să elimin proprietatea Read-only pentru acest folder? Am încercat să o înlătur, dar proprietatea Read-only persistă. Am încercat și din partea de control al versiunii și nici asta nu a funcționat.

Comentarii

  • Este vorba de o partajare în rețea? Aveți acces administrativ pe computerul dumneavoastră? Această întrebare s-ar putea să se potrivească mai bine pe serverfault sau superuser. –  > Por arunkumar.
  • nu,,, folosesc propria mea mașină și am acces administrativ –  > Por ricky.
  • am rezolvat această problemă prin copierea manuală a fișierului dintr-o locație în locația necesară, probabil că problema este legată de MSBUILD cu fișier readonly –  > Por ricky.
43 răspunsuri
DiligentKarma

Am rezolvat această problemă prin ștergerea fișierelor litigioase din dosarul bin și reconstruirea proiectului.

Comentarii

    50

  • post vechi, știu, dar am avut aceeași problemă chiar acum. Asigurați-vă că VS este, de asemenea, închis, deoarece va refuza accesul la ștergerea dosarului în unele cazuri –  > Por Eon.
  • O mică notă: nu am înțeles, la început, că trebuie să șterg aceste fișiere în folderul de ieșire al proiectului principal și nu în folderul de ieșire al dll-ului. Deci, avertisment aici 🙂 –  > Por Piero Alberto.
  • În cazul meu, nici măcar închiderea VS nu a fost suficientă pentru a elibera dosarul și a-mi permite să îl șterg – ProcessExplorer a arătat că „VBCSCompiler.exe” încă îl folosea. În acest caz, ieșirea și reintrarea din Windows (sau pur și simplu uciderea procesului) a rezolvat problema, permițându-mi să reconstruiesc soluția și să fac ca totul să funcționeze din nou. –  > Por S. Jensen.
  • în cazul meu, motivul pentru care acel folder și soluția au devenit ReadOnly și, ulterior, VS a avut probleme în construirea acesteia, a fost că un fișier nu a reușit să se sincronizeze cu GoogleDrive și a fost cumva blocat de acest proces. Deci, pentru a reconstrui corect, a trebuit să închid GoogleDrive și apoi s-a construit foarte bine. –  > Por konrad.
  • Am descoperit că Bitdefender Antivirus Free a fost vinovatul. –  > Por Warwick.
Wahid Bitar

Doar asigurați-vă că dosarul NU este Read-Only și reconstruiți soluția

Comentarii

  • Încerc să înlătur caseta de selectare ‘Read-only’ umplută cu culoarea verde. Când fac clic pe ‘Apply’ și apoi pe ‘Ok’, iar apoi verific din nou proprietățile acelui folder, pot vedea din nou în starea anterioară (având din nou caseta de selectare ‘Read-only’ umplută cu culoarea Verde). Are cineva o soluție în acest sens? –  > Por Vikram.
  • De asemenea, asigurați-vă că fișierul nu este blocat. În cazul meu, fișierul se afla pe un share și altcineva îl avea deschis. –  > Por Dan Bechard.
  • Închideți Visual Studio înainte de a elimina atributul read only. Deoarece este posibil ca fișierul în cauză să fie în curs de utilizare (blocat) –  > Por Gautam Jain.
  • Am creat o extensie Visual Studio pentru ștergerea atributului ReadOnly și Hidden al dll-urilor care blochează compilarea. UnBlockDllExtension : marketplace.visualstudio.com/… –  > Por vrnithinkumar.
jordenysp

Am rezolvat această problemă: Închideți Visual Studio, deschideți-l din nou și încărcați soluția, Rebuild your solution. Problema mea a apărut folosind TFS și VIsual Studio 2010.

Comentarii

    22

  • Adăugați aceeași problemă în VS2013. Caz clasic de The IT Crowd. „Bună ziua, aici este IT, ați încercat să-l opriți și să-l porniți din nou?”. –  > Por Maxime Rouiller.
  • Același scenariu: TFS și VS 2010. Aceeași problemă. Aceeași soluție. +1 –  > Por ajeh.
  • Acest lucru s-a întâmplat și pe VS2015 :p  > Por Yoo Matsuo.
  • Și același lucru în VS2017 –  > Por arame333333.
  • Am înnebunit deja încercând să rezolv asta, s-a dovedit că vechea metodă bună dacă ceva nu funcționează, repornește-l, a funcționat foarte bine –  > Por Mykhailo Seniutovych.
MuriloKunze

Kill process VBCSCompiler.exe și reconstruiți.

Comentarii

  • Aceasta este ceea ce a rezolvat-o pentru mine. Mulțumesc, străinule dragă :D.  > Por Morsus.
  • da, asta este. –  > Por kal kokah.
  • Mulțumesc foarte mult, străinule bun! 😀 –  > Por Agent007.
  • uneori a funcționat pentru mine nu întotdeauna, trebuie să spun că va rezolva o parte din această problemă există și altceva care cauzează această problemă –  > Por Amit Bisht.
  • Încearcă și asta, s-ar putea să te ajute stackoverflow.com/a/12740768/2445111 –  > Por Amit Bisht.
Heitor Corrêa

Am pășit și eu în această problemă.

Mai întâi mergeți și verificați dacă ați mapat dosarul bin și obj în programul Source Control.

Acest lucru poate transforma fișierele din folderele de binare în arhive numai pentru citire, ceea ce face imposibil ca Visual Studio să le suprascrie atunci când compilează codul.

Mergeți și eliminați cartografierea din aceste dosare, verificați modificările și încercați din nou.

Problema mea a apărut folosind TFS (Team foundation server) și Visual Studio 2010.

Sper că acest lucru ajută pe cineva.

Comentarii

  • Am vrut doar să adaug că răspunsul lui Heitorolecarte mi-a rezolvat problema și că aceasta poate apărea cu Visual Studio 2012 și TFS2010. –  > Por Rodney.
Alejandro Haro

Rulați Visual Studio ca administrator

Comentarii

  • Notă: aici este o modalitate scurtă și simplă de a rula întotdeauna ca administrator în mod implicit stackoverflow.com/questions/12257110/… – –  > Por wmebane.
  • Acest răspuns mi-a spus suficient de mult încât am știut doar să adaug permisiunea de scriere la „Users” pe folderul de ieșire – și asta mi-a rezolvat instantaneu problema (care era că nu puteam publica nici măcar prima dată). –  > Por X Goodrich.
  • Ce sugestie nespus de periculoasă. Nu numai că este iresponsabil să sfătuiești pe cineva suficient de nesigur pe ceea ce se întâmplă pentru a ocoli securitatea, dar construirea ca administrator va ascunde orice probleme de implementare pe care le are codul tău. –  > Por Paul Childs.
Claudiu Constantin

În cazul meu, antivirusul a fost cel care a blocat fișierul.

Comentarii

  • BitDefender 6.2 aici -.  > Por JOG.
  • Folosind Avast aici – JOG  > Por h-rai.
  • Avast și pentru mine. –  > Por dc922.
Vikram

Eu folosesc Visual Studio 2013. M-am confruntat cu această problemă de 2 ori:

  1. La prima ocazie, am rulat Visual Studio fără drepturi de administrator. Așadar, am închis VS și l-am pornit folosind ‘Run as administrator‘. Acest lucru mi-a rezolvat problema.

  2. A doua oară, am repornit VS de mai multe ori, asigurându-mă de fiecare dată că îl execut ca administrator. De asemenea, am reconstruit soluția de mai multe ori. Dar, în ciuda acestui fapt, am primit o eroare. După aceea, am am eliminat fișierul în cauză din locația țintă (fișierul era deja prezent, poate de la construcția anterioară, în locația în care încearcă să copieze) și am reconstruit soluția. După aceea, eroarea a dispărut și totul a funcționat fără probleme!

Comentarii

  • ștergerea fișierelor deja prezentate în dosarul țintă funcționează pentru mine –  > Por Saad Awan.
Vinayak Savale

Mai întâi mergeți la locația fișierului. Apoi faceți clic dreapta pe dosarul fișierului -> Properties -> Opțiunea Read Only (Numai citire) nebifată și aplicați-o la fișiere și la subfolderele sale.Mi-a rezolvat problema.Codare fericită!

tomRedox

Acest lucru a reapărut din nou în Visual Studio 2017, în acest caz, cauza este procesul Application Insights ServiceHub.DataWarehouseHost.exe.

Există o soluție de rezolvare discutată în firul de discuții avertizare MSB3026: Nu s-a putut copia „objDebug
etcoreapp1.1src.pdb” în „binDebug
etcoreapp1.1src.pdb”
, care constă în adăugarea unui eveniment de precompilare la proiect pentru a ucide procesul de fiecare dată când proiectul este construit. Citez din acel link:

  • Faceți clic dreapta pe proprietățile proiectului
  • Alegeți proprietăți
  • Evenimente de construcție
  • Linia de comandă a evenimentului de pre-construcție
taskkill /IM ServiceHub.DataWarehouseHost.exe /F 2>nul 1>nul
Exit 0
  • Salvați și construiți

Tigran

Poate cineva să știe de ce apare această problemă?

Dacă mă uit la răspunsul dvs. că ați rezolvat problema prin copiere manuală, aș spune că codul la care lucrați a fost realizat de un alt utilizator (cu privilegii de administrator de asemenea), astfel încât a fost blocat pentru dvs. Efectuând copy –? paste, ai făcut propria ta copie a sursei cu tot accesul de care aveai nevoie. Singurul lucru care trebuie observat este că, în acest caz, dacă acest alt dezvoltator va trebui să lucreze la copia dvs., el/ea va avea cam aceeași problemă pe care ați avut-o înainte.

EdSF

Postare veche, dar acest zombie se lovește de VS 2017 (nu am săpat de ce este vorba doar de „unele” proiecte). În acest caz, nu este permisiunile utilizatorului, mai degrabă procesul IIS Express folosește încă fișierele.

Veți vedea pictograma în tava de activități

  1. Faceți clic dreapta
  2. Ieșiți din
  3. Ar trebui să puteți rebuild fără acest mesaj enervant „permisiune refuzată”.

Acesta este, de asemenea, motivul pentru care „repornirea Visual Studio” va „rezolva” problema. Făcând acest lucru, se oprește IIS Express.

Hth…

shawn

Am adăugat din nou toate dependențele / referințele mele non-.NET și a rezolvat problema.

Henley Chiu

Am rezolvat și eu această problemă. Problema era că aveam soluția deschisă în alt loc. După ce am închis-o, funcționează

Comentarii

  • Am făcut și eu acest lucru. Întotdeauna verificați mai întâi lucrurile ușoare și evidente, destinația mea era pe o unitate de rețea, deoarece am fost depanat pe o altă mașină. –  > Por Simon Unsworth.
David Leitner

Am avut aceeași problemă, dar repornirea Visual Studio de fiecare dată nu a fost o opțiune pentru mine, deoarece problema apare uneori foarte des.

Am rezolvat-o prin instalarea Unlocker (încearcă să instaleze orice bară de instrumente la instalare, așa că nu uitați să debifați acest lucru), această aplicație îmi oferă acces rapid la redenumirea/ștergerea unui fișier „.xml” blocat.. Știu că și aceasta este doar o soluție de rezolvare, dar pentru mine a fost cea mai rapidă soluție pentru a rezolva această problemă.

Comentarii

  • Mulțumesc pentru asta. Am avut această problemă în ultimul an și am crezut că se datorează faptului că treceam de la Administrator la Administrator și invers, dar acum știu că este vorba de un proces critic stupid legat de Panda Antivirus (PSANHost.exe, care nu este prezent în Task Manager) care a blocat fișierele. –  > Por yeejuto.
portia

Am creat această problemă atunci când am adăugat un nou proiect de configurare la soluție și apoi am adăugat fișiere direct din folderul /bin/release al proiectului principal de aplicație în folderul de fișiere de aplicație al proiectului de configurare. Controlul sursei din proiectul de configurare mă bloca în mod constant să finalizez o compilare a proiectului principal de aplicație.

Soluție: creați un dosar de descărcare separat în afara oricărui proiect care va conține toate fișierele care vor fi incluse în instalare și adăugați-le de acolo. Este o pacoste, deoarece acum trebuie să îmi amintesc să copiez toate fișierele pentru fiecare pachet de instalare nou. S-ar putea să văd dacă pot face ceva cu acțiunile post-compilare a noastră o compilare automată pentru a face procesul mai ușor.

InitialV

Dacă copiați orice fișier într-o soluție, asigurați-vă că fișierele nu sunt în modul Read Only. Faceți clic dreapta pe fișier și debifați opțiunea de atribut a rezolvat problema mea.

Madmartigan

Am avut aceeași eroare, dar eu folosesc Perforce controlul versiunii. Iată cum am rezolvat-o.

  1. Închis Perforce P4V client
  2. Repornit Visual Studio 2010 (s-ar putea să nu fie necesar)
  3. Am reconstruit proiectul, ceea ce a reușit
  4. M-am simțit excepțional de fericit și dezgustat în același timp

Comentarii

  • Am aceeași configurație, dar nu am reușit să ajung la pașii 3 și 4 🙁  > Por user3260977.
Ziggler

Și eu am avut aceeași problemă. Am primit mesaje de eroare care se refereau la nu se poate copia deoarece accesul la cale este refuzat. În cazul meu, toate dll-urile și fișierele xml și așa mai departe sunt plasate în folderul D:TFSExampleBinDebug.

Am făcut clic dreapta pe folderul Bin și am făcut clic pe Properties (Proprietăți) și am văzut că la Attributes (Atribute) este bifată caseta Read-only (Doar pentru citire).

Am debifat caseta de selectare „Read only”, am făcut clic pe Apply și am făcut clic pe OK în noua fereastră pop-up care a apărut.

M-am întors în Visual Studio și am construit soluția care îmi dădea mesaje de eroare.

Voilaa.. De data aceasta a fost construită cu succes, fără erori.

Nu știu dacă acest lucru este perfect, dar am făcut acest lucru pentru a rezolva problema mea.

Hazen Hills Software

Verificați Task Manager și asigurați-vă că nu aveți un proces devenv.exe suspendat. Opriți procesul fugar și încercați din nou.

Ramy Othman

Mergeți la calea fișierului, apoi debifați caseta de selectare read only a acestui fișier.

Ji_in_coding

Majoritatea răspunsurilor pe care le-am văzut explorează în mod obiectiv posibilele probleme cu mediul, ceea ce este probabil corect pentru 99% dintre persoanele care se confruntă cu această problemă (nu se poate copia fișierul de la … la … accesul este refuzat).

M-am gândit că ar trebui să împărtășesc experiența mea pentru cei 1% care s-au confruntat cu această problemă din motive diverse.

Am scris un program batch de redenumire a fișierelor pe care îl folosesc pentru a acționa asupra a zeci de mii de fișiere, iar AntiVirusul meu l-a interpretat ca fiind troian și l-a pus în carantină automată. Având în vedere că această cale se află pe lista neagră a antivirusului meu, Visual Studio nu poate copia niciodată *.exe în dosarul bin, ceea ce înseamnă că nu poate copia .exe.

Rezolvarea mea este să pun această cale pe lista albă și problema este rezolvată.

Noroc.

Joao Leme

Știu că este un fir vechi, dar pentru cei care caută răspunsuri, ca și mine acum câteva minute, vă recomand să încercați mai întâi să reporniți computerul. Doar asta a rezolvat pentru mine. Înainte nu puteam nici măcar să copiez manual în folder.

Comentarii

  • m-a ajutat și pe mine. 2020 gang –  > Por Vitor Ceolin.
Ehsan

Doar faceți clic dreapta pe proiectul MVC și faceți clic pe opțiunea de curățare. Am avut o problemă similară și curățarea proiectului înainte de a reconstrui a rezolvat-o pentru mine.

Am avut și eu aceeași problemă. Am rezolvat-o debifând proprietățile Read-only ale folderului rădăcină.

Comentarii

  • Uneori, soluția este atât de simplă și evidentă ca aceasta. În loc să vă tot bateți capul și să lucrați cu proceduri complexe și nesfârșite, verificați doar acest tip de posibilități simple și viața dumneavoastră va deveni mult mai ușoară. Îi sunt recunoscător lui StackOverflow pentru că ne pune la dispoziție o comunitate atât de vastă de experți care ne pot oferi ajutorul necesar în momente disperate. –  > Por Choudhury Saadmaan Mahmid.
Manoj

Și eu am avut această problemă. Iată cum se rezolvă acest lucru

  • Excludeți bin folder din proiect.
  • Închideți Visual Studio.
  • Curățarea discului de pe unitatea C.
  • Redeschideți proiectul în Visual Studio.
  • Și apoi reconstruiți soluția.
  • Rulați proiectul.

Acest proces funcționează pentru mine.

krishna keshav

Schimbarea căii de ieșire a funcționat pentru mine în Visual Studio 2015. Acest lucru ar trebui să vă ajute – Schimbarea directorului de ieșire pentru compilare

Rama Krshna Ila

Am reușit să rezolv problema prin eliminarea fișierului țintă care se plânge (în exemplul dvs. „BinDebugtest.Resources.xml”) din dosarul bin al site-ului web țintă și re-construindu-l. Asta a rezolvat-o pentru mine.

Krishna

1) închideți soluția Visual Studio

2) navigați la promptul de comandă –> executați ca administrator –> iisreset /stop

3) navigați la c–> Windows –> Microsoft.Net –> Framework64–> v4.030319–> Temporary Asp.NET Files –> Ștergeți toate fișierele și folderele din această cale.

4) Navigați înapoi la promptul de comandă –> iisreset /start

5) Acum deschideți studioul vizual –> executați ca administrator –> curățați soluția și construiți-o (nu reconstruiți..doar construiți a funcționat pentru mine)

Chirag Thakar

Am avut aceeași problemă, Pentru a rezolva acest lucru am verificat / făcut mai multe lucruri

Ce nu a funcționat

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

Ce a funcționat în cele din urmă

Doar lipiți comanda dată de Fred Morrison în „Package Manager Console”:

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

Notă: Doar o observație Repornirea Visual Studio ar putea să nu funcționeze în acest caz, dar repornirea sistemului poate funcționa, deoarece oprirea procesului „VBCSCompiler” a fost soluția, astfel încât putem face acest lucru în ambele moduri.

Bizhan

Nu ar trebui să modificați atributul folderului la not-readonly. motivul pentru care vedeți acest mesaj de eroare este că source control presupune că stocați doar fișierele diverse în altă parte decât în folderul bin, pentru că acesta a rezervat fișierele care sunt create automat de .Net și nu dorește să le adauge la source control.

Vă sugerez ca în loc să utilizați Environment.CurrectDirectory (pe care presupun că o folosiți în prezent), să creați un folder numit „MyProjectName” în adresa %appdata% și apoi să folosiți:

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

Jon Willis

Deci, tocmai m-am lovit de aceeași problemă, cauza mea, am avut folderul de dezvoltare partajat pentru a putea folosi un mac ca gazdă de construcție pentru o aplicație IOS folosind Xamarin. Proiectul a fost rulat pe mac care a preluat proprietatea dll-ului, prin urmare, nu am putut face modificări la acel dll de oriunde altundeva. Simpla oprire a aplicației de pe mac mi-a redat proprietatea, ceea ce mi-a permis din nou accesul complet. Sper că acest lucru face de atunci.

TC Tarım Köy İșleri

Ștergeți toate bibliotecile referite în „bindebug” și faceți clic dreapta pe Soluție în exploratorul de soluții după ce faceți clic pe „Clean Solution”.

Și Rebuild!!!

patil.rahulk

M-am confruntat cu această problemă de mai multe ori, iar soluția pe care am găsit-o este să ștergeți dosarul de depanare și apoi să reconstruiți soluția/proiectul. A funcționat pentru mine!!!

Marlon Vidal

Asigurați-vă că adăugați numele fișierului după numele căii (pathfileName.extension). Am petrecut mai mult de o oră fără să notez acest lucru.

Pat Capozzi

Acesta poate fi un produs secundar ciudat al încărcării sursei inițial din controlul sursei (TFS etc.), unde toate fișierele și folderele sunt protejate la scriere. Mergeți la directorul de nivel superior și verificați proprietățile și ați putea găsi Atributul „Read-only” (numai pentru citire) verificat. Debifați acest atribut și sistemul ar trebui să vă întrebe dacă doriți ca toate directorii de la nivelul superior să fie setați ca fiind inscriptibili. Acest lucru ar trebui să rezolve problema.

desiguy

Am încercat să mă deconectez și să mă conectez din nou și a funcționat pentru mine. Să sperăm că acest lucru va ajuta pe altcineva.

Santiago Martí Olbrich

În cazul meu, am portat un proiect de pe Windows pe OSX, folosind Visual Studio Community 7.1.5 pentru Mac. Ceea ce a făcut trucul a fost dezactivarea funcției Use MSBuild engine (recommended for this type of project)opțiunea din preferințele proiectului:

rsmith

Pentru mine, problema era că un alt proiect din soluție avea același fișier .dll care fusese verificat mai recent.

Copierea manuală a versiunii mai recent verificate a fișierului .dll din folderul bin al celuilalt proiect în folderul bin al proiectului care genera eroarea a rezolvat problema.

O soluție pe termen mai lung pentru soluția noastră ar fi să folosim același fișier .dll exact pentru toate proiectele din soluție, în loc să avem același fișier .dll în mai multe proiecte, dar nu am avut chef să mă ocup de acest lucru, așa că soluția rapidă și murdară a fost să copiez doar versiunea mai nouă.

Dominic Grenier

Am încercat totul aici, cumva ștergerea tuturor folderelor bin și obj din proiectul meu nu a funcționat. Eliberarea folderelor din alte procese nu a făcut nimic. Repornirea nu a făcut nimic. Îndepărtarea read only din fiecare fișier prin debifarea acestuia pe folderul principal nu a ajutat.

Fiecare dependență a sfârșit prin a se adăuga la problemă. Construirea direct în folderul dependențelor a funcționat, așa că am fost confuz. Aveam de gând să dublez această întrebare, dar am găsit ceva care a funcționat.

Știți ce a funcționat?

dotnet clean

Er.Imran Shaikh

după ce am încercat aproape totul, am copiat proiectul în altă locație și am construit proiectul… și a funcționat.

Dotnetpickles

Soluție simplă:

Doar actualizați următoarele pachete

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

Se va rezolva problema.

Blake Rivell

Dacă cineva dorește o soluție foarte simplă înainte de a încerca orice altceva.

Pur și simplu reporniți PC-ul.Deschideți Visual Studio, încercați să construiți din nou.