Błąd: nie można uzyskać dostępu do pliku bin / Debug /…, ponieważ jest używany przez inny proces

113

Podczas debugowania projektu pojawia się następujący błąd:

„Nie można skopiować pliku” obj \ Debug \ My Dream.exe ”do„ bin \ Debug \ My Dream.exe ”. Proces nie może uzyskać dostępu do pliku„ bin \ Debug \ My Dream.exe ”, ponieważ jest używany przez inny proces."

Używając Process Explorer, widzę, że MyApplication.exe nie działa, ale proces systemowy nadal go używa, chociaż wcześniej zatrzymałem debugowanie. Za każdym razem, gdy zmienię kod i rozpocznę debugowanie, będzie to miało miejsce. Jeśli skopiuję projekt na USB i debuguję, działa poprawnie.

Czemu? Jak mogę naprawić ten błąd?

Używam Windows 7 Professional. Z Xp nigdy nie miałem tego błędu.

Trần Minh
źródło
1
win7 czasami blokuje pliki, które są przeglądane w eksploratorze, więc upewnij się, że nie masz otwartego folderu debugowania.
Necrolis,
Myślę, że system go używa.
Trần Minh
1
To albo blokada, albo jakiś idiota dodany / bin do kontroli źródła, a teraz pliki są chronione przed zapisem (kliknij prawym przyciskiem myszy bin, odznacz chroniony przed zapisem).
Stefan Steiger,
3
W programie Visual Studio 2017 jest to gorsze niż kiedykolwiek wcześniej.
Rob Lyndon
1
W moim przypadku MSBuild.exeplik został zatrzymany, po prostu zakończ proces w Menedżerze zadań
Pierre

Odpowiedzi:

120

Ugh, to stary problem, coś, co od czasu do czasu pojawia się w Visual Studio. Ugryzł mnie kilka razy i straciłem godziny na ponowne uruchamianie i walkę z VS. Jestem pewien, że omawiano to tutaj w SO więcej niż raz. Mówiono o tym również na forach MSDN. Nie ma rzeczywistego rozwiązania, ale istnieje kilka obejść. Rozpocznij wyszukiwanie tutaj .

Dzieje się tak, że VS blokuje plik, a następnie go nie zwalnia. Jak na ironię, ta blokada uniemożliwia VS-owi usunięcie pliku, aby mógł go odtworzyć po odbudowaniu aplikacji. Jedynym pozornym rozwiązaniem jest zamknięcie i ponowne uruchomienie VS, aby zwolnić blokadę pliku.

Moje pierwotne obejście polegało na otwarciu folderu bin / Debug i zmianie nazwy pliku wykonywalnego. Nie możesz go usunąć , jeśli jest zablokowany, ale możesz zmienić jego nazwę. Możesz więc po prostu dodać liczbę na końcu lub coś w tym rodzaju, co pozwoli ci kontynuować pracę bez konieczności zamykania wszystkich okien i czekania na ponowne uruchomienie VS. Niektórzy nawet zautomatyzowali to, używając zdarzenia pre-build, aby dołączyć losowy ciąg na końcu starej nazwy pliku wyjściowego. Tak, to gigantyczny hack, ale ten problem staje się tak frustrujący i osłabiający, że zrobisz wszystko.

Później dowiedziałem się, po nieco dłuższych eksperymentach, że problem pojawia się tylko wtedy, gdy tworzysz projekt z otwartym jednym z projektantów. Tak więc rozwiązaniem, które działało dla mnie przez długi czas i uniemożliwiło mi kiedykolwiek do czynienia z jednym z tych głupich błędów, jest upewnienie się, że zawsze zamykam wszystkie okna projektanta przed zbudowaniem projektu WinForms. Tak, to również jest nieco niewygodne, ale z pewnością pokonuje spodnie konieczność ponownego uruchamiania VS dwa razy na godzinę lub dłużej.

Zakładam, że dotyczy to również WPF, chociaż nie używam go i osobiście nie doświadczyłem tam problemu.

Nie próbowałem jeszcze odtworzyć go na VS 2012 RC. Nie wiem, czy to już zostało tam naprawione, czy nie. Ale z mojego dotychczasowego doświadczenia wynika, że ​​nadal udaje mu się pojawiać, nawet po tym, jak Microsoft twierdził, że go naprawił. Nadal jest dostępny w VS 2010 SP1. Nie mówię, że ich programiści to idioci, którzy nie wiedzą, co robią, oczywiście. Wydaje mi się, że istnieje wiele przyczyn tego błędu i / lub bardzo trudno jest wiarygodnie odtworzyć go w laboratorium. To jest ten sam powód, dla którego osobiście nie złożyłem żadnych raportów o błędach (chociaż dałem +1 innym ludziom), ponieważ nie mogę go wiarygodnie odtworzyć, podobnie jak Abominable Snowman.

<koniec rant, który nie jest skierowany do nikogo w szczególności>

Cody Gray
źródło
1
To wciąż się (dla mnie) dzieje w VS2013. Zawsze jest to plik PDB projektu WPF w moim rozwiązaniu, który zostaje zablokowany w katalogu docelowym. Zamknięcie wszystkich projektantów nie pomogło (boo!), Ale zmiana nazwy pliku zadziałała (dzięki, Cody!). Gigantyczny hack kusi ...
Jon
2
Zaczęło mi się to przytrafiać od wczoraj, kiedy zaktualizowałem do vS 2013 ... nie zdarzyło mi się to ani razu od VS 2008 ... takie smutne.
SomeNickName
8
VS 2015 i nadal mam problem.
Berin Loritsch
13
Dzieje się to w programie Visual Studio 17, a ponowne uruchomienie programu Visual Studio nie pomaga.
Rob Lyndon
2
@jairhumberto nie ma powodu do warknięcia, komputery i tak są wystarczająco frustrujące, nie ma potrzeby przekazywania tego komuś innemu .. ale to działa dla mnie w przypadku tego konkretnego problemu, może masz coś innego! Zobacz: stackoverflow.com/a/19649014/27494
ScottN
64

Ten błąd pojawiał się już wcześniej, nawet w programie Visual Studio 2008. Powrócił i był bardziej rozpowszechniony w programie Visual Studio 2012.

Oto co robię.

Wklej to w zdarzeniu poprzedzającym kompilację kłopotliwego projektu:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
ScottN
źródło
1
Gdzie mogę znaleźć to Pre-Buildwydarzenie w moim formularzu systemu Windows?
Unknownymous
2
@qwerty Znajduje się we właściwościach projektu w sekcji Build Events lub jeśli jesteś w projekcie VB.net, w sekcji Compile, zobaczysz przycisk Build Events.
ScottN,
@ScottN: och BTW, ten pre-buildkod jest również lekarstwem na wdrożoną (przez kliknięcie) aplikację, gdy moja aplikacja jest uruchomiona, a następnie wystąpił błąd / usterka w menedżerze zadań, zakończę zadanie moje, myApp.exeale nie zakończę zadania i pojawi się monit ERROR ON ENDING TASK?
Unknownymous
@qwerty Nie, to nie ma powiązania z wdrożoną aplikacją ClickOnce. Ten błąd występuje tylko wtedy, gdy tworzysz aplikację podczas programowania i testowania i tylko w programie Visual Studio, a nie w przypadku żadnej wdrożonej aplikacji działającej w systemach klienckich.
ScottN
Co to .lockeddotyczy?
Shimmy Weitzhandler
22

Komputer (kliknięcie prawym przyciskiem myszy) -> zarządzaj -> Usługi i aplikacje -> usługa -> Włącz obsługę aplikacji

Pracował dla mnie!

Alex
źródło
2
Wyłączyłem tę usługę kilka miesięcy temu. Włączenie go teraz wydawało się rozwiązać problem w programie Visual Studio (nie można skopiować z powodu zablokowania pliku exe). Zastanawiam się, dlaczego ta usługa musi być uruchomiona, to co o niej przeczytałem nie wydawało się być związane z niczym istotnym dla tego błędu (np. Blackviper.com/windows-services/application-experience ).
Andreas Jansson
10
Mam uruchomioną usługę, ale nadal występuje problem z blokadą.
antfx
1
+1 Wow, próbowałem / wszystko / inne znalazłem. Wreszcie natknąłem się na to, aby to naprawić. Mój też był wyłączony. Nigdy nie pomyślałbym, że to sprawca!
John S.
Uruchamianie systemu Windows 7 SP1 z VS2010 SP1, włączenie usług „Doświadczenie aplikacji” natychmiast mi pomaga. Wielkie dzięki. Jednak po minucie wyłączenie go nie powoduje natychmiastowego odtworzenia problemu.
Jimm Chen
7
usługa nie została znaleziona w
systemie
13

Miałem ten sam problem w programie Visual Studio 2013. Nie jestem pewien, co spowodowało to w moim projekcie, ale udało mi się go naprawić, czyszcząc rozwiązanie i odbudowując je.

  1. Kompiluj> Czyste rozwiązanie
  2. Kompiluj> Odbuduj rozwiązanie
lkisac
źródło
1
Nie próbuj tego na dużych projektach ... Pełna przebudowa trwa naprawdę długo.
mBardos,
7

Przynajmniej w moim przypadku zauważyłem, że Visual Studio 2012 tworzyło co najmniej dwa procesy-duchy msbuild.exe, które nie ginęły po kompilacji. Te zombie najwyraźniej powodują pojawianie się blokad plików.

Zabijanie msbuild.exe jest rozwiązaniem jednorazowym, należy to zrobić na podstawie kompilacji.

Ale potem doszedłem do wniosku, że mogę raz na zawsze wyłączyć kompilację równoległą - przeszedłem do Narzędzia> Opcje> Projekty i rozwiązania> Kompiluj i uruchom> „maksymalna liczba równoległych kompilacji projektów” - domyślnie ma wartość 8, ja Przełączyłem się na 1. Działa jak urok.

Oczywiście kompilacje są teraz nieco wolniejsze, ale lepiej bezpieczne niż przykro. Przynajmniej dla tego konkretnego małego projektu nie potrzebowałem więcej niż jednego wątku kompilacji.

TarmoPikaro
źródło
7

Rozumiem, że to stare pytanie. Niestety miałem ten sam problem z moją .net core 2.0aplikacją w formacie visual studio 2017. Pomyślałem więc o udostępnieniu rozwiązania, które zadziałało dla mnie. Przed tym rozwiązaniem próbowałem wykonać poniższe kroki.

  1. Uruchomiono ponownie Visual Studio
  2. Zamknięto całą aplikację
  3. Wyczyść moje rozwiązanie i odbuduj

Żaden z powyższych kroków nie rozwiązał problemu.

Następnie otworzyłem mój Task Manageri wybrany dotnetproces, a następnie kliknąłem przycisk Zakończ zadanie. Później otworzyłem Visual Studio i wszystko działało dobrze.

wprowadź opis obrazu tutaj

Sibeesh Venu
źródło
2

Zobacz moją odpowiedź tutaj, jeśli masz ten problem podczas uruchamiania testów jednostkowych. Odpowiedź skopiowana poniżej:

Opierając się na odpowiedzi Sébastiena, dodałem krok przed kompilacją do mojego projektu testowego, aby automatycznie zabić wszystkie vstest.*uruchomione pliki wykonywalne. Działało dla mnie następujące polecenie przed kompilacją:

taskkill /f /im vstest.*
exit 0

exit 0Komenda jest na końcu, aby zapobiec gromadzeniu awarię gdy nie istnieją żadne vstest.*pliki wykonywalne uruchomione.

mrtumnus
źródło
1

Ostatnio miałem problem z Visual Studio 2012 z tym samym opisem błędu: „Proces nie może uzyskać dostępu do pliku, ponieważ jest używany przez inny proces ...”

Aby to naprawić, musisz najpierw zrozumieć aplikację, która nadal z niej korzysta. Zamknąłem wszystkie procesy, takie jak „MSBuild” i „MSBuild host”. Ale to nie wystarczy. Jeśli masz zainstalowane i włączone „kontrakty kodu”, czasami wymaga to sprawdzenia bibliotek DLL i zawieszania się tej operacji.

Musisz więc zatrzymać wszystkie procesy „CCCheck.exe” i to wszystko.

Wreszcie, aby zrozumieć, że proces używa twojej biblioteki DLL, zawsze możesz spróbować po prostu usunąć folder „obj” w menedżerze plików i ta operacja się nie powiedzie, możesz zobaczyć „okno wiadomości” z opisem operacji zawieszania. Możesz także spróbować użyć aplikacji „Sys Internals Suite”.

Yarkov Anton
źródło
Przynajmniej w moim przypadku zauważyłem, że Visual Studio tworzyło procesy duchów msbuild.exe, które nie ginęły po kompilacji. Te zombie najwyraźniej powodują pojawianie się blokad plików. Ale nie ma pojęcia, jak to rozwiązać. Zabijanie msbuild.exe jest rozwiązaniem jednorazowym, należy to zrobić na podstawie kompilacji.
TarmoPikaro,
1

Pracował dla mnie. Menedżer zadań -> Nazwa projektu -> Zakończ zadanie. (miałem 3 takie same procesy z nazwą mojego projektu);

VS 2013; Win 8;

GroD
źródło
1

Upewnij się, że jakiekolwiek poprzednie uruchomienie aplikacji (na przykład uruchomienie bez opcji debugowania) zostało faktycznie zatrzymane. Pracowałem nad aplikacją WPF, uruchomiłem bez debugowania i zminimalizowałem ją, gdy ciągle otrzymywałem błąd. Po zamknięciu aplikacji zachowanie VS wróciło do normy.

sk1900
źródło
1

Ten problem nęka mnie w programie Visual Studio 2017. Zaczął się około dwa lub trzy tygodnie temu i poważnie wpłynął na moją produktywność. Clean i Rebulid nie działały; nawet ponowne uruchomienie komputera nie działa.

Jednym ze sposobów rozwiązania tego problemu jest wyczyszczenie nieprawidłowego zestawu i zbudowanie (a nie odbudowanie) projektu, który chcesz uruchomić natychmiast po zakończeniu. Działa to przez około 30% czasu.

Jednak prawdopodobnie najbardziej niezawodnym rozwiązaniem, jakie znalazłem, jest otwarcie wiersza polecenia programisty i msbuildbezpośrednie użycie . Robię to od trzech dni i jak dotąd problem nie wystąpił ani razu.

Rob Lyndon
źródło
1

W moim przypadku było to, że mam włączoną opcję „Pokaż wszystkie pliki”. Visual Studio 2017

JD - DC TECH
źródło
1

Biegnij taskmanager.
Zlokalizuj netcorei usuń.
Następnie możesz usunąć plik ręcznie lub uruchamiając Clean.

BobSpring
źródło
0

To czysta spekulacja, a nie odpowiedź.

Jednak mam ten problem już od jakiegoś czasu.

Przyszedłem po pewnym czasie, aby podejrzewać interakcję między VS a moimi środkami ostrożności.

Po pewnym czasie gry wydaje się, że mógł zniknąć, gdy zmodyfikowałem mój program antywirusowy, aby wszystko pod rozszerzeniem

C: \ Users [nazwa użytkownika] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

folder nie był objęty ochroną w czasie rzeczywistym.

Wygląda na to, że kompilacja faktycznie najpierw zapisuje bibliotekę DLL, a następnie kopiuje ją do ostatecznej lokalizacji kompilacji.

PolicyWatcher
źródło
0

Może być za późno. Ale napotkałem podobny problem iw moim przypadku projekt miał odniesienie do siebie. Dlatego usunięcie go z Referencji zadziałało jak urok !!!

aby
źródło
0

Znalazłem najszybszy sposób bez zamykania formularzy lub ponownego uruchamiania VisualStudio, to przejdź do strony kompilacji projektu i kliknij przycisk "Zaawansowane opcje kompilacji ...". Następnie wprowadź dowolną zmianę w jednej z opcji (powiedzmy, zmieniając opcję Generuj informacje debugowania z Pełne na Tylko pdb), a następnie kliknij OK. Działa za każdym razem i będzie musiał to zrobić, dopóki MS nie naprawi tego błędu (nigdy nie miałem tego problemu, dopóki nie przełączyłem się z VS2012 na VS2013)

Kolejna uwaga, jeśli nie możesz wyczyścić projektu lub rozwiązania, nie zostanie ono zbudowane. Pliki są zdecydowanie zablokowane przez VS (nie jest to problem antywirusowy, przynajmniej nie w moim przypadku)

MC9000
źródło
0

Wypróbowałem wszystkie te sugestie, a także inne sugestie znalezione gdzie indziej, a jedyną rzeczą, która zadziałała, było ponowne uruchomienie komputera. Następnie zrobiłem czyste rozwiązanie, a następnie odbudowałem. Używam Visual Studio 2013 w celach informacyjnych.

Mortey
źródło
0

Pobiegłem do tego samego problemu i odkryłem, że w tle działa wiele aplikacji Windows Form . Dzieje się tak, gdy aplikacja ma dwa formularze i zamkniesz drugi formularz, który nie jest głównym formularzem, więc aplikacja nie zostanie całkowicie zamknięta.

Zwykle uruchamiam swoją aplikację

  • poprzez jego exe lub
  • działać bez debugowania

Rozwiązaniem jest zamknięcie drugiej instancji aplikacji formularza Windows . Jest to jeden ze sposobów, aby zawsze zamknąć instancję aplikacji.

jmvtrinidad
źródło
0

Polecenie przed kompilacją

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Pomógł

Kakha Middle Or
źródło
0

[Rozwiązany] Błąd: nie można uzyskać dostępu do bin / Debug /…, ponieważ jest używany przez inny proces:

Zbliżam się do tego, że pojawia się ten błąd, gdy próbujesz uruchomić dwa okna jeden po drugim, na przykład najpierw ładując formularz, a potem czasami automatycznie znika, a drugi formularz jest ładowany na ekran.

Zasadniczo musisz zamknąć swój pierwszy formularz działający w tle i podać główną przyczynę tego błędu.

Aby zamknąć pierwszy formularz, musisz dodać te dwa wiersze kodu w drugim module obsługi zdarzenia ładowania.

    Form1 form = new Form1();
    form.Close();

To doskonale rozwiąże błąd.

Sabir Al Fateh
źródło
0

Jednym prostym rozwiązaniem jest przejście do folderu bin \ Debug, usunięcie wszystkich plików w tym folderze, a następnie odbudowanie. Jeśli to nie zadziała, zamknij program Visual Studio, a następnie przejdź do folderu bin \ Debug za pomocą eksploratora plików, po lewej stronie coner kliknij Plik> Otwórz wiersz polecenia> Otwórz wiersz polecenia jako administrator> wprowadź to polecenie „DEL / F / Q / A * ">, a następnie odbuduj

Hung Vu
źródło
0

Odpowiedź Cody Graya okazała się częściowo pomocna, ponieważ skierowała mnie do prawdziwego źródła mojego problemu, którego niektórzy z was mogą również doświadczać: wykonanie testów programu Visual Studio jest domyślnie otwarte i blokuje pliki.

Aby zatrzymać to przeważnie bezużyteczne zachowanie, postępuj zgodnie z instrukcjami z https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-rtmrel

Odznacz menu Test -> Ustawienia testu -> „Utrzymuj silnik wykonywania testów uruchomionych”

therightstuff
źródło
0

Mój problem polegał na tym, że dotnet się rozłączył i za każdym razem, gdy VS próbował utworzyć nową bibliotekę dll lub uzyskać dostęp do starej, proces dotnet łączył się z biblioteką dll i zatrzymywał program Visual Studio przed klonowaniem biblioteki dll. Rozwiązaniem jest po prostu zakończenie wszystkich zadań dotnet w menedżerze zadań (faktycznie usunie tylko martwe, jeśli próbujesz zakończyć jedno i nie zostanie zamknięte, oznacza to, że działa).

Joel Hines
źródło
0

Zamknij VisualStudio, ctrl-alt-delete, wybierz Menedżera zadań, znajdź i zakończ wszystkie procesy MSBuild - VisualStudio ma w zasadzie dość poważny błąd, w którym traci kontrolę nad swoim debuggerem, a debugger utrzymuje blokadę w pliku .pdb w debug / bin teczka. Po zakończeniu wszystkich procesów programu MSBuild (debugera) usuń folder / debug / bin i ponownie otwórz rozwiązanie w programie Visual Studio. Teraz możesz już iść. Microsoft musi to naprawić.

JakeJ
źródło
0

Otworzyłem osobne pytanie dotyczące VS 2017, które po jednej aktualizacji miało podobne zachowanie. Wydawało się, że problem jest generowany przez program antywirusowy.

Dodałem folder bin do listy wykluczeń programu antywirusowego, uruchomiłem ponownie komputer i teraz wydaje się, że działa.

meJustAndrew
źródło
0

Rozwiązałem ten problem ..

obok debugowania widać rozwijane menu z pewną konfiguracją. Domyślnie był dowolny procesor. Wybierz x86 i uruchom program, który będzie działał. Jeśli nie ma x86, przejdź do menedżera konfiguracji i dodaj x86

Sanjula De Alwis
źródło
-1

Kolejny kludge, ugh, ale jest to łatwe i działa dla mnie w VS 2013. Kliknij projekt. W panelu właściwości powinien znajdować się wpis o nazwie Plik projektu z wartością

(nazwa twojego projektu) .vbproj

Zmień nazwę projektu - na przykład dodaj -01 na końcu. Oryginalny plik .zip, który był zablokowany, nadal tam jest, ale nie ma już do niego odwołań ... więc możesz kontynuować pracę. Następnym razem, gdy komputer zostanie uruchomiony ponownie, blokada zniknie i będzie można usunąć błędny plik.

den232
źródło