Visual Studio 빌드 실패 : obj \ debug에서 bin \ debug로 exe 파일을 복사 할 수 없음

업데이트 : 이 버그를 재현하는 샘플 프로젝트 는 Microsoft Connect에서 찾을 수 있습니다 . 또한 아래의 대답에 제시된 솔루션이 해당 샘플 프로젝트에서 작동하는지 테스트하고 확인했습니다 . 이 방법으로 문제가 해결되지 않으면 다른 문제가있을 수 있습니다 (별도의 질문에 속함).

이것은 이전에 스택 오버플로와 다른 장소에서 묻는 질문이지만 지금까지 찾은 제안 중 어느 것도 도움이되지 않았으므로 새로운 질문을 시도해야합니다.

시나리오 : 간단한 Windows Forms 응용 프로그램 (C #, .NET 4.0, Visual Studio 2010)이 있습니다. 여기에는 대부분의 다른 양식이 상속하는 몇 가지 기본 양식이 있으며 데이터베이스 액세스를 위해 Entity Framework (및 POCO 클래스)를 사용합니다. 공상도없고 멀티 스레딩도 없습니다.

문제 : 한동안은 괜찮 았습니다. 그런 다음 응용 프로그램을 시작하려고 할 때 Visual Studio를 빌드하지 못했습니다. "파일 '... bin \ Debug \ [ProjectName] .exe'을 (를) 삭제할 수 없습니다. '... bin \ Debug \ [ProjectName] .exe'경로에 대한 액세스가 거부되었습니다. ' 라는 경고가 표시 됩니다." 및 오류 파일을 복사 할 수 "없습니다 'OBJ \ 86 \ 디버그 \ [프로젝트 이름] .EXE'에서 '빈 \ 디버그 \ [프로젝트 이름] .EXE'. 프로세스가 파일 '빈 \ 디버그 \에 액세스 할 수 없습니다 [프로젝트 이름] .EXE "다른 프로세스에서 사용 중이기 때문입니다." (Rebuild를 실행할 때 경고와 오류가 모두 발생하지만 Build를 실행할 때만 오류가 발생한다고 생각하지 않습니까?)

경고 및 오류 메시지의 내용을 완벽하게 이해합니다 .Visual Studio는 exe 파일을 덮어 쓰려고하지만 동시에 어떤 이유로 든 파일을 잠그려고합니다. 그러나 이것은 문제에 대한 해결책을 찾는 데 도움이되지 않습니다 ... 내가 찾은 유일한 것은 Visual Studio를 종료하고 다시 시작하는 것입니다. 양식을 변경하고 나서 다시 같은 문제가 발생하여 다시 시작해야 할 때까지 빌드 및 실행이 작동합니다.

위에서 언급했듯이 이것은 알려진 문제인 것 같으므로 제안 된 솔루션이 많이 있습니다. 내가 이미 시도한 것을 나열하면 사람들이 건너 뛸 것을 알 수 있습니다.

• 새로운 깨끗한 솔루션을 만들고 이전 솔루션에서 파일을 복사하십시오.

• 프로젝트의 사전 빌드 이벤트에 다음을 추가하십시오.

  if exist "$(TargetPath).locked" del "$(TargetPath).locked"
     if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  

• 프로젝트 속성 (.csproj 파일)에 다음을 추가합니다.

  <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

그러나 그들 중 누구도 나를 위해 일하지 않았으므로 아마도 내가 약간 좌절하기 시작한 이유를 알 수 있습니다. 어디를 봐야할지 모르겠어요. 누군가 내게 무언가를 줄 수 있기를 바랍니다! 이것은 VS의 버그입니까, 그렇다면 패치가 있습니까? 아니면 내가 잘못했거나 순환 참조 또는 이와 유사한 것이 있습니까? 그렇다면 어떻게 알 수 있습니까?

모든 제안은 높이 평가됩니다 :)

업데이트 : 마찬가지로 코멘트에 언급 아래, 나는 또한 실제로 그 과정 Explorer를 사용하여 검사 한 것입니다 파일을 잠그고 비주얼 스튜디오.

이것은 어리석게 들릴지 모르지만 Windows 7에서 VS2010을 실행하여 이러한 모든 솔루션을 시도했습니다. 이름을 바꾸고 건물을 제외하고는 아무 것도 지루하지 않았습니다. 결국, 나는 범인을 추적했고, 믿기 어렵다는 것을 알게되었습니다. 하지만 AssemblyInfo.cs에서 다음 코드를 사용하고있었습니다 ...

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

이것은 매우 일반적이지만 어떤 이유로 버전을 2.0.0.0으로 변경하면 다시 작동합니다. Windows 7 관련 항목인지 (3-4 주 동안 만 사용 했음) 또는 무작위인지 또는 무엇인지 알지 못하지만 나를 위해 수정했습니다. VS가 생성 된 각 파일에 대한 핸들을 유지하고 있다고 생각합니다. 그래서 물건을 늘리는 방법을 알고 있습니까? 나는 확실하지 않으며 전에 이런 일이 일어나는 것을 본 적이 없다. 그러나 다른 사람이 머리카락을 뽑은 경우 시도해보십시오.

이 문제에 대한 더 이상의 피드백을 얻지 못했기 때문에 결국 내 솔루션이 된 것을 공유한다고 생각했습니다.

Barry가 원래 게시물에 대한 주석에서 제안한 것처럼 수동으로 '... bin \ Debug [ProjectName] .exe'의 이름 을 다른 이름 (예 : '[ProjectName] 1.exe' )으로 바꾸는 것은 한 가지 해결 방법입니다 (I ' m 그러나 파일을 직접 삭제할 수는 없으며 삭제를 방지하는 동일한 잠금도 이름 바꾸기를 방해한다고 생각하는 것처럼 조금 이상하다고 말할 수 있습니다.) 좋은 해결책은 아니지만 (적어도 두 번 수행 한 후 거의 일상이됩니다) 합리적이고 빠르며 적어도 처음에는 Visual Studio를 다시 시작하는 것보다 훨씬 빠릅니다.

누군가 궁금해하는 경우 에도이 문제를 반 무작위로 볼 수 있다고 덧붙일 수도 있습니다. 일반적으로 양식의 디자인 모드에서 일부 변경을 수행 한 후에 발생합니다 (항상 그런 것은 아님). 비즈니스 논리 코드 또는 비 시각 관련 코드 만 변경하면 일반적으로 발생하지 않습니다 (그러나 때로는 그렇지 않습니다 ...). 실제로 실망 스럽지만 적어도 나에게 도움이되는 해킹이 있습니다. 다음 프로젝트 가이 문제에 직면하지 않기를 바랍니다.

@ 배리 : 귀하의 의견에 대한 신용을 얻고 싶다면 언제든지 답변으로 게시하고 받아 들일 것입니다 :)

하나의 간단한 해결책을 찾았습니다. 프로젝트 폴더 및 하위 폴더에 대해 Windows 인덱싱 서비스를 비활성화하십시오.

VS2008 (Windows 7 x32)의 WPF 프로젝트와 동일한 문제 (MSB3021)가 있습니다. 이전 실행 후 응용 프로그램을 너무 빨리 다시 실행하려고하면 문제가 나타납니다. 몇 분 후 exe 파일이 자체적으로 잠금 해제되고 응용 프로그램을 다시 실행할 수 있습니다. 그러나 그러한 긴 일시 정지는 나를 화나게합니다. 정말 도움이 된 유일한 것은 VS를 관리자로 실행하는 것입니다.

이 문제가 발생하면 빌드하려는 프로젝트가 obj 폴더의 .exe를 잠그는 솔루션의 시작 프로젝트로 설정되어 있다는 사실과 관련이 있습니다 (작업 관리자에도 나타납니다). 솔루션에서 다른 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 시작 프로젝트 설정을 선택하십시오. 그러면 잠금이 해제되고 작업 관리자에서 잠금이 해제되어 빌드 할 수 있습니다.

나는 여기의 답변에서 다른 모든 제안을 시도했지만 그중 아무것도 효과가 없었습니다. 결국 Process Monitor를 사용하여 VS2010이 빌드하지 못한 .exe가 시스템 프로세스에 의해 잠겨 있음을 발견했습니다 (PID = 4). 이와 관련된 상황을 SO로 검색 하면이 답변 이 산출되었습니다 .

요약 : Application Experience 서비스를 비활성화 한 경우 (내처럼) 다시 활성화 한 후 시작하십시오. 2 년간의 악화가 끝났습니다.

나도 이것과 매우 비슷한 문제가 있었고 내 경우에는 bin \ debug 폴더를 VMware 및 VMware, VMWare, VM 게스트 아래의 탐색기 또는 안티 바이러스에서 공유 폴더로 사용할 수있게했기 때문에 게스트 아래의 프로그램 (하나는 설치되지 않은 것으로 생각되지만)은 파일에 대한 핸들을 잡고 있습니다.

"Visual Studio 호스팅 프로세스 사용"사용 안 함

Process Explorer어떤 프로세스가 파일을 잠그고 있는지 정확하게 찾으려면 다운로드 를 제안 합니다. 다음에서 찾을 수 있습니다.

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

Visual Studio를 사용하면 오류를 재현하는 간단한 프로젝트를 만들 수 없었습니다.

내 솔루션은 Visual Studio Hosting 프로세스를 비활성화하는 것이 었습니다.

관심있는 사람들을 위해 문제가되는 핸들에 대한 핸들 추적을 첨부했습니다.

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

문제가 아직 해결되지 않은 경우 :

비주얼 스튜디오의 오류는 다음과 같습니다

"이 프로세스는 다른 프로세스에서 사용 중이기 때문에 'bin \ Debug ** app.exe **'파일에 액세스 할 수 없습니다."

따라서 창의 작업 관리자 (Ctrl + Shift + Esc)로 이동하여 응용 프로그램 이름을 찾은 다음 Endprocces로 강제로 닫으십시오.

다른 가능성이 있습니다.

vs2012 / win7 에서이 오류를 수신 한 후 bin 디렉토리에서 파일을 삭제하려고 시도했으며 탐색기는 파일이 XAML UI 디자이너에서 사용 중임을 나타냅니다.

VS에서 열었던 모든 탭을 닫고 VS를 닫은 다음 작업 관리자에서 모든 MSBuild 프로세스를 강제 종료했습니다. 마지막으로 VS를 다시 시작한 후 솔루션을 빌드 할 수있었습니다.

그리고 다른 가능한 원인 :

이 문제의 또 다른 원인을 발견했습니다. 코드 리팩토링을 수행하고 프로젝트를 솔루션 안팎으로 이동 한 후 프로젝트 참조가 더 이상 솔루션의 프로젝트를 예상 한대로 참조하지 않았습니다.

이 비주얼 스튜디오는 일부 프로젝트를 동시에 빌드 할 수 있다고 생각하여 파일 잠금을 생성한다고 오해했습니다.

편집 : VS2012를 사용하여 최근 몇 번이 나이 문제가 발생했으며 빌드 순서를 올바른 종속성으로 설정하고 VS가 실행중인 msbuild 프로세스를 종료 한 다음 VS를 다시 시작하면 문제가 해결됩니다. 확실하게 msbuild 프로세스를 종료하지만 VS를 닫으면 프로세스도 종료됩니다.

내가 일반적 으로이 작업을 수행하는 것은 마지막 빌드에서 참조하지 않은 솔루션 내의 다른 프로젝트에 의존하도록 프로젝트를 리팩터링하는 것입니다. 이것은 때때로 VS를 혼란스럽게하는 것처럼 보이고 빌드 순서를 업데이트하지 않습니다.

빌드 순서를 확인하려면 : 솔루션 탐색기에서 솔루션을 마우스 오른쪽 단추로 클릭하고 "프로젝트 빌드 순서 ..."를 선택하고 각 프로젝트에 대한 종속성이 올바르게 표시되는지 확인하십시오.

IIS 다시 시작-디버거에 연결된 프로세스 일 수 있음

바이러스 백신을 비활성화하고 시도하십시오. 나는 또한 그 문제에 직면하고 있었지만 안티 바이러스가 비활성화되면 바이러스 백신으로 인해 응용 프로그램이 차단되었습니다.

나는 같은 오류에 직면했다.

모든 종속 프로젝트 / 라이브러리 의 bin 폴더 내용을 모두 삭제하여 문제를 해결했습니다 .

이 오류는 주로 버전 변경으로 인해 발생합니다.

이것은 Microsoft의 커뮤니티 버그보고 사이트 인 Connect에 여러 번 제출되었습니다. 참고로,이 버그는 2003 년 이후 Visual Studio에 영향을 미쳤으며 RTM 이후에 수정되었다고 생각합니다. :( 참조 중 하나는 다음과 같습니다.

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

간단한 일을 먼저하십시오.

실행중인 프로세스가 솔루션의 일부를 잠그지 않았는지 확인하십시오.

예를 들어, Windows 서비스 (일반적으로 콘솔에서 단위 테스트)에서 "InstallUtil"을 실행했습니다.

이로 인해 Windows 서비스 프로젝트의 bin 폴더에 일부 dll이 잠겼습니다. 내가 재건 할 때이 문제에서 예외가 발생했습니다.

Windows 서비스를 중지하고 다시 빌드하면 성공했습니다.

이 문제의 고급 단계를 수행하기 전에 응용 프로그램의 Windows 작업 관리자를 확인하십시오.

따라서 발자국 소리가 들리면 말이 얼룩말이 아니라고 생각하십시오! (의대생 친구로부터)

나는 같은 문제가 있었다. bin \ debug에서 obj ....로 복사 할 수 없다고 말했습니다.

웹 프로젝트를 빌드 할 때 내 dll이 bin \ debug가 아닌 bin 폴더에 있음을 알았습니다. 게시하는 동안 bin \ debug에서 파일을 찾고있었습니다. 그래서 편집기에서 웹 프로젝트 파일을 열고 bin \ debug 인스턴스를 찾은 후 모든 dll이 bin \ debug \ mylibrary.dll로 언급되었습니다. 경로에서 모든 \ debug를 제거하고 다시 게시했습니다. 이번에는 vs 폴더에서 모든 dll을 찾아서 게시 할 수있었습니다.

웹 프로젝트 파일 에서이 경로가 어떻게 바뀌 었는지 전혀 모르겠습니다.

나는 이것을 디버깅하는 데 5 시간 이상을 보냈고 마침내 스스로 해결책을 찾았다.

이것이 정답 입니다.

위의 방법 중 어느 것도 작동하지 않고 콘솔 응용 프로그램을 개발중인 경우 :

Program.cs에 문자를 입력 한 다음 삭제하십시오. 왜 이것이 작동하는지 모르겠지만 매번 '복사 할 수 없습니다'문제를 해결하는 것 같습니다.

이것은 Avast에 의해 일반적으로 발생합니다.

일반적으로 릴리스에서 프로젝트를 실행할 수 있지만 디버그에서 실행하면 정기적으로 실패합니다.

프로젝트 폴더에 대한 제외를 추가하면 문제가 사라지는 것 같습니다. 다른 바이러스 백신 소프트웨어로 인해 발생할 수도 있다고 가정합니다.

.exe 및 .pub 파일의 이름을 바꾸면 나에게 도움이되었지만 실제로 지루합니다. 또한 디버그 세션 중에 편집 할 수없는 문제에 직면합니다. 마지막으로 다음과 같이 고급 보안 설정 페이지로 이동했습니다.

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%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION % 3dV4.0 % 22 % 29 & rd = true

"ClickOnce 보안 설정 사용"확인란을 선택 취소 한 다음 다시 선택하십시오. 며칠 동안 문제가 없었습니다 ....

나를 위해 이것은 대상 폴더 ( C:\users\username\source\repos\project\project\bin\debug\app.publish) 에서 명령 프롬프트를 열어서 발생했습니다 .

DEBUGGING이 게시 폴더에 액세스해야하는 이유를 잘 모르지만 명령 창을 닫으면 문제가 해결되었습니다.

단위 테스트를 디버그하거나 단위 테스트를 실행하려고 할 때 누군가이 문제가 발생하는 경우 파일을 해제하려면 다음 두 프로세스를 종료해야했습니다.

제공 한 몇 가지 솔루션을 시도했지만 때때로이 오류가 계속 발생합니다. 내 프로세스가 실행 중이 아니라고 인터넷 탐색기로 실행 파일을 삭제하려고하면 파일 목록에서 제거되지만 F5와 voila를 누르면 파일이 다시 시작됩니다. 전혀 삭제되지 않았습니다.

그러나 TotalCommander를 통해 파일을 삭제하면 exe 파일이 실제로 삭제되고 프로젝트를 성공적으로 빌드 할 수 있습니다.

Windows 7 x64 및 Total Commander 7.56a 32 비트를 사용하고 있습니다.

다른 답변은 저에게 효과적이지 않았지만 Visual Studio에서 열린 탭을 모두 닫으면 문제가 해결 된 것으로 보입니다.

나는 이것이 매우 오래된 질문이라는 것을 알고 있지만 최근에 VS 2012에서 "obj에서 bin으로 복사 할 수 없습니다"오류가 발생했습니다. 특정 프로젝트를 다시 작성하려고 할 때마다 메시지가 나타납니다. 유일한 해결책은 모든 재 구축 전에 깨끗하게하는 것입니다.

많은 조사를 한 결과 내 파일 중 하나에 불완전한 pragma 경고 문구가있어 컴파일이 성공하지 못했지만 VS가 파일을 잠그는 데 혼란을 겪었습니다.

필자의 경우 파일 맨 위에 다음이 있습니다.

#pragma warning(

그게 다야. 나는 잠시 동안 무언가를 시도했지만 산만 해져서 프로세스를 끝내지 않았지만 그 특정 라인에 대한 VS 경고가 셔플에서 사라졌습니다. 결국 나는 경고를 보았고, 그 줄을 제거하고 그 이후로 매번 작동합니다.

비슷한 문제에 직면했을 때 작동하는 유일한 것은 다음과 같습니다.

• 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 설정으로 이동하여 디버그 및 릴리스 빌드가 동일한 설정을 대상으로하는지 또는 응용 프로그램이로드하거나 저장하려고하는 설정이 있는지 확인하십시오.
• C : \ Users (YourUserAccount) \ AppData \ Local (YourAppName) 폴더를 삭제합니다.
• 내가 가진 파일이 "차단됨"으로 간주되지 않았는지 확인하십시오. 프로젝트에 포함 된 파일을 마우스 오른쪽 버튼으로 클릭하면 하나의 아이콘이 실제로 차단되어 인터넷에서 다운로드 되었기 때문에 불량으로 간주됩니다. 차단 해제 버튼을 클릭해야했습니다 (예 : http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png- "이 파일은 다른 컴퓨터에서 가져 왔 으므로 도움이되지 않을 수 있습니다.) 이 컴퓨터를 보호하십시오. ").

WCF를 사용하는 Windows 서비스의 경우 WFC 호스트 프로세스를 종료하고 작동했습니다. 이것이 일어날 때 나는 그것을 싫어하고 때때로 무작위로 발생합니다.

내 솔루션은 버전, 프로세스가 잠기거나 다시 시작하거나 파일을 삭제하는 것과 관련이 없습니다.

문제는 실제로 빌드가 실패하여 정확한 오류가 발생하지 않았기 때문입니다. 실제 문제는 디자인 결함이었습니다.

// 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(); 

"a"의 범위를 함수 외부로 변경하거나 이후에 "a"를 사용하지 않으면 Task.Factory.StartNew();다시 빌드 할 수있었습니다.

이것은 Windows7x64 sp1에서 VS2012 업데이트 4를 사용할 때 발생했습니다.

에러 메시지:

C : \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5) : 오류 MSB3030 : "obj \ x86 \ Debug \ xxx.exe"파일을 찾을 수 없으므로 파일을 복사 할 수 없습니다. .

VS2013 에서이 오류가 정기적으로 발생합니다. 합리적으로 잘 작동하는 것으로 보이는 것은 응용 프로그램을 실행하기 전에 Rebuild Solution을 수행하는 것입니다. CLEAN을 수행하는 것이 때로는 효과가 있지만 Rebuild Solution이 더 일관되게 작동하는 것으로 나타났습니다.