Visual Studio 2010은 항상 프로젝트가 오래되었다고 생각하지만 아무것도 변경되지 않았습니다.

여기에 설명 된 것과 비슷한 문제가 있습니다 .

또한 Visual Studio 2008에서 Visual Studio 2010으로 C ++ / CLI 및 C # 프로젝트의 혼합 솔루션을 업그레이드했습니다. 이제 Visual Studio 2010에서는 하나의 C ++ / CLI 프로젝트가 항상 오래되었습니다.

이전에 컴파일 및 링크되어 F5히트가 발생해도 "프로젝트가 오래되었습니다. 빌드 하시겠습니까?" 가 나타납니다. DLL 파일은 계층이 매우 낮고 솔루션의 거의 모든 프로젝트를 다시 빌드해야하기 때문에 매우 성가신 일입니다.

내 pdb 설정이 기본값으로 설정되어 있습니다 ( 이 문제의 해결 방법 ).

Visual Studio 2010에서 강제로 다시 빌드하거나 프로젝트가 최신이라고 생각하는 이유가 있습니까?

Visual Studio 2010이 왜 그렇게 동작하는지 다른 아이디어가 있습니까?

Visual Studio / Express 2010에만 해당합니다. VS2012, VS2013 등에 대한 다른 (쉬운) 답변보기

누락 된 파일 을 찾으려면 C ++ 프로젝트 시스템 로깅 사용 기사의 정보 를 사용하여 Visual Studio에서 디버그 로깅을 사용하도록 설정 하고 재 빌드의 원인을 알려주십시오 .

1. 또는에서 devenv.exe.config찾은 파일을 엽니 다 . Express 버전의 경우 구성 파일의 이름은 입니다.%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\V*Express.exe.config

2. </configSections>줄 뒤에 다음을 추가하십시오 .

   <system.diagnostics>
     <switches>
       <add name="CPS" value="4" />
     </switches>
   </system.diagnostics>
   

3. Visual Studio를 다시 시작하십시오.
4. DbgView를 열고 디버그 출력을 캡처하고 있는지 확인하십시오.
5. 디버깅을 시도하십시오 (Visual Studio에서 F5를 누르십시오)

6. 디버그 로그에서 다음 형식의 행을 검색하십시오.

   devenv.exe 정보 : 0 : 빌드 입력 'Bla \ Bla \ SomeFile.h'가 없기 때문에 'Bla \ Bla \ Dummy.vcxproj'프로젝트가 최신 상태가 아닙니다.

   (방금 Ctrl + F를 치고 검색했습니다. not up to date) 이것들은 프로젝트가 영구적으로 "오래된"원인이 된 참조 일 것입니다.

이 문제를 해결하려면 프로젝트에서 누락 된 파일에 대한 참조를 제거하거나 참조를 업데이트하여 실제 위치를 표시하십시오.

참고 : 2012 이상을 사용하는 경우 스 니펫은 다음과 같아야합니다.

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

Visual Studio 2012에서는 수용 된 솔루션보다 동일한 결과를 쉽게 얻을 수있었습니다.

도구 → 옵션 → 프로젝트 및 솔루션 → 빌드 및 실행 → * MSBuild 프로젝트 빌드 출력 세부 정보 " 메뉴의 옵션 을 최소 에서 진단으로 변경했습니다 .

그런 다음 빌드 출력에서 ​​"최신 상태가 아님"을 검색하여 동일한 줄을 찾았습니다.

'blabla'프로젝트가 최신이 아닙니다. 프로젝트 항목 'c : \ foo \ bar.xml'에 'Copy to Output Directory'속성이 'Copy always'로 설정되어 있습니다.

이것은 오늘 나에게 일어났다. 원인을 추적 할 수있었습니다. 프로젝트에 더 이상 디스크에 존재하지 않는 헤더 파일이 포함되어 있습니다.

프로젝트에서 파일을 제거하면 문제가 해결되었습니다.

또한이 문제가 발생하여 해결 방법을 찾았습니다.

문제는 위에서 언급 한대로 "파일이 더 이상 디스크에 없습니다."

이것은 정확하지 않습니다. 파일이 디스크에 존재하지만 .VCPROJ 파일이 다른 곳에서 파일을 참조하고 있습니다.

"파일 포함보기"로 이동하여 Visual Studio에서 찾을 수없는 파일을 찾을 때까지 각 포함 파일을 차례로 클릭하여이를 '발견'할 수 있습니다. 그런 다음 해당 파일을 기존 항목으로 추가하고 찾을 수없는 참조를 삭제하면 모든 것이 정상입니다.

올바른 질문은 다음과 같습니다. 포함 파일의 위치를 ​​모르는 경우 Visual Studio는 어떻게 빌드 할 수 있습니까?

우리는 .vcproj 파일이 Visual Studio GUI에 표시되지 않는 어딘가에 해당하는 파일에 대한 상대 경로를 가지고 있다고 생각하며, 이것이 포함의 트리 뷰가 올바르지 않더라도 프로젝트가 실제로 빌드되는 이유를 설명합니다.

받아 들인 대답은 내가 작업을 시작해야했던 혼란스러운 프로젝트 에서이 문제를 해결하는 방법을 알아내는 올바른 길을 안내하는 데 도움이되었습니다. 그러나 매우 많은 수의 잘못된 포함 헤더를 처리해야했습니다. 자세한 디버그 출력을 사용하면 하나를 제거하면 IDE가 30 초 동안 정지되어 디버그 스퓨가 출력되므로 프로세스 속도가 매우 느려집니다.

나는 참을성이 없어서 (Visual Studio 2010) 프로젝트 파일을 확인하고 누락 된 모든 파일을 필터와 함께 한 번에 출력하는 빠르고 더러운 Python 스크립트를 작성했습니다. 여기 요점 : https://gist.github.com/antiuniverse/3825678 (또는 상대 경로를 지원하는 포크 )

예:

D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
  fx_cs_blood.h   (cstrike\fx_cs_blood.h)
  hud_radar.h   (cstrike\hud_radar.h)
[Game Shared Header Files]:
  basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
  fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
  weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
  weapon_hegrenade.h   (..\shared\cstrike\weapon_hegrenade.h)
  weapon_ifmsteadycam.h   (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
  basepaenl.h   (swarm\gameui\basepaenl.h)
  ...

소스 코드:

#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET

ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'

#Works with relative path also
projectFileName = sys.argv[1]

if not os.path.isabs(projectFileName):
   projectFileName = os.path.join(os.getcwd(), projectFileName)

filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()

for inc in filterRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    incFilter = inc.find(ns+'Filter')
    if incFileRel != None and incFilter != None:
        filterDict[incFileRel] = incFilter.text
        if incFilter.text not in missingDict:
            missingDict[incFilter.text] = []

projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()

for inc in projRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    if incFileRel != None:
        incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
        if not os.path.exists(incFile):
            missingDict[filterDict[incFileRel]].append(incFileRel)

for (missingGroup, missingList) in missingDict.items():
    if len(missingList) > 0:
        print("["+missingGroup+"]:")
        for missing in missingList:
            print("  " + os.path.basename(missing) + "   (" + missing + ")")

솔루션 (및 디스크)에서 cpp 및 일부 헤더 파일을 삭제했지만 여전히 문제가 있습니다.

컴파일러가 사용하는 모든 파일은 temp 디렉토리의 * .tlog 파일에 들어갑니다. 파일을 제거해도이 * .tlog 파일은 업데이트되지 않습니다. 증분 빌드에서 프로젝트가 최신인지 확인하는 데 사용되는 파일입니다.

이 .tlog 파일을 수동으로 편집하거나 프로젝트를 정리하고 다시 빌드하십시오.

비슷한 문제가 있었지만 필자의 경우 누락 된 파일이 없었고 pdb 출력 파일을 정의하는 방법에 오류가있었습니다. 접미사 .pdb를 잊어 버렸습니다 (디버그 로깅 트릭으로 찾았습니다).

vxproj 파일에서 다음 문제를 해결하기 위해 다음 줄을 변경했습니다.

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

에

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

VS2013 (업데이트 5) 에서이 문제가 발생했으며 두 가지 이유가 있습니다.이 두 가지 이유는 "도구"-> "프로젝트 및 솔루션"-> "빌드 및 실행"에서 "상세한"빌드 출력을 활성화하여 찾을 수 있습니다. .

1. "Forcing recompile of all source files due to missing PDB "..."
   이는 컴파일러 옵션에서 디버그 정보 출력을 비활성화 할 때 발생합니다 (프로젝트 설정 : "C / C ++"-> "디버그 정보 형식"을 "없음"으로, "링커"-> "디버깅 정보 생성"을 "아니오"로 :) . "C / C ++"-> "프로그램 데이터베이스 파일 이름"(기본값 : "$ (IntDir) vc $ (PlatformToolsetVersion) .pdb")을 그대로두면 VS는 버그로 인해 파일을 찾지 못합니다 ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
   수정하려면 파일 이름을 ""(빈 필드)로 지우십시오.

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   이것은 알려진 VS 버그 인 것 같습니다 ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- the-command-line-since-the-last-build ) 및 최신 버전 (VS2013 제외)에서 수정 된 것으로 보입니다. 나는 해결책을 알지 못했지만, 그렇게한다면 반드시 여기에 게시하십시오.

다른 사람 이이 같은 문제가 있는지 모르겠지만 프로젝트의 속성이 "Configuration Properties" -> C/C++ -> "Debug Information Format""없음"으로 설정되어 있고 기본 "프로그램 데이터베이스 (/ Zi)"로 다시 전환 할 때마다 프로젝트가 다시 컴파일되지 않도록 중지했습니다. .

Visual Studio Forum에서 참조하는 또 다른 간단한 솔루션 입니다.

구성 변경 : 메뉴 도구 → 옵션 → 프로젝트 및 솔루션 → VC ++ 프로젝트 설정 → 솔루션 탐색기 모드 에서 모든 파일 표시 .

그러면 솔루션 탐색기에서 모든 파일을 볼 수 있습니다.

노란색 아이콘으로 표시된 파일을 찾아 프로젝트에서 제거하십시오.

괜찮아.

Visual Studio 2013- "PDB가 없어서 모든 소스 파일을 강제로 다시 컴파일합니다." 문제를 찾기 위해 자세한 빌드 출력을 설정했습니다. "도구"→ "프로젝트 및 솔루션"→ "빌드 및 실행"에서 "자세한"빌드 출력을 활성화했습니다.

나는 모든 C ++의 여러 프로젝트를 가지고 있었고 프로젝트 설정에서 옵션을 (C / C ++ → 디버그 정보 형식) 문제 프로젝트의 프로그램 데이터베이스 (/ Zi)로 설정했습니다. 그러나 이로 인해 해당 프로젝트의 문제점이 중지되지 않았습니다. 문제는 솔루션의 다른 C ++ 프로젝트 중 하나에서 비롯된 것입니다.

내가 설정 한 모든 "프로그램 데이터베이스 (/ Zi)"에 C ++ 프로젝트를. 문제가 해결되었습니다.

다시, 문제를보고 한 프로젝트는 문제 프로젝트가 아니 었습니다. 문제를 해결하려면 모든 프로젝트를 "프로그램 데이터베이스 (/ Zi)"로 설정하십시오.

나는 오늘이 문제를 만났지만 조금 달랐습니다. 내 솔루션에 CUDA DLL 프로젝트가 있습니다. 깨끗한 솔루션으로 컴파일해도 괜찮지 만 그렇지 않으면 컴파일러는 항상 CUDA DLL 프로젝트를 최신 상태가 아닌 것으로 취급했습니다.

이 게시물 에서 해결책을 시도했습니다 .

그러나 내 솔루션에 누락 된 헤더 파일이 없습니다. 그런 다음 제 사건의 이유를 알았습니다.

문제가 발생하지는 않았지만 프로젝트의 중간 디렉토리를 변경했습니다. CUDA DLL Project의 Intermediate Directory를 $ (Configuration) \으로 다시 변경하면 모든 것이 다시 작동합니다.

CUDA Build Customization과 기본이 아닌 Intermediate Directory 사이에 약간의 문제가 있다고 생각합니다.

비슷한 문제가 있었고 위의 지침 (허용 된 답변)을 따라 누락 된 파일을 찾았지만 머리를 긁지 않았습니다. 다음은 내가 한 일에 대한 요약입니다. 정확히 말하면 프로젝트에서 빌드하는 데 필요하지 않기 때문에 파일이 누락되지는 않습니다 (적어도 필자의 경우). 필요하지 않은 디스크에는 존재하지 않는 파일에 대한 참조입니다.

여기 내 이야기가 있습니다 :

1. Windows 7에서 파일은에 있습니다 %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. 이 두 개의 유사한 파일은 devenv.exe.config.config와 devenv.exe.config. 나중에 변경하고 싶습니다.

2. Windows 7에서는 프로그램 파일에있는이 파일을 편집 할 권한이 없습니다. 다른 곳 (바탕 화면)을 변경 한 후 복사하여 프로그램 파일 위치로 다시 복사하십시오.

3. 누락 된 파일을보기 위해 DebugView 를 IDE에 연결하는 방법을 알아 내려고했습니다 . 글쎄, 당신은 아무것도 할 필요가 없습니다. 그냥 실행하면 모든 메시지가 캡처됩니다. 기본적으로 선택해야하는 메뉴 Capture Events에서 메뉴 옵션이 선택되어 있는지 확인하십시오 Capture.

4. DebugView는 모든 누락 된 파일을 한 번에 표시하지 않습니다 (적어도 나를 위해하지는 않았습니다)! Visual Studio 2010에서 DebugView를 실행하고 프로젝트를 실행하는 것보다 project out of date메시지 가 표시되고 빌드 하려면 예 를 선택 하면 DebugView 가 누락되거나 재 빌드를 일으키는 첫 번째 파일을 표시합니다 . 메모장에서 프로젝트 파일 (솔루션 파일 아님)을 열고 해당 파일을 검색하여 삭제하십시오. 이 삭제를 수행하는 동안 프로젝트를 닫았다가 다시 여는 것이 좋습니다. DebugView에 더 이상 누락 된 파일이 표시되지 않을 때까지이 프로세스를 반복하십시오.

5. DebugView 도구 모음 단추 또는 편집 → 필터 / 강조 표시 옵션 에서 메시지 필터 를 최신 상태 로 설정 하지 않는 것이 좋습니다. 그렇게하면 표시되는 유일한 메시지는 '최신이 아닌'문자열이있는 것입니다.

불필요한 참조 인 파일이 많았고 모두 제거하면 위 단계에 따라 문제가 해결되었습니다.

누락 된 모든 파일을 한 번에 찾는 두 번째 방법

이러한 파일을 한 번에 모두 찾는 두 번째 방법이 있지만 (a) 소스 제어 및 (b) Visual Studio 2010과의 통합과 관련이 있습니다. Visual Studio 2010을 사용 하여 프로젝트를 원하는 위치 또는 소스의 더미 위치에 추가하십시오. 제어. 디스크에 존재하지 않지만 프로젝트 파일에서 참조되는 파일을 포함하여 모든 파일을 추가하려고 시도합니다. Perforce 와 같은 소스 제어 소프트웨어로 이동하여 디스크에 존재하지 않는 파일을 다른 색 구성표로 표시해야합니다. Perforce는 그들에게 검은 자물쇠를 보여줍니다. 이것들은 누락 된 참조입니다. 이제 당신은 그들 모두의 목록을 가지고 있으며 메모장을 사용하여 프로젝트 파일에서 모든 파일을 삭제할 수 있으며 프로젝트가 오래된 것에 대해 불평하지 않을 것입니다 .

저에게는 프로젝트 내부의 "헤더 파일"에 존재하지 않는 헤더 파일이있었습니다. 이 항목을 제거한 후 (오른쪽 클릭> 프로젝트에서 제외) 처음으로 다시 컴파일 한 후 직접

========== 빌드 : 0 성공, 0 실패, 5 최신, 0 건너 뛰기 ==========

수정없이 재 구축을 시도하지 않았습니다. VS2010에 의해 구현 된 검사 전 빌드라고 생각합니다 (문서화되어 있는지 확실하지 않을 수 있음). "AlwaysCreate"플래그를 트리거합니다.

Visual Studio IDE가 아닌 명령 줄 MSBuild 명령을 사용하는 경우 (예 : AppVeyor를 대상으로하거나 명령 줄을 선호하는 경우)이 옵션을 MSBuild 명령 줄에 추가 할 수 있습니다.

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

여기에 설명 된 대로 (경고 : 일반적인 MSDN 상세 정보). 빌드가 완료되면 빌드 will be compiled중에 작성된 로그 파일에서 문자열 을 검색하십시오 MyLog.log.

업데이트 4와 함께 Visual Studio 2013 Professional을 사용하고 있지만 다른 제안으로는 해결책을 찾지 못했지만 팀 프로젝트의 문제를 해결했습니다.

문제를 일으킨 방법은 다음과 같습니다.

• 새로운 클래스 객체 생성 (프로젝트-> 클래스 추가)
• 솔루션 탐색기를 통해 파일 이름을 바꾸고 일치하는 모든 참조의 이름을 자동으로 바꿀지 묻는 메시지가 표시되면 예를 클릭했습니다.

다음은 문제를 해결하기 위해 수행 한 작업입니다.

• 팀 탐색기 홈으로 이동
• 소스 제어 탐색기를 클릭하십시오.
• 모든 클래스 / 프로젝트 파일이있는 폴더로 드릴
• 목록에서 ORIGINAL 파일 이름을 찾아 마우스 오른쪽 버튼으로 클릭하여 삭제
• 짓다

이 경우 프로젝트에 보관하려는 실제 파일이 아닌 팬텀 파일을 삭제하고 있는지 확인하십시오.

나는이 문제가 있었고 이것을 발견했다.

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Visual C ++ 프로젝트가 계속 최신 버전이 winwlm.h macwin32.h rpcerr.h macname1.h아님 ( 없음)

문제:

Visual C ++ .Net 2003에서 마지막 빌드에서 아무런 변경 사항도보고되지 않았지만 내 프로젝트 중 하나가 항상 오래된 것으로 주장했습니다.

해당 프로젝트에 대한 BuildLog.htm 파일을 열면이 파일들에 대한 PRJ0041 오류 목록이 나타 났으며, 그 어느 것도 내 시스템에 표시되지 않습니다 : winwlm.h macwin32.h rpcerr.h macname1.h

각 오류는 다음과 같습니다.

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

프로젝트가 계속 빌드 될 수 있지만이 파일을 찾을 때까지 계속 오래된 버전으로 표시 될 수 있습니다.

해결책:

프로젝트의 .rc 파일 afxres.h대신에 포함 resource.h하십시오.

프로젝트의 .rc 파일에는 "#include resource.h"가 포함되어 있습니다. 리소스 컴파일러는 전 처리기 #ifdef블록을 존중하지 않으므로 무시해야 할 포함 파일을 찾아 내려고 시도합니다. Windows.h에는 이러한 블록이 많이 있습니다. afxres.h를 포함하면 대신 PRJ0041 경고가 수정되고 "프로젝트가 오래되었습니다"오류 대화 상자가 제거되었습니다.

필자의 경우 프로젝트 중 하나에 여러 IDL 파일이 포함되어 있습니다. MIDL 컴파일러는 IDL 파일 이름에 관계없이 각각에 대해 'dlldata.c'라는 DLL 데이터 파일을 생성합니다. 이로 인해 Visual Studio는 IDL 파일을 변경하지 않아도 모든 빌드에서 IDL 파일을 컴파일했습니다.

해결 방법은 각 IDL 파일에 대해 고유 한 출력 파일을 구성하는 것입니다 (MIDL 컴파일러는 / dlldata 스위치가 생략 된 경우에도 항상 이러한 파일을 생성합니다).

• IDL 파일을 마우스 오른쪽 버튼으로 클릭
• 속성-MIDL-출력을 선택하십시오.
• DllData 파일 특성 의 고유 파일 이름을 입력하십시오.

나는 이것에 대해 머리를 찢어 많은 시간을 보냈다. 빌드 출력이 일정하지 않았습니다. 서로 다른 프로젝트는 하나의 빌드에서 다음 연속 빌드까지 다른 이유로 "최신 상태가 아닙니다". 결국 범인은 DropBox (3.0.4) 라는 것을 알게되었습니다 . 소스 폴더를 ... \ DropBox에서 프로젝트 폴더로 연결합니다 (이 이유인지 확실하지 않음). 그러나 DropBox 는 빌드 도중 파일을 어떻게 든 "만져" 줍니다. 일시 중지 된 동기화 및 모든 것이 지속적으로 최신 상태입니다.

몇 가지 잠재적 인 이유가 있으며, 언급 한 바와 같이 MSBuild 세부 정보를 '진단'으로 설정하여 먼저 진단해야합니다. 명시된 이유는 대부분 설명이 필요하므로 즉시 조치를 취할 수 있지만 MSBuild는 일부 파일이 수정되어 복사해야한다고 잘못 주장하기도합니다.

이 경우 NTFS 터널링을 비활성화하거나 출력 폴더를 새 위치로 복제해야합니다. 여기 더 많은 단어가 있습니다.

이것은 나에게 여러 번 일어 났고 그 이유를 알기 전에 사라졌습니다. 제 경우에는 다음과 같습니다.

듀얼 부팅 설정에서 시스템 시간이 잘못되었습니다!

우분투와의 이중 부팅이 근본 원인이었습니다. 하드웨어 시계가 엉망이되지 않도록 우분투를 수정하기에는 너무 게으르다. Ubuntu에 로그인하면 시간이 5 시간 앞으로 이동합니다.

운이 좋지 않아서 잘못된 시스템 시간으로 프로젝트를 한 번 만든 다음 시간을 수정했습니다. 결과적으로 모든 빌드 파일에 잘못된 타임 스탬프가 있었으며 VS는 파일이 모두 오래되었다고 생각하고 프로젝트를 다시 빌드합니다.

대부분의 빌드 시스템은 데이터 타임 스탬프를 사용하여 재 구축시기를 결정합니다. 출력 파일의 날짜 / 시간 소인은 종속성의 마지막 수정 시간과 비교하여 확인합니다. 종속성이 최신 인 경우 대상이 다시 빌드됩니다.

빌드 출력의 타임 스탬프가 향후 생성 될 파일의 ​​타임 스탬프를 초과하기 어려우므로 종속성 중 어떤 것이 든 유효하지 않은 데이터 타임 스탬프를 얻는 경우 문제가 발생할 수 있습니다.

나를 위해 일부 파일의 '빌드 작업'속성이 '자원'으로 설정되고 '출력 디렉토리로 복사'가 '새로운 경우 복사'로 설정된 WPF 프로젝트에서 문제가 발생했습니다. 해결책은 'Copy to Output Directory'속성을 'Do not copy'로 변경하는 것 같습니다.

msbuild는 'Resource'파일을 출력에 복사하지 않는 것을 알고 있지만 파일이 없으면 빌드를 트리거합니다. 아마도 그것은 버그로 간주 될 수 있습니까?

msbuild가 콩을 쏟아 왜 모든 것을 계속 만드는지에 대한 힌트를 얻는 힌트를 얻으면 크게 도움이됩니다!

프로젝트의 디버깅 명령 인수를 변경하면 프로젝트를 다시 빌드해야한다는 메시지도 트리거됩니다. 대상 자체가 디버깅 인수의 영향을받지 않더라도 프로젝트 속성이 변경되었습니다. 그래도 다시 작성하면 메시지가 사라집니다.

Visual Studio 2005와 비슷한 문제가 있었으며 솔루션은 다음과 같은 종속성 (처음 맨 처음 작성)으로 5 개의 프로젝트로 구성되었습니다.

Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.

Video_Codec 프로젝트는 솔루션을 완전히 정리 한 다음 다시 빌드 한 후에도 전체 빌드를 원한다는 것을 알았습니다.

pdbC / C ++ 및 링커 의 출력 파일이 다른 작업 프로젝트에서 사용하는 위치와 일치 하도록하여이 문제를 해결 했습니다. 또한 RTTI를 켰습니다.

Visual Studio 2015 SP3의 또 다른 제품이지만 몇 년 전에 Visual Studio 2013에서 비슷한 문제가 발생했습니다.

내 문제는 어떻게 든 잘못된 cpp 파일이 사전 컴파일 된 헤더에 사용되었다는 것입니다 (따라서 미리 컴파일 된 헤더를 만든 두 개의 cpp 파일이 있습니다). 이제 Visual Studio에서 내 요청없이 'precompiled headers'를 만들기 위해 잘못된 cpp의 플래그를 변경 한 이유는 없지만 실마리는 있었지만 어쩌면 일부 플러그인이나 뭔가 ??

어쨌든 잘못된 cpp 파일에는 모든 빌드에서 변경되는 version.h 파일이 포함되어 있습니다. 따라서 Visual Studio는 모든 헤더와 전체 프로젝트를 다시 작성합니다.

글쎄, 지금은 정상적인 행동으로 돌아 왔습니다.

나는 항상 모든 파일을 컴파일하고 이전에 VS2005에서 VS2010으로 (다른 사람들에 의해) 업그레이드 된 VC ++ 프로젝트를 가지고있었습니다. StdAfx.cpp를 제외한 프로젝트의 모든 cpp 파일이 사전 컴파일 된 헤더 작성 (/ Yc)으로 설정되어 있음을 발견했습니다. StdAfx.cpp 만 사전 컴파일 된 헤더를 작성하도록 설정하고 나머지는 사전 컴파일 된 헤더 사용 (/ Yu)으로 설정 하여이 문제를 해결했습니다.

저는 Visual Studio 2013을 사용하고 있으며 Windows 10 May 2019 업데이트로 업데이트되었으며 변경 사항에 관계없이 매번 컴파일을 갑자기 다시해야했습니다. pch를 TargetName 대신 ProjectName으로 이름을 바꾸려고 시도했지만 자세한 로그와 해당 Python 스크립트가있는 누락 된 파일을 찾았지만 결국 내 시간이 MS의 서버와 동기화되지 않았습니다 (밀리 초).

나를 위해 이것을 해결 한 것은

• 제어판에서 "날짜 및 시간 조정"
• "지금 동기화"

이제 내 프로젝트를 아무 이유없이 다시 컴파일 할 필요가 없습니다.

줄 바꿈이나 다른 공백을 넣은 것 같습니다. 그것을 제거하고 F5를 다시 누르십시오.

.NET 프로젝트는 항상 관계없이 다시 컴파일됩니다. 이것의 일부는 IDE를 최신 상태로 유지하는 것입니다 (예 : IntelliSense). 몇 년 전에 Microsoft 포럼에서이 질문을했던 것을 기억하며 이것이 제가받은 답변이었습니다.