Kompilacja programu Visual Studio kończy się niepowodzeniem: nie można skopiować pliku exe z obj \ debug do bin \ debug


193

Aktualizacja: przykładowy projekt odtwarzający ten błąd można znaleźć tutaj w Microsoft Connect . Przetestowałem również i zweryfikowałem, czy rozwiązanie podane w zaakceptowanej odpowiedzi poniżej działa na tym przykładowym projekcie. Jeśli to rozwiązanie nie działa, prawdopodobnie masz inny problem (który należy do osobnego pytania).


To pytanie zostało zadane wcześniej, zarówno tutaj na Stack Overflow, jak i w innych miejscach, ale żadna z sugestii, które znalazłem do tej pory, nie pomogła mi, więc muszę po prostu spróbować zadać nowe pytanie.

Scenariusz: mam prostą aplikację Windows Forms (C #, .NET 4.0, Visual Studio 2010). Ma kilka podstawowych formularzy, które dziedziczy większość innych formularzy, używa Entity Framework (i klas POCO) do dostępu do bazy danych. Nic szczególnego, nic wielowątkowego ani nic.

Problem: Przez jakiś czas wszystko było w porządku. Następnie, zupełnie nieoczekiwany, Visual Studio nie udało się skompilować, kiedy miałem uruchomić aplikację. Otrzymałem ostrzeżenie „Nie można usunąć pliku„ ... bin \ Debug \ [ProjectName] .exe ”. Dostęp do ścieżki„ ... bin \ Debug \ [ProjectName] .exe ”jest zabroniony.” i błąd „Nie można skopiować pliku„ obj \ x86 \ Debug \ [ProjectName] .exe ”do„ bin \ Debug \ [ProjectName] .exe ”. Proces nie może uzyskać dostępu do pliku„ bin \ Debug \ [ProjectName] .exe „ponieważ jest wykorzystywany w innym procesie”. (Dostaję zarówno ostrzeżenie, jak i błąd podczas uruchamiania Przebuduj, ale tylko błąd podczas uruchamiania Kompilacji - nie sądzisz, że to jest istotne?)

Rozumiem doskonale, co mówi ostrzeżenie i komunikat o błędzie: Visual Studio najwyraźniej próbuje zastąpić plik exe, jednocześnie z jakiegoś powodu blokując go. Jednak to nie pomaga mi znaleźć rozwiązania problemu ... Jedyne, co znalazłem, działa to zamknięcie programu Visual Studio i ponowne uruchomienie. Budowanie i uruchamianie działa, dopóki nie zmienię niektórych formularzy, potem znów mam ten sam problem i muszę ponownie uruchomić ... Dość frustrujące!

Jak wspomniałem powyżej, wydaje się, że jest to znany problem, więc istnieje wiele sugerowanych rozwiązań. Wymienię tylko to, co już próbowałem tutaj, aby ludzie wiedzieli, co pominąć:

  • Tworzenie nowego czystego rozwiązania i po prostu skopiuj pliki ze starego rozwiązania.
  • Dodanie następujących elementów do zdarzenia przed kompilacją projektu:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
    
  • Dodanie następujących właściwości do właściwości projektu (plik .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Jednak żaden z nich nie działał dla mnie, więc prawdopodobnie możesz zrozumieć, dlaczego zaczynam być trochę sfrustrowany. Nie wiem, gdzie jeszcze szukać, więc mam nadzieję, że ktoś mi coś da! Czy to błąd w VS, a jeśli tak, to czy jest łatka? Czy też zrobiłem coś złego, czy mam okólnik lub podobne, a jeśli tak, to jak mogę się dowiedzieć?

Wszelkie sugestie są mile widziane :)

Aktualizacja: Jak wspomniano w komentarzu poniżej, ja również sprawdzić za pomocą Process Explorer to, że faktycznie jest Visual Studio, który jest blokowanie pliku.


4
Czy sprawdziłeś, czy aplikacja zamyka się prawidłowo? Czy menedżer zadań pokazuje [ProjectName] .exe na liście procesów?
miensol

2
Miałem to już wcześniej i po prostu zmieniłem nazwę pliku na .old itp. I uruchomiłem kompilację. Nie do końca wiem, ale wiem, ale zadziałało.
codingbadger

@miensol: Tak, wydaje się poprawnie zamykać. Dostaję komunikat „Program” [1848] [Nazwa projektu] .vshost.exe: Zarządzany (v4.0.30319) ”zakończył działanie z kodem 0 (0x0).” @ Barry: zmiana nazwy pliku exe w bin \ Debug działa, ale jak powiedziałeś, nie jest to naprawdę rozwiązanie i będzie to denerwujące, że trzeba to robić za każdym razem. Trochę lepiej niż restartowanie Visual Studio ...
Julian

2
@Naliluj: Natknąłem się na ten artykuł z forum Microsoft, który wyjaśnia, że ​​może być związany z plikami zasobów. Jeśli używasz plików resx, może to dać podpowiedź.
Patrick

1
Dla potomnych miałem ten problem i został on rozwiązany przez dodanie elementu <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> do mojego pliku csproj.
ThisIsTheDave

Odpowiedzi:


117

To zabrzmi głupio, ale wypróbowałem wszystkie te rozwiązania, uruchamiając VS2010 na Windows 7. Żadne z nich nie działało oprócz zmiany nazwy i budowania, co było BARDZO żmudne co najmniej. W końcu wytropiłem winowajcę i trudno mi w to uwierzyć. Ale użyłem następującego kodu w AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Jest to dość powszechne, ale z jakiegoś powodu zmiana wersji na 2.0.0.0 sprawiła, że ​​wszystko znów działa. Nie wiem, czy jest to coś specyficznego dla systemu Windows 7 (używam go tylko przez 3-4 tygodnie), czy jest losowy, czy co, ale to naprawiło to dla mnie. Zgaduję, że VS zachowywał kontrolę nad każdym generowanym plikiem, więc wiedziałby, jak zwiększać wartości? Naprawdę nie jestem pewien i nigdy wcześniej tego nie widziałem. Ale jeśli ktoś tam również wyciąga włosy, spróbuj.


12
To jeden szalony pomysł, dam ci to;) Jeszcze bardziej szalone jest to, że faktycznie wydaje się działać! Testowałem to już kilka razy i mogę potwierdzić, że przy użyciu wersji asemblera takiej jak „2.0. *” Dostaję błąd, ale gdy zamiast tego używam „2.0.0”, działa to jak amulet! Wzywam więcej osób do przetestowania tego, a jeśli uznasz, że to działa, zagłosuj na tę odpowiedź, ponieważ jest to coś, o czym trzeba wiedzieć! Mam nadzieję, że Microsoft podejmie tę kwestię ... Dziękuję drharris :)
Julian

2
to nie działało dla mnie, kiedy ponownie uruchamiam VS, przez jakiś czas nie otrzymałem błędu. Za każdym razem, gdy
pojawia

6
fyi ... to mi nie zadziałało. Moje ustawienia zawsze były: [assembly: AssemblyVersion („1.0.0.0”)] [assembly: AssemblyFileVersion („1.0.0.0”)]
tbone

4
Jeśli obecnie masz [zespół: Montaż Wersja („1.0.0.0”)], zamień go na [zespół: Montaż Wersja („2.0.0.0”)] (tzn. „2” zamiast „1”). To zadziałało dla mnie. Chociaż nie sprawdziłem, możliwe jest, że po prostu zmiana wersji na coś innego niż to, co masz teraz, może rozwiązać ten problem.
Frederick The Fool

1
Działa również dla dll! VS mówi, że nie można skopiować biblioteki dll i po zmianie ZARÓWNO [zestaw: MontażVersion] i [zespół: MontażFileVersion ()] z 1.0. * Na 2.0.0.0, zadziałało.
AZ.

14

Ponieważ nie otrzymałem żadnej opinii na ten temat, pomyślałem, że podzielę się tym, co ostatecznie stało się moim rozwiązaniem:

Jak zasugerował Barry w komentarzu do oryginalnego postu, ręczna zmiana nazwy pliku „... bin \ Debug [ProjectName] .exe” na coś innego (np. „[ProjectName] 1.exe” ) jest jednym obejściem (I ” m jednak nie wolno samemu usuwać pliku i muszę powiedzieć, że uważam to za nieco dziwne, ponieważ można by sądzić, że ta sama blokada uniemożliwiająca usunięcie również uniemożliwiłaby zmianę nazwy ...). To nie jest dobre rozwiązanie, ale jest dość szybkie (przynajmniej po zrobieniu tego kilka razy, prawie staje się rutyną) i przynajmniej znacznie szybsze niż ponowne uruchomienie Visual Studio, co zrobiłem na początku.

Na wypadek, gdyby ktoś się zastanawiał, mógłbym również dodać, że ten problem widzę tylko częściowo losowo. Zwykle dzieje się to po wprowadzeniu pewnych zmian w trybie projektowania formularza (ale nie zawsze). Zwykle nie zdarza się to, jeśli zmieniam tylko kod logiki biznesowej lub kod niezwiązany z obrazem (ale czasami robi to ...). Rzeczywiście frustrujące, ale przynajmniej mam hack, który działa dla mnie - miejmy nadzieję, że mój następny projekt również nie napotka tego problemu ...

@ Barry: jeśli chcesz uzyskać uznanie za komentarz, opublikuj go jako odpowiedź, a ja go zaakceptuję :)


Głosowałem za tym, ponieważ tak robiłem w przeszłości. Zgadzam się, to brudne rozwiązanie, ale działa. VS miał ten problem przez kilka iteracji. Ładuję również mój projekt z katalogu sieciowego. Został w pełni zaufany, ale to nie ma znaczenia. Nie ma znaczenia, czy jest to mapowanie dysku czy UNC. Tak, stwardnienie rozsiane naprawdę musi to naprawić. Mają zamknięty błąd, mówiąc, że nie można się rozmnażać. Kulawy!
Josh Robinson

14

Znalazłem jedno proste rozwiązanie, po prostu wyłącz Usługi indeksowania systemu Windows dla folderu projektu i podfolderów


2
To również działało dla mnie. Nie jestem pewien, czy rozumiem dlaczego, ponieważ eksplorator procesów pokazał, że devenv.exe trzyma uchwyt blokujący. Niemniej jednak wyłączenie indeksowania rozwiązało problem.
Fopedush

1
@Fopedush Napotkałem ten problem z tym samym rozwiązaniem, chociaż wtedy nie widziałem tego pytania. Ta odpowiedź zawiera wyjaśnienie, dlaczego pomaga.
Darren Hale,

1
Ten zrobił to dla mnie.
Martin Capodici

12

Mam ten sam problem (MSB3021) z projektem WPF w VS2008 (w systemie Windows 7 x32). Problem pojawia się, jeśli próbuję ponownie uruchomić aplikację zbyt szybko po poprzednim uruchomieniu. Po kilku minutach plik exe sam się odblokował i mogę ponownie uruchomić aplikację. Ale taka długa pauza denerwuje mnie. Jedyną rzeczą, która naprawdę mi pomogła, było uruchomienie VS jako administratora.


1
Znalazłem ostatni raport o błędzie dotyczący tego konkretnego problemu: connect.microsoft.com/VisualStudio/feedback/details/558848/... Ten raport o błędzie dostarczył przykładowy projekt, który był w stanie odtworzyć błąd. Tam też działało rozwiązanie sugerowane przez drharrisa (zobacz obejście zamieszczone w powyższym linku, aby uzyskać krok po kroku rozwiązanie przykładowego projektu).
Julian

To jest jedyne rozwiązanie, które również działało dla mnie. Dzięki @Nailuj!
Winger

Jest to z pewnością łatwiejsze niż ponowne uruchomienie VS.
Elvedin Hamzagic,

1
„Nie znaleziono strony” dla problemu z połączeniem, czy po prostu usunęli go ze wstydu = S Czy było kiedyś opublikowane rozwiązanie / obejście tego problemu?
Coops,

9

Kiedy natknąłem się na ten problem, chodzi o fakt, że projekt, który próbuję zbudować, jest ustawiony jako projekt startowy w rozwiązaniu powodującym zablokowanie pliku .exe w folderze obj (pojawia się również w menedżerze zadań) kliknij prawym przyciskiem myszy inny projekt w swoim rozwiązaniu i wybierz ustaw projekt startowy. Spowoduje to zwolnienie blokady, usunięcie go z menedżera zadań i powinno umożliwić budowanie.


1
To działa za każdym razem dla mnie. Wydaje się, że ma to związek z procesem vshost, który jest generowany i uruchamiany dla usług
jaywayco

8

Wypróbowałem wszystkie pozostałe sugestie w odpowiedziach tutaj, z których żadna nie zadziałała. W końcu skorzystałem z Monitora procesów, aby odkryć, że mój plik .exe, którego kompilacja nie powiodła się w VS2010, został zablokowany przez proces systemowy (PID = 4). Przeszukiwanie SO w sytuacjach związanych z tym dało odpowiedź.

Podsumowując: jeśli masz wyłączoną usługę Application Experience (tak jak ja), włącz ją ponownie i uruchom. Skończyły się dwa lata pogorszenia.


+1 Wcześniej próbowałem wszystkiego innego (1. menedżer zadań, 2. eksplorator procesów, tj. Zamknij uchwyt, którego okna mi nie pozwalają, 3. Wyłącz antywirusa, 4. Wyłącz APP_DATA / Local / Microsoft / Visual Studio z usługi indeksowania Windows. ), ale ta wskazówka dotyczy: Usługa „Application Experience” jest jedyną, która uratowała mnie od uderzenia głową w ścianę. Włączyłem to i problem zniknął. Zabawne jest to, że po ponownym wyłączeniu wszystko było nadal OK. Nie miałem już żadnych problemów. Ale zdecydowanie to jedyna rzecz, która mnie ułożyła.
Tomás

Pracuj też dla mnie !!! Jedyną inną rzeczą, która działa, jest również usunięcie folderu bin przed uruchomieniem aplikacji, ale musisz zawsze usuwać przed uruchomieniem, bardzo denerwujące.
E_Blue

6

Miałem również problem bardzo podobny do tego i znalazłem przyczynę w moim przypadku, że udostępniłem folder bin \ debug jako folder współdzielony pod VMware i VMware, Explorer pod gościem VM, a może nawet antywirusem program pod gościem (choć nie sądzę, że miałem go zainstalowany) trzymał uchwyt pliku (ów).


Mam zainstalowany program Avast i dziś rano dostałem losowy błąd MVC, który mówi, że w mojej bibliotece DLL był wirus. Po błędzie nie mogłem już zbudować mojego projektu MVC. Dodałem wyjątek do osłony systemu plików Avast i wszystko znów działa.
Dusty


4

Sugeruję pobranie, Process Exploreraby dowiedzieć się, jaki dokładnie proces blokuje plik. Można go znaleźć na:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Zgadzam się - niekoniecznie VS blokuje plik. Winni mogą być za to weryfikatorzy wirusów. Spróbuj wyłączyć program antywirusowy, aby zobaczyć, czy to pomoże.
Polyfun

Przepraszam, zapomniałem wspomnieć, że już to zrobiłem. I mówi, że to jest Visual Studio (devenv.exe), który ma blokadę pliku ([ProjectName] .vshost.exe). To też mi niewiele pomaga.
Julian

@ShellShock: wyłączenie mojego antywirusa (Avast) też nie pomaga.
Julian

Dla mnie za pomocą Sysinternals ProcessExplorer widzę dojście do tego pliku, ale kiedy go klikam, żadna aplikacja go nie wyświetla, a gdy próbuję zamknąć uchwyt, pojawia się komunikat „Błąd otwierania: uchwyt jest nieważny." błąd w ProcessExplorer. Mimo to zamek nadal się utrzymuje.
tbone

4

Za pomocą programu Visual Studio nigdy nie mogłem wymyślić prostego projektu, aby odtworzyć błąd.

Moim rozwiązaniem było wyłączenie procesu hostingu Visual Studio.

Dla zainteresowanych załączyłem śledzenie uchwytu dla obrażającego uchwytu:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

jeśli widzisz na samej górze w rachubę, znajduje się link do Microsoft Connect z raportu o błędzie i przykładowy projekt, który odtwarza błąd: connect.microsoft.com/VisualStudio/feedback/details/558848/...
Julian

Wyłączenie procesu hostingu działało dla mnie. Nadal działa również po ponownym włączeniu. Spędziłem 4 godziny, próbując rozwiązać ten problem, próbując setek rozwiązań. To jedyny, który zdalnie wydawał się działać.
Drew Chapin,

4

JEŚLI TWÓJ PROBLEM NIE JEST JESZCZE ROZWIĄZANY:

Błąd programu Visual Studio to:

„Proces nie może uzyskać dostępu do pliku„ bin \ Debug ** app.exe ** ”, ponieważ jest używany przez inny proces.”

Przejdź do menedżera zadań systemu Windows (Ctrl + Shift + Esc), znajdź nazwę swojej aplikacji i wymuś jej zamknięcie przez Endprocces.


3

Oto kolejna możliwość:

Po otrzymaniu tego błędu w vs2012 / win7 poszedłem i spróbowałem usunąć plik z katalogu bin, a program explorer wskazał, że plik był używany przez XAML UI Designer.

Zamknąłem wszystkie karty, które miałem otwarte w VS, zamknąłem VS, a następnie zabiłem wszystkie procesy MSBuild w menedżerze zadań. Wreszcie po ponownym uruchomieniu VS udało mi się zbudować rozwiązanie.


i inna możliwa przyczyna:

Zauważyłem inną możliwą przyczynę tego problemu. Po dokonaniu refaktoryzacji kodu, przenoszeniu projektów do rozwiązania i z niego, moje odwołania do projektów nie odwoływały się już do projektów w rozwiązaniu zgodnie z oczekiwaniami.

To studio wizualne wprowadza w błąd, myśląc, że może jednocześnie budować niektóre projekty, tworząc w ten sposób blokady plików.

EDYCJA: Miałem to już kilka razy, nawet ostatnio z VS2012 i naprawia to, gdy ustawię kolejność kompilacji na prawidłowe zależności, zabijam wszelkie procesy msbuild, które VS pozostawił uruchomiony, a następnie ponownie uruchamiam VS. Zabijam procesy msbuild tylko dla pewności, ale zamknięcie VS również powinno je zabić.

To, co zwykle robię, aby to spowodować, to refaktoryzacja projektu tak, aby opierał się on na innym projekcie w ramach rozwiązania, do którego nie odwoływał się przy ostatniej kompilacji. Czasami wydaje się to mylić VS i nie aktualizuje kolejności kompilacji.

Aby sprawdzić kolejność kompilacji: Kliknij prawym przyciskiem myszy Rozwiązanie w Eksploratorze rozwiązań i wybierz „Kolejność kompilacji projektu ...” i sprawdź, czy zależności są odpowiednio odnotowane dla każdego projektu.


Ostatnio doświadczyliśmy tego w projekcie WinPhone 8. W niewytłumaczalny sposób przyczyną było użycie typu Tuple. Po usunięciu kodu używającego krotki problem zniknął. Dodaj kod z powrotem problem powrócił.
Seamus

Miałem ten sam problem z VS2012, zamknięcie VS nie załatwiło sprawy
musiałem

Używam VS 2013 i byłem w stanie po prostu zabić proces „XDesProc.exe * 32” (Microsoft Visual Studio XAML UI Designer) w menedżerze zadań przed każdą kompilacją i to załatwiło sprawę. Nie ma potrzeby ponownego uruchamiania VS, ponieważ projektant interfejsu XAML wydaje się ładować ponownie za każdym razem, gdy otwierasz plik * .xaml w widoku projektu.
Tim Sexton

3

Uruchom ponownie usługi IIS - może to być proces dołączony do debugera


3

Wyłącz program antywirusowy i spróbuj. Miałem również do czynienia z tym problemem ... ale w moim przypadku program antywirusowy blokował moją aplikację, kiedy wyłączałem program antywirusowy, został rozwiązany.


3

Napotkałem ten sam błąd.

Rozwiązałem problem, usuwając całą zawartość folderów bin wszystkich zależnych projektów / bibliotek.

Ten błąd występuje głównie z powodu zmian wersji.



1

Najpierw wykonaj proste czynności.

Sprawdź, czy część rozwiązania nie jest zablokowana przez uruchomiony proces.

Na przykład uruchomiłem „InstallUtil” w mojej usłudze Windows (którą zwykle testuję jednostkowo z konsoli).

Spowodowało to zablokowanie niektórych moich bibliotek DLL w folderze bin projektu usługi systemu Windows. Kiedy dokonałem przebudowy, otrzymałem wyjątek w tym numerze.

Zatrzymałem usługę Windows, przebudowałem ją i udało się.

Sprawdź Menedżera zadań Windows dla swojej aplikacji, zanim wykonasz jakiekolwiek kroki w tym temacie.

Kiedy więc usłyszysz kroki, pomyśl, że konie to nie zebry! (od przyjaciela studenta medycyny)


1

Miałem ten sam problem. Powiedział, że nie można skopiować z bin \ debugowania do obj .....

Kiedy buduję projekt internetowy, znalazłem, że wszystkie moje dll były w folderze bin, a nie w bin \ debug. Podczas publikowania vs szukałem plików w bin \ debug. Więc otworzyłem plik projektu WWW w edytorze i szukam instancji bin \ debug i znalazłem wszystkie dll wymienione jako bin \ debug \ mylibrary.dll. Usunąłem wszystkie \ debugowanie ze ścieżki i opublikowałem ponownie. Tym razem vs udało się znaleźć wszystkie dll w folderze bin i publikacja powiodła się.

Nie mam pojęcia, jak zmieniła się ta ścieżka w pliku projektu WWW.

Spędziłem ponad 5 godzin debugując to i w końcu sam znalazłem rozwiązanie.

To jest właściwa odpowiedź .


1

Jeśli żadna z powyższych czynności nie działa, a Ty tworzysz aplikację konsolową:

Spróbuj wpisać dowolny znak w Program.cs, a następnie usuń go. Nie mam pojęcia, dlaczego to działa, ale wydaje się, że rozwiązuje problem „Nie można skopiować” za każdym razem.


1

Jest to zwykle spowodowane przez Avast.

Zwykle mogę uruchamiać moje projekty niezależnie od wersji, ale podczas debugowania dość regularnie kończy się niepowodzeniem.

Właśnie dodałem wykluczenie do folderu moich projektów i problem wydaje się znikać. Zakładam, że przyczyną tego może być również inne oprogramowanie antywirusowe.


1

Zmiana nazwy pliku .exe i .pub działała dla mnie, ale była bardzo nudna. Mam również problem z edycją podczas sesji debugowania. Wreszcie przeszedłem na stronę Advanced Security Setting, zgodnie z:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMonikerRAM%2. % 3dV4.0% 22% 29 & rd = true

Odznaczam, a następnie ponownie zaznaczam pole wyboru „Włącz ustawienia zabezpieczeń ClickOnce”. Od kilku dni jest bez problemów ....


1

Dla mnie było to spowodowane posiadaniem wiersza polecenia otwartego w folderze docelowym ( C:\users\username\source\repos\project\project\bin\debug\app.publish).

Nie jestem pewien, dlaczego DEBUGGING wymaga dostępu do folderu publikowania, ale zamknięcie okna poleceń rozwiązało problem.


1

W przypadku, gdy ktoś napotyka na to podczas próby debugowania testu jednostkowego lub uruchomienia testu jednostkowego, musiałem zabić następujące dwa procesy, aby zwolnić plik:

procesy do zabicia.


0

Wypróbowałem kilka rozwiązań, które podałeś, ale czasami nadal pojawia się ten błąd. Jestem pewien, że mój proces nie działa, a kiedy próbuję usunąć plik wykonywalny za pomocą przeglądarki Internet Explorer, jest on usuwany z listy plików, ale następnie naciskam F5 i voila, plik jest z powrotem. W ogóle nie został usunięty.

Ale jeśli usunę plik za pomocą TotalCommander, plik exe zostanie faktycznie usunięty i mogę pomyślnie zbudować projekt.

Korzystam z systemu Windows 7 x64 i 32-bitowego programu Total Commander 7.56a.


0

Żadna z pozostałych odpowiedzi nie działała dla mnie, ale wydaje się, że zamknięcie wszystkich otwartych kart w Visual Studio rozwiązało problem.


0

Wiem, że to bardzo stare pytanie, ale ostatnio napotkałem błąd „nie można skopiować z obj do bin” w VS 2012. Za każdym razem, gdy próbowałem odbudować określony projekt, otrzymałem wiadomość. Jedynym rozwiązaniem było wyczyszczenie przed każdą przebudową.

Po wielu badaniach okazało się, że w jednym z moich plików miałem niepełne ostrzeżenie o pragmie, które nie uniemożliwiło powodzenia kompilacji, ale w jakiś sposób mylło VS z utrzymywaniem zablokowanych plików.

W moim przypadku na górze pliku miałem następujące elementy:

#pragma warning(

Otóż ​​to. Wydaje mi się, że próbowałem coś zrobić dawno temu, rozproszyłem się i nigdy nie zakończyłem procesu, ale ostrzeżenia VS dotyczące tej konkretnej linii zostały zgubione. W końcu zauważyłem ostrzeżenie, usunąłem linię i odbudowałem działa za każdym razem od tego czasu.


0

Kiedy napotkałem podobny problem, jedyne, co wydawało się działać, to:

  • Kliknij projekt prawym przyciskiem myszy, przejdź do Ustawień i upewnij się, że kompilacje zarówno debugowania, jak i wersji docelowej mają te same ustawienia lub zawierają ustawienia, które aplikacja próbuje załadować lub zapisać.
  • Usuwanie folderu C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Upewniając się, że żadne pliki, które tam miałem, nie zostały uznane za „zablokowane”. Klikając prawym przyciskiem myszy pliki dołączone do mojego projektu, zdałem sobie sprawę, że jedna ikona została faktycznie zablokowana i uznana za złą, ponieważ została pobrana z Internetu. Musiałem kliknąć przycisk Odblokuj (na przykład sprawdź to: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - „Ten plik pochodzi z innego komputera i może zostać zablokowany, aby pomóc chroń ten komputer. ”).

0

W przypadku usług Windows korzystających z WCF zakończyłem proces hosta WFC i zadziałał. Nienawidzę tego, kiedy to się dzieje, a czasami zdarza się to losowo.


0

Moje rozwiązanie nie ma nic wspólnego z wersjami, blokowaniem procesów, restartowaniem lub usuwaniem plików.

Problem był spowodowany niepowodzeniem kompilacji i niepoprawnym błędem. Rzeczywistym problemem była wada projektowa:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Po zmianie zakresu „a” na poza funkcję lub po nieużywaniu „a” później Task.Factory.StartNew();byłem w stanie zbudować ponownie.

Stało się tak podczas korzystania z VS2012 Update 4 na Windows7x64 sp1.

Komunikat o błędzie:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): błąd MSB3030: Nie można skopiować pliku „obj \ x86 \ Debug \ xxx.exe”, ponieważ nie został znaleziony .


0

Znalazłem z VS2013 regularnie otrzymuję ten błąd. Coś, co wydaje się działać całkiem dobrze, to wykonać Przebuduj Rozwiązanie przed próbą uruchomienia aplikacji. Przekonałem się, że czasami CZYSZCZENIE działa, ale Wydaje się, że Rozwiązanie Przebudowy działa bardziej konsekwentnie.

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.