오류 : 파일 bin / Debug /…에 액세스 할 수 없습니다. 다른 프로세스에서 사용 중이기 때문입니다.

프로젝트를 디버깅 할 때 다음 오류가 발생합니다.

""obj \ Debug \ My Dream.exe "파일을"bin \ Debug \ My Dream.exe "로 복사 할 수 없습니다. 다른 사용자가 사용 중이기 때문에 프로세스에서 'bin \ Debug \ My Dream.exe'파일에 액세스 할 수 없습니다. 방법."

Process Explorer를 사용하면 MyApplication.exe가 나왔지만 이전에 디버그를 중지했지만 시스템 프로세스에서 여전히 사용합니다. 내 코드를 변경하고 디버그를 시작할 때마다 발생합니다. 프로젝트를 USB에 복사하고 디버그하면 정상적으로 실행됩니다.

왜? 이 오류를 어떻게 수정할 수 있습니까?

저는 Window 7 Professional을 사용합니다. Xp에서는이 오류가 발생하지 않았습니다.

어, 이것은 오래된 문제이며 Visual Studio에서 가끔씩 나타나는 문제입니다. 그것은 나를 몇 번 물었고 VS와 다시 시작하고 싸우는 데 몇 시간을 낭비했습니다. 나는 그것이 두 번 이상 여기에서 논의되었다고 확신합니다. MSDN 포럼에서도 논의되었습니다. 실제 솔루션은 없지만 몇 가지 해결 방법이 있습니다. 여기에서 조사를 시작하십시오 .

무슨 일이 일어나고 있는지 VS가 파일에 대한 잠금을 획득 한 다음 해제하지 않는 것입니다. 아이러니하게도이 잠금은 VS 자체가 파일을 삭제하는 것을 방지하므로 응용 프로그램을 다시 빌드 할 때 파일을 다시 만들 수 있습니다. 유일한 해결책은 VS를 닫고 다시 시작하여 파일에 대한 잠금을 해제하는 것입니다.

내 원래 해결 방법은 bin / Debug 폴더를 열고 실행 파일의 이름을 바꾸는 것이 었습니다. 잠겨있는 경우 삭제할 수 없지만 이름을 바꿀 수 있습니다. 따라서 끝에 숫자 만 추가하면 모든 창을 닫고 VS가 다시 시작될 때까지 기다릴 필요없이 계속 작업 할 수 있습니다. 어떤 사람들은 이전 출력 파일 이름 끝에 임의의 문자열을 추가하기 위해 사전 빌드 이벤트 를 사용하여이를 자동화했습니다 . 예, 이것은 거대한 해킹이지만이 문제는 너무 실망스럽고 쇠약 해져서 무엇이든 할 수 있습니다.

좀 더 많은 실험을 한 후에 디자이너 중 한 명이 열려있는 상태에서 프로젝트를 빌드 할 때만 문제가 발생하는 것 같다는 것을 나중에 알게되었습니다. 따라서 장기적으로 저에게 효과가 있었고 이러한 어리석은 오류 중 하나를 다시 처리하지 못하게 한 솔루션은 WinForms 프로젝트를 빌드하기 전에 항상 모든 디자이너 창을 닫는 것입니다. 예, 이것도 다소 불편하지만 VS를 한 시간에 두 번 이상 다시 시작해야하는 바지보다 확실히 낫습니다.

나는 이것을 사용하지 않고 개인적으로 거기에서 문제를 경험하지 않았지만 이것이 WPF에도 적용된다고 가정합니다.

나는 또한 아직 VS 2012 RC에서 그것을 재현하려고 시도하지 않았습니다. 아직 거기에서 고쳐 졌는지 아닌지는 모르겠습니다. 그러나 지금까지 내 경험에 따르면 Microsoft가 수정했다고 주장한 후에도 여전히 팝업이 나타납니다. VS 2010 SP1에도 여전히 있습니다. 물론 프로그래머가 자신이 무엇을하는지 모르는 바보라고 말하는 것은 아닙니다. 버그에 대한 원인은 여러 가지 뿐이며 실험실에서 안정적으로 재현하기가 매우 어렵다고 생각합니다. 그것은 내가 개인적으로 버그 보고서를 제출하지 않은 것과 같은 이유입니다 (나는 다른 사람들을 +1 했음에도 불구하고).

_{<특별히 누구에게도 향하지 않는 최후의 폭언>}

이전에 Visual Studio 2008에서도이 오류가 발생했습니다. Visual Studio 2012에서 더 많이 발생했습니다.

여기 내가하는 일이 있습니다.

번거로운 프로젝트의 빌드 전 이벤트에 이것을 붙여 넣으십시오.

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

컴퓨터 (오른쪽 클릭)-> 관리-> 서비스 및 응용 프로그램-> 서비스-> 응용 프로그램 경험 활성화

나를 위해 일했습니다!

Visual Studio 2013에서 동일한 문제가 발생했습니다. 내 프로젝트에서이 문제의 원인은 확실하지 않지만 솔루션을 정리하고 다시 빌드하여 해결할 수있었습니다.

1. 빌드> 클린 솔루션
2. 빌드> 솔루션 다시 빌드

적어도 제 경우에는 Visual Studio 2012가 빌드 후 사라지지 않는 msbuild.exe 고스트 프로세스를 두 개 이상 생성하고 있다는 사실을 알게되었습니다. 이 좀비들은 분명히 파일 잠금을 일으키고 있습니다.

msbuild.exe를 죽이는 것은 일회성 솔루션이며 빌드 단위로 수행해야합니다.

하지만 병렬 빌드를 한 번에 비활성화 할 수 있다는 것을 알아 냈습니다. 도구> 옵션> 프로젝트 및 솔루션> 빌드 및 실행> "최대 병렬 프로젝트 빌드 수"로 이동했습니다. 기본적으로 값은 8입니다. 1로 전환했습니다. 매력처럼 작동합니다.

물론 빌드는 이제 조금 느리지 만 후회하는 것보다 더 안전합니다. 적어도이 작은 프로젝트에서는 하나 이상의 빌드 스레드가 필요하지 않았습니다.

나는 이것이 오래된 질문이라는 것을 이해합니다. 불행히도 .NET .net core 2.0에서 내 응용 프로그램 과 동일한 문제에 직면 했습니다 visual studio 2017. 그래서 나는 나를 위해 일한 솔루션을 공유하려고 생각했습니다. 이 솔루션 전에 아래 단계를 시도했습니다.

1. 다시 시작된 Visual Studio
2. 모든 응용 프로그램을 닫았습니다.
3. 내 솔루션을 정리하고 다시 빌드

위 단계 중 어느 것도 문제를 해결하지 못했습니다.

그런 다음 내 Task Manager및 선택한 dotnet프로세스를 열고 작업 끝내기 버튼을 클릭했습니다. 나중에 Visual Studio를 열었고 모든 것이 잘 작동했습니다.

단위 테스트를 실행하는 동안이 문제가 발생하면 여기 내 대답을 참조하십시오 . 아래에 복사 된 답변 :

Sébastien의 답변을 바탕으로 테스트 프로젝트에 사전 빌드 단계를 추가하여 vstest.*아직 실행중인 실행 파일 을 자동으로 종료했습니다 . 다음 사전 빌드 명령이 저에게 효과적이었습니다.

taskkill /f /im vstest.*
exit 0

exit 0명령은 없을 때 빌드 실패를 방지하기 위해 끝에 vstest.*실행되는 실행 파일.

최근에 Visual Studio 2012에서 "다른 프로세스에서 파일을 사용하고 있기 때문에 파일에 액세스 할 수 없습니다 ..."라는 동일한 오류 설명과 함께 문제가 발생했습니다.

이 문제를 먼저 해결하려면 여전히 사용하는 응용 프로그램을 이해해야합니다. "MSBuild"및 "MSBuild 호스트"와 같은 모든 프로세스를 종료했습니다. 그러나 이것은 충분하지 않습니다. "코드 계약"을 설치하고 설정 한 경우이 작업을 확인하고 중단하는 데 DLL이 필요한 경우가 있습니다.

따라서 "CCCheck.exe"의 모든 프로세스를 중지해야합니다.

마지막으로, 프로세스가 DLL을 사용하고 있음을 이해하기 위해 항상 파일 관리자에서 "obj"폴더를 삭제하려고하면이 작업이 실패 할 수 있습니다. 중단 작업에 대한 설명이 포함 된 "메시지 창"이 표시 될 수 있습니다. 또한 변형으로 "Sys Internals Suite"응용 프로그램을 사용해 볼 수 있습니다.

나를 위해 일했습니다. 작업 관리자-> 프로젝트 이름-> 작업 종료. (내 프로젝트 이름으로 3 개의 동일한 프로세스가 있습니다.)

VS 2013; 승리 8;

응용 프로그램의 이전 실행 (예 : 디버깅 옵션없이 시작)이 실제로 중지되었는지 확인합니다. 나는 WPF 응용 프로그램에서 작업하고 있었고 디버깅하지 않고 시작했으며 오류가 계속 발생하면 최소화했습니다. 응용 프로그램을 닫은 후 VS 동작이 정상으로 돌아 왔습니다.

저는 Visual Studio 2017에서이 문제에 시달렸습니다.이 문제는 약 2 ~ 3 주 전에 시작되어 제 생산성을 크게 떨어 뜨 렸습니다. Clean과 Rebulid는 작동하지 않았습니다. 내 컴퓨터를 다시 시작해도 작업이 수행되지 않습니다.

문제를 처리하는 한 가지 방법은 문제가되는 어셈블리를 정리하고 나중에 즉시 실행할 프로젝트를 빌드 (다시 빌드하는 것이 아님)하는 것입니다. 이것은 약 30 %의 시간 동안 작동합니다.

그러나 내가 찾은 가장 신뢰할 수있는 솔루션은 개발자 명령 프롬프트를 열고 msbuild직접 사용 하는 것입니다. 나는 지난 3 일 동안 이것을 해왔고 지금까지 문제가 한 번도 발생하지 않았습니다.

제 경우에는 "모든 파일 표시"를 활성화했습니다. 비주얼 스튜디오 2017

을 실행 taskmanager합니다.
찾아서 netcore삭제하십시오.
그런 다음 수동으로 또는을 실행하여 파일을 삭제할 수 있습니다 Clean.

이것은 순수한 추측이며 대답이 아닙니다.

그러나 나는 잠시 동안이 문제를 겪었습니다.

나는 VS와 AV 예방 조치 간의 상호 작용을 의심하기 위해 잠시 후에 왔습니다.

일부 재생 후, 것 같습니다 수 있습니다 나는 아래 모든 것이, 그래서 바이러스 백신을 수정할 때 멀리 갔다

C : \ Users [사용자 이름] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

폴더는 실시간 보호에 포함되지 않았습니다.

빌드가 실제로 여기에 DLL을 먼저 작성한 다음 최종 빌드 위치에 복사하는 것처럼 보입니다.

너무 늦을 수 있습니다. 그러나 비슷한 문제가 발생했으며 제 경우에는 프로젝트에 자체 참조가 있습니다. 따라서 References에서 삭제하는 것은 매력처럼 작동했습니다 !!!

양식을 닫거나 VisualStudio를 다시 시작하지 않고 가장 빠른 방법은 프로젝트의 컴파일 페이지로 이동하여 "고급 컴파일 옵션 ..."버튼을 클릭하는 것입니다. 그런 다음 옵션 중 하나를 변경 한 다음 (예 : 디버그 정보 생성을 전체에서 pdb 전용으로 변경) 확인을 클릭합니다. 매번 작동하며 MS 가이 버그를 수정할 때까지해야합니다 (VS2012에서 VS2013으로 전환 할 때 까지이 문제가 없었습니다)

또 다른 참고 사항은 프로젝트 또는 솔루션을 정리할 수 없으면 빌드되지 않습니다. 파일은 VS에 의해 확실히 잠겨 있습니다 (적어도 내 경우에는 바이러스 백신 문제가 아닙니다)

나는이 모든 제안과 다른 곳에서 발견 된 다른 제안을 시도했고, 나를 위해 일한 유일한 것은 내 컴퓨터를 다시 시작하는 것이었다. 그런 다음 깨끗한 솔루션을 수행 한 다음 재건했습니다. 참조 용으로 Visual Studio 2013을 사용하고 있습니다.

나는이 같은 문제를 겪었고 내가 찾은 것은 실제로 백그라운드에서 여러 Windows 양식 응용 프로그램 을 실행하고 있다는 것 입니다. 응용 프로그램에 두 개의 양식이 있고 기본 양식 이 아닌 두 번째 양식 을 닫아 응용 프로그램이 완전히 종료되지 않을 때 발생합니다.

나는 보통 내 응용 프로그램을 실행합니다.

• exe를 통해 또는
• 디버깅하지 않고 실행

해결책은 Windows 양식 응용 프로그램의 다른 인스턴스를 닫는 것 입니다. 이것은 항상 애플리케이션 인스턴스를 닫는 한 가지 방법입니다.

사전 빌드 명령

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

도움

[해결됨] 오류 : 다른 프로세스에서 사용 중이기 때문에 bin / Debug /… 파일에 액세스 할 수 없습니다.

첫 번째 양식을로드 한 다음 때때로 자동으로 사라지고 두 번째 양식이 화면에로드되는 것과 같이 두 개의 창을 차례로 실행하려고 시도하는 동안이 오류가 발생한다고 접근하고 있습니다.

기본적으로 백그라운드에서 실행중인 첫 번째 양식과이 오류의 주요 원인을 닫아야합니다.

첫 번째 양식을 닫으려면 두 번째 양식로드 이벤트 핸들러에이 두 줄의 코드를 추가해야합니다.

    Form1 form = new Form1();
    form.Close();

이것은 오류를 완벽하게 해결합니다.

한 가지 간단한 해결책은 bin \ Debug 폴더로 이동하여 해당 폴더의 모든 파일을 삭제 한 다음 다시 빌드하는 것입니다. 작동하지 않으면 Visual Studio를 닫은 다음 파일 탐색기를 사용하여 bin \ Debug 폴더로 이동 한 다음 왼쪽 모서리에서 파일> 명령 프롬프트 열기> 관리자 권한으로 명령 프롬프트 열기>이 명령 입력 "DEL / F / Q / A * "> 다시 빌드

나는 Cody Gray의 답변이 부분적으로 도움이된다는 것을 알았습니다. 당신 중 일부가 경험할 수있는 내 문제의 실제 소스로 안내했습니다 .Visual Studio의 테스트 실행은 기본적으로 열려 있고 파일에 대한 잠금을 유지합니다.

주로 쓸모없는 동작을 중지하려면 https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 의 지침을 따르십시오. -50727-1-rtmrel

테스트 메뉴-> 테스트 설정-> "테스트 실행 엔진 실행 유지"를 선택 취소하십시오.

내 문제는 dotnet이 중단되었고 VS가 새 dll을 만들거나 이전 dll에 액세스하려고 할 때마다 dotnet 프로세스가 dll을 래치하고 Visual Studio가 dll을 복제하는 것을 중지했습니다. 해결책은 작업 관리자에서 모든 dotnet 작업을 종료하는 것입니다 (실제로 죽은 작업 만 제거합니다. 하나를 끝내려고하고 종료되지 않으면 작동 중임을 의미합니다).

VisualStudio 닫기, ctrl-alt-delete, 작업 관리자 선택, 모든 MSBuild 프로세스 찾기 및 종료-VisualStudio에는 기본적으로 디버거의 제어를 잃고 디버거가 디버그 / 빈의 .pdb 파일에 대한 잠금을 유지하는 매우 심각한 버그가 있습니다. 폴더. 모든 MSBuild (디버거) 프로세스를 종료 한 후 / debug / bin 폴더를 삭제하고 Visual Studio에서 솔루션을 다시 엽니 다. 이제 가셔도 좋습니다. 마이크로 소프트는이 쓰레기를 고쳐야합니다.

나는 별도의 질문 을 열었습니다한 번의 업데이트 후 비슷한 동작을 보인 VS 2017에 관한 . 문제는 바이러스 백신 프로그램에 의해 생성 된 것처럼 보였습니다.

바이러스 백신 제외 목록에 bin 폴더를 추가하고 컴퓨터를 다시 시작했으며 이제 작동하는 것 같습니다.

이 문제를 해결했습니다 ..

디버그 근처에 몇 가지 구성이있는 드롭 다운 메뉴가 표시됩니다. 기본적으로 모든 CPU가 있습니다. x86을 선택하고 작동 할 프로그램을 실행하십시오. x86이 없으면 구성 관리자로 이동하여 x86을 추가하십시오.

또 다른 kludge, ugh,하지만 VS 2013에서 쉽게 작동합니다. 프로젝트를 클릭하십시오. 속성 패널에는 값이있는 프로젝트 파일이라는 항목이 있어야합니다.

(프로젝트 이름) .vbproj

끝에 -01을 추가하는 등 프로젝트 이름을 변경합니다. 잠긴 원본 .zip 파일이 여전히 존재하지만 더 이상 참조되지 않으므로 작업을 계속할 수 있습니다. 다음에 컴퓨터를 재부팅하면 잠금이 사라지고 잘못된 파일을 삭제할 수 있습니다.