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

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.

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>}

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"

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

Pracował dla mnie!

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

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.

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.

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.

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”.

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;

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.

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.

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

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

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.

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 !!!

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)

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.

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.

Polecenie przed kompilacją

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

Pomógł

[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.

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

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”

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).

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ć.

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.

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

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.