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

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.

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.

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ę :)

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

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.

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.

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 tę 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.

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

Wyłącz „Włącz proces hostowania programu Visual Studio”

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

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

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.

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

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.

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.

Zostało to złożone wiele razy w Connect, witrynie zgłaszania błędów w społeczności Microsoft. Do twojej wiadomości, uważam, że ten błąd dotyczy Visual Studio od 2003 roku i został naprawiony po RTM za każdym razem. :( Jeden z odnośników jest następujący:

https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0

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)

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

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.

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.

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

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.

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:

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.

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

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.

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

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.

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 .

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.