업데이트 : 이 버그를 재현하는 샘플 프로젝트 는 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 게스트 아래의 탐색기 또는 안티 바이러스에서 공유 폴더로 사용할 수있게했기 때문에 게스트 아래의 프로그램 (하나는 설치되지 않은 것으로 생각되지만)은 파일에 대한 핸들을 잡고 있습니다.
