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 파일을 덮어 쓰려고하지만 어떤 이유로 인해 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의 Explorer 또는 안티 바이러스에서 공유 폴더로 사용 가능하게 만들었 기 때문입니다. 게스트 아래의 프로그램 (하나는 설치되지 않은 것으로 생각되지만)은 파일에 대한 핸들을 잡고있었습니다.
"Visual Studio 호스팅 프로세스 사용"사용 안 함 
문제가 아직 해결되지 않은 경우 :
비주얼 스튜디오의 오류는 다음과 같습니다
"이 프로세스는 다른 프로세스에서 사용 중이기 때문에 'bin \ Debug ** app.exe **'파일에 액세스 할 수 없습니다."
따라서 창의 작업 관리자 (Ctrl + Shift + Esc)로 이동하여 응용 프로그램 이름을 찾은 다음 Endprocces로 강제로 닫으십시오.
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
다른 가능성이 있습니다.
vs2012 / win7 에서이 오류를 수신 한 후 bin 디렉토리에서 파일을 삭제하려고 시도했으며 탐색기는 파일이 XAML UI 디자이너에서 사용 중임을 나타냅니다.
I closed all the tabs I had open in VS, closed VS, then made sure to kill all MSBuild processes in taskmanager. Finally, after restarting VS I was able to build the solution.
and another possible cause:
I have noticed another possible cause for this issue. After doing some code refactoring, moving projects in and out of a solution, my project references were no longer referencing the projects in the solution as expected.
This mislead visual studio to think it could build some projects concurrently, thus creating the file locks.
EDIT: I have had this happen on a few occasions even recently with VS2012 and it does fix it once I set the build order to the correct dependencies, kill any msbuild processes that VS left running, and then restart VS. I kill the msbuild processes just to be sure, but closing VS should kill them off too.
What I usually do to cause this is refactor a project such that it relies on another project within the solution that it wasn't referencing on last build. This sometimes seem to confuse VS and it doesn't update the build order.
To check build order: Right-click the Solution in the Solution Explorer and select "Project Build Order..." and verify that dependencies are properly noted for each project.
Restart IIS- could be a process attached to the debugger
Disable antivirus and try. I was also facing that problem... but in my case antivirus was blocking my application when I disabled antivirus it resolved.
I faced the same error.
I solved the problem by deleting all the contents of bin folders of all the dependent projects/libraries.
This error mainly happens due to version changes.
I'd suggest download Process Explorer to find out exactly what process is locking the file. It can be found at:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
This has been filed multiple times on Connect, Microsoft's community bug reporting site. FYI, I believe this bug has afflicted Visual Studio since 2003 and has been fixed after RTM each time. :( One of the references is as follows:
If none of the above works, and you are developing a console application:
Try typing any character into Program.cs, then delete it. I have no idea why this works, but it seems to resolve 'Unable to copy' problem every time.
This is rather commonly caused by Avast.
I can usually run my projects in Release regardless, but when running in debug it would pretty regularly fail.
I just add an exclusion for my projects folder and the problem seems to go away. I assume this might also be cause by other antivirus software.
Renaming the .exe and .pub file worked for me, but really tedious. I also face the problem that I could not do editing during a debug session. Finally I went to the Advanced Security Setting Page, as per:
I un-select then re-select the "Enable ClickOnce security settings" checkbox. It's been problem free for some days now....
For me this was being caused by having a command prompt open in the targeted folder (C:\users\username\source\repos\project\project\bin\debug\app.publish).
Not sure why DEBUGGING requires access to the publish folder, but closing the command window solved the issue for me.
In case somebody is running into this while trying to debug a Unit Test or Run a unit test I had to kill the following two processes in order for it to release the file:
I tried several solutions that you provided, but occasionally I still receive this error. I am positive that my process is not running, and when i try to delete the executable file with internet explorer it is removed from the file list, but then I press F5 and voila, the file is back. It has not been deleted at all.
But if i delete the file through the TotalCommander, the exe file is actually deleted and I can successfully build the project.
I am using windows 7 x64 and total commander 7.56a 32 bit.
None of the other answers worked for me but closing all open tabs in Visual Studio appears to have solved the problem.
I know this is a very old question, but I recently experienced the "cannot copy from obj to bin" error in VS 2012. Every single time I tried to rebuild a certain project, I got the message. The only solution was to do a clean before every rebuild.
After much investigating, it turns out I had an incomplete pragma warning statement in one of my files that did not prevent the compilation from succeeding, but was somehow confusing VS into keeping the file(s) locked.
In my case, I had the following at the top of the file:
#pragma warning(
That's it. I guess I was attempting to do something a while back and got distracted and never finished the process, but the VS warnings about that particular line were lost in the shuffle. Eventually I noticed the warning, removed the line, and rebuild works every time since then.
Do the simple things first.
Check that part of your solution is not locked by a running process.
For instance, I ran "InstallUtil ' on my windows service(which I normally unit test from a console).
This locked some of my dlls in the bin folder of the windows service project. When I did a rebuild I got the exception in this issue.
I stopped the windows service, rebuilt and it succeeded.
Check Windows Task Manager for your Application, before doing any of the advance steps in this issue.
So when you hear footsteps, think horses not zebras! (from medical student friend)
When I faced a similar issue, the only thing that seemed to work was:
- Right click the project, going to Settings, and making sure that both Debug and Release builds target the same settings, or have the settings in there that the application tries to load or save.
- Deleting the C:\Users(YourUserAccount)\AppData\Local(YourAppName) folder.
- Making sure that no files that I had in there were considered "Blocked". Right-clicking my project's included files, I realized that one icon was actually blocked and considered bad because it was downloaded from the internet. I had to click the Unblock button (in example, check this out: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "This file came from another computer and might be blocked to help protect this computer.").
For Windows Services using WCF, I ended the WFC host process and it worked. I hate it when this happens, and it happens randomly at times.
My solution has nothing to do with versions, processes being locked, restarting, or deleting files.
The problem was actually due to the build failing, and not giving the correct error. The actual problem was a design flaw:
// 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();
After changing the scope of "a" to outside the function, or not using "a" after Task.Factory.StartNew();, I was able to build again.
This happened when using VS2012 Update 4 on Windows7x64 sp1.
Error message:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3390,5): error MSB3030: Could not copy the file "obj\x86\Debug\xxx.exe" because it was not found.
I have found with VS2013 I get this error regularly. Something that seems to work reasonably well is to perform a Rebuild Solution prior trying to run the application. I found that performing a CLEAN sometimes works, but the Rebuild Solution seems to work more consistently.
I had same problem. It said could not copy from bin\debug to obj.....
When i build web project i found my dll were all in bin folder and not in bin\debug. During publish vs was looking for files in bin\debug. So i opened web project file in editor and look for instances of bin\debug and i found all the dll were mentioned as bin\debug\mylibrary.dll. I removed all \debug from the path and published again. This time vs was able to find all the dll in bin folder and publish succeeded.
I have no idea how this path got changed in web project file.
I spent more than 5 hours debugging this and finally found solution on my own.
This is the right answer.
'Programming' 카테고리의 다른 글
| 무료 WPF 테마가 있습니까? (0) | 2020.05.13 |
|---|---|
| Java 프로젝트에서 UML 클래스 다이어그램 생성 (0) | 2020.05.13 |
| Linux에 어떤 LaTeX Editor를 추천하십니까? (0) | 2020.05.13 |
| Amazon SimpleDB 및 Amazon DynamoDB (0) | 2020.05.13 |
| 왜 @autoreleasepool이 ARC에 여전히 필요한가요? (0) | 2020.05.13 |