Visual Studio는 빌드시 출력 파일을 잠급니다.


80

VS 2010에 간단한 WinForms 솔루션이 있습니다. 빌드 할 때마다 출력 파일 (bin \ debug \ app.exe)이 잠기고 후속 빌드가 실패 "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." 하고 프로젝트를 빌드하는 유일한 방법은 VS를 다시 시작하는 것입니다. 모든 빌드는 매우 어색합니다.

이 오래된 블로그 게시물 http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx를 찾았습니다 . 문제가 정말 오래된 것 같습니다. 여기에서 무슨 일이 일어나고 있는지 또는 적어도 몇 가지 해결 방법을 아는 사람이 있습니까?

최신 정보

실제로 파일을 실행 하지 않습니다 . 잠금은 디버그 후가 아니라 빌드 후에 발생합니다 (예 : VS 시작-빌드-빌드-실패!). 그리고 바이러스 백신을 끄려고했습니다. 도움이되지 않습니다.

업데이트 2

프로세스 탐색기는 파일을로드 한 devenv.exe를 표시합니다 (핸들이 아닌 DLL로). 빌드 중 일부 결함으로 인해 언로드가 차단 된 것처럼 보이지만 (첫 번째) 빌드는 "1 성공, o 실패"이외의 다른 메시지없이 완료됩니다.


가끔 비슷한 문제가 있습니다. Windows 7을 사용하십니까? 제 경우에는 파일을 잠그는 것이 VS가 아닙니다. 탐색기에서 파일을 삭제할 수 있으며 빌드가 정상적으로 실행됩니다. 출력 디렉토리에 탐색기 창이 열려 있으면 문제가 더 자주 발생하는 것으로 나타났습니다. 바이러스 스캐너 btw를 사용하지 않습니다.
stijn 2010 년

NUnit을 사용할 때 Win7에서 때때로 동일한 문제가 발생하는데, 이는 TDD를 수행 할 때 매우 성가신 일입니다.
Mathias

@stijn : 온 액세스 바이러스 스캐너를 사용하지 않습니까? Doooh ...
TheBlastOne 2011-07-11

이것은 VS 2013에서 단위 테스트를 디버깅하고 VS가 테스트 실행을 완료하기 전에 코드를 중지 할 때도 발생합니다. VS가 테스트 실행기를 언로드 할 때까지 몇 초 더 기다리면 발생하지 않습니다.
StingyJack 2015 년

어쩌면이 도움이 될 것입니다 sevenforums.com/tutorials/...
토성 기술

답변:


69

같은 문제가 있었지만 해결책을 찾았습니다 ( Keyvan Nayyeri 덕분에 ).

그러나 이것을 해결하는 방법? 프로젝트 유형에 따라 다양한 방법이 있지만 Visual Studio 추가 기능 개발자에게 권장하는 간단한 솔루션 중 하나는 프로젝트의 빌드 이벤트에 간단한 코드를 추가하는 것입니다.

프로젝트의 빌드 전 이벤트 명령 줄에 다음 코드 줄을 추가 할 수 있습니다.

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

나를 위해 일했습니다. 당분간 그 문제가 발생했습니다.
ritcoder 2012

이것은 나를 위해 작동합니다. 아래의 Vladimir Datsyuk에 따라 % random % 버전을 시도했지만 제 경우에는 잠긴 유일한 파일이 VS를 시작한 후 첫 번째 빌드에서 가져온 것이므로 한 번만 작동하면됩니다. 나는 VS 2013을 사용하고 있으며 GUI 디자이너를 사용하지 않고 많은 참조 및 T4 템플릿 프로젝트가있는 큰 솔루션입니다.
Davos

5
PDB도 잠겨 있었기 때문에 이름을 변경해야했습니다. if exist "$(TargetDir)$(TargetName).pdb.locked" del "$(TargetDir)$(TargetName).pdb.locked" ,if exist "$(TargetDir)$(TargetName).pdb" if not exist "$(TargetDir)$(TargetName).pdb.locked" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked"
Tobias J

나에게도 적합합니다 (Visual Studio 2013). Thx
Anonymous

VS2017에서 계속 작업합니다. 놀라운 것은 VS2017에서 문제가 지속된다는 것입니다!
Carvo Loco

24

바이러스 문제가 아닙니다. Visual Studio 2010 버그입니다. Visual Studio GUI 디자이너 사용과 관련된 문제인 것 같습니다.

여기서 해결 방법은 빌드 전 이벤트에서 잠긴 출력 파일을 다른 임시 파일로 이동하는 것입니다. 임시 파일 이름을 임의로 생성하는 것이 좋습니다.

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

일정한 임시 파일 이름을 사용하는 경우 잠금을 연기합니다.

이 해결 방법은 정확히 한 번만 작동합니다.

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

정확히 2 번 작동하는 2 개의 임시 파일이있는 솔루션을 찾았습니다.


1
나에게도 발생하지만 내 앱을 실행하는 경우에만 발생합니다. 캐싱이나 어떤 이유로 든 실행 가능한 것을 주시하는 것이 OS라고 생각합니다. 또한 적어도 제 경우에는 System.Reflection.Assembly.GetExecutingAssembly ()를 호출하는 앱에서만 발생하는 것 같습니다.
TheBlastOne 2011

2
확인 마지막 실행이 System.Reflection.Assembly.GetExecutingAssembly를 호출하거나 디자인 타임 구성 요소의 소스 코드 (구성 요소 도구 모음에서 활성화 된 디자인 타임 구성 요소의 소스 코드)를 호출 한 경우에만 발생하는 것 같습니다. 디자인 타임 동안 System.Reflection.Assembly.GetExecutingAssembly에 대한 호출이 마지막 실행이 시작될 때 편집기에서 열려있었습니다. 알았다?
TheBlastOne 2011-07-14

1
갑자기이 문제가 나타났다고 생각합니다 ... 이제 프로젝트 설정을 구축하는 데 30 분을 허비했습니다. 잠금 문제가 발생하기 때문입니다! 응용 프로그램도 실행하지 않습니다.
GorillaApe 2011-07-20

1
stackoverflow.com/questions/3312646/… 저를 위해 일했습니다
GorillaApe

1
pbd 파일에 대한 추가 사항 : del "$(TargetPath).locked.*" /q if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked.%random%" del "$(TargetDir)$(TargetName).pdb.locked.*" /q if exist "$(TargetDir)$(TargetName).pdb" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked.%random%" exit /B 0
Marv

6

나에게도 문제가 발생했습니다.

내 시나리오는 다음과 같습니다. Windows 7 실행 (Windows XP에서도 발생했을 수 있음) 및 WPF 사용자 컨트롤을 사용하여 프로젝트에서 작업하는 동안 사용자 컨트롤의 XAML 파일을 열 때까지 항상 빌드 할 수있었습니다. 빌드가 하나 있고 파일이 잠 깁니다.

또한 관리자 권한 으로 Visual Studio (Devenv.exe)를 실행하고 있음을 알게되었고 관리자 권한없이 Visual Studio를 실행하기 시작했는데 문제가 사라졌습니다! .

도움이되었는지 알려주세요. 행운을 빕니다.


1
모든 VS11 릴리스에서 똑같은 문제가 발생했지만 아직 수정 사항을 찾지 못했습니다 (불행히도 관리자 권한없이 진행해도 도움이되지 않았습니다). 어떤 아이디어라도 감사합니다!
Dan Nolan

4

탐욕스러운 바이러스 검사 소프트웨어에서 또는 app.exe가 제대로 종료되지 않는 경우에 이것을 보았습니다. 프로세스가 아직 실행되고 있지 않은지 확인하십시오.


3

컴퓨터의 바이러스 스캐너는 어떻습니까? 파일에 대한 핸들을 보유하고있는 프로세스를 볼 수 있습니까 ( 프로세스 탐색기 를 사용 하여 확인)?

프로세스 목록에 "app.exe"가 표시 될 수 있습니다. 즉, 마지막으로 디버깅 한 버전이 여전히 실행 중입니까? 여러 스레드가있는 응용 프로그램을 개발할 때 join모든 스레드가 아닌 경우 이런 일이 발생할 수 있습니다.


3

나는 같은 문제가 있었고 VS는 빌드하기 전에 VS에서 Form 또는 UserControl을 열 때만 exe를 잠급니다. 솔루션은 매우 쉬웠습니다. 솔루션을 빌드하기 전에 Form / UserControl을 닫아야했고 작동했습니다.


3

훌륭한 Stormenet 답변을 바탕 으로 모든 경우에 작동하는 작은 스크립트를 작성했습니다.

다음은 사전 빌드 이벤트 텍스트 상자에 입력 할 코드입니다.

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

사전 빌드 이벤트

다음은 파일에서 복사 할 스크립트 $(SolutionDir)\BuildProcess\PreBuildEvents.bat 입니다 (물론이 경로를 수정할 수 있음).

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

2

빌드 번호 자동 업데이트를 사용하면 잠금 문제가 발생할 수 있는 알려진 문제 533411 도 있습니다. 버그 보고서의 해결 방법

임시 해결 방법은 재 구축 후 어셈블리 버전 업데이트를 비활성화하는 것입니다. AssemblyInfo.cs 파일에서 AssemblyVersion 특성에서 와일드 카드를 제거합니다. 예를 들면 다음과
같습니다.
[assembly : AssemblyVersion ( "1.4. *")]
[assembly : AssemblyFileVersion ( "1.4")]

[assembly : AssemblyVersion ( "1.4.0.0")]
[어셈블리 : AssemblyFileVersion ( "1.4.0.0")]


2

이 문제가 있었고 일부 사용자 지정 코드로 해결했습니다. 여기 참조 : Visual Studio 2010 빌드 파일 잠금 문제

수락 된 답변으로 유틸리티를 컴파일하고 문제를 해결하기 위해 설명 된대로 빌드 단계 중에 참조하십시오. 나는 여전히 아침의 일을 정리하기 위해 점심 시간에 VS 2010을 끕니다.

사용자 지정 코드의 이유는 자주 권장되는 솔루션이 한 번만 작동 한 다음 이름이 바뀐 파일도 잠기므로 이름을 바꿀 수 없기 때문입니다. 여기서는 이름이 바뀐 버전이 충돌하지 않도록 파일에 데이터 시간 정보를 추가하기 만하면됩니다.


0

나를 위해 일한 유일한 방법은 Visual Studio 2012를 종료하고 문제가있는 프로젝트의 BIN 및 OBJ 폴더를 삭제 한 다음 Visual Studio를 다시 여는 것입니다.

문제 해결 ... 다음 시간까지.


0

$ (TargetPath)가 COM을 사용하는 DLL을 가리키는 경우 기본 생성자가 있는지 확인하십시오. 기본 생성자가 왜 거기에서 추론되지 않는지 확실하지 않습니다. 이 시나리오에서 기본 생성자를 추가하면 저에게 효과적이었습니다.


0

Visual Studio를 닫고 최신 솔루션을 다시 열고 다시로드하면 문제가 해결됩니다. (Visual Studio 2013 Ultimate)


1
예, 매번해야합니다. 그게 해결책입니다
존 데 메트

0

VS2017에서 xamarin 앱을 개발하는 것과 동일한 문제가 발생했습니다.

devenv.exe로 exe / dll을 잠그는 Windows Defender가 발생했습니다.

Win Defender로 이동하여

devenv.exe
msbuild.exe

프로세스 제외 목록에.


창문 수비수라는 걸 어떻게 알았어?
Mike

내 솔루션은 약간 작동했지만 실제로 새로운 VS2017 업데이트 릴리스의 주요 버그라는 것을 알았습니다. developercommunity.visualstudio.com/content/problem/54945/…
michael g

0

이것이 내가 찾은 해결책입니다.

  1. 아래와 같이 프로젝트 설정에서 Visual Studio 호스팅 프로세스를 선택 취소합니다.

여기에 이미지 설명 입력

  1. exe를 종료하십시오. taskmanager의 applicationname.vshost.exe가됩니다.

여기에 이미지 설명 입력

  1. 이제 애플리케이션을 다시 빌드하고 실행할 수 있습니다.

참고 : 문제없이이 옵션을 다시 활성화 할 수 있습니다.


0

McAfee LiveSafe 실시간 검색을 비활성화하여이 문제를 해결했습니다. 내 .exe 파일은 OP가 설명한 것처럼 잠기고 파일을 제거 할 방법이 없으므로 솔루션을 빌드 할 수 없습니다. McAfee 기능을 비활성화 한 후 문제가 사라졌습니다.

그런 다음 당연히 내 PC가 새롭고 이미 설치된 프로그램과 함께 제공되기 때문에 설치된 McAfee를 완전히 제거했습니다.


-8

새로운 빈 솔루션을 만들고 이전 파일을 모두 추가했습니다. 이것은 어떻게 든 문제를 해결했습니다.


이것은 아마도 답이 될 수 없습니다. 다른 사람들은 문제에 대한 훨씬 더 명확한 이유와 기록이 손실되기 때문에 버전 제어로 작업 할 때 허용되지 않는 새 솔루션 파일을 만들 필요가없는 적절한 해결 방법을 제공했습니다.
Bernhard Hofmann

예, 이것은 잘못된 대답입니다. 다른 것들은 여전히 ​​더 나쁩니다. 출력 파일의 이름을 바꾸는 것은 해결책이 아니며 다루기 힘든 해결 방법입니다. 더 좋은 아이디어가 있다면 답변을 게시 해보세요.
신경 끄시 고

새로운 솔루션을 만드는 것은 일시적으로 문제를 해결했습니다. 가장 좋은 답변은 Vladimir Datsyuk의 답변 인 것 같습니다.
user492238

1
하나의 솔루션에 15 개의 프로젝트가있는 경우이 솔루션이 최적일까요?
Shittu Joseph Olugbenga
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.