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

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>

---

I had this problem in VS2013 (Update 5) and there can be two reasons for that, both of which you can find by enabling "Detailed" build output under "Tools"->"Projects and Solutions"->"Build and Run".

1. "Forcing recompile of all source files due to missing PDB "..."
   This happens when you disable debug information output in your compiler options (Under Project settings: „C/C++“->“Debug Information Format“ to „None“ and „Linker“->“Generate Debug Info“ to „No“: ). If you have left „C/C++“->“Program Database File Name“ at the default (which is „$(IntDir)vc$(PlatformToolsetVersion).pdb“), VS will not find the file due to a bug (https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds).
   To fix it, simply clear the file name to "" (empty field).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   This seems to be a known VS bug too (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) and seems to be fixed in newer versions (but not VS2013). I known of no workaround, but if you do, by all means, post it here.

---

I don't know if anyone else has this same problem, but my project's properties had "Configuration Properties" -> C/C++ -> "Debug Information Format" set to "None", and when I switched it back to the default "Program Database (/Zi)", that stopped the project from recompiling every time.

---

Another simple solution referenced by Visual Studio Forum.

Changing configuration: menu Tools → Options → Projects and Solutions → VC++ Project Settings → Solution Explorer Mode to Show all files.

Then you can see all files in Solution Explorer.

Find the files marked by the yellow icon and remove them from the project.

It's OK.

---

Visual Studio 2013 -- "Forcing recompile of all source files due to missing PDB". I turned on detailed build output to locate the issue: I enabled "Detailed" build output under "Tools" → "Projects and Solutions" → "Build and Run".

I had several projects, all C++, I set the option for under project settings: (C/C++ → Debug Information Format) to Program Database (/Zi) for the problem project. However, this did not stop the problem for that project. The problem came from one of the other C++ projects in the solution.

I set all C++ projects to "Program Database (/Zi)". This fixed the problem.

Again, the project reporting the problem was not the problem project. Try setting all projects to "Program Database (/Zi)" to fix the problem.

---

I met this problem today, however it was a bit different. I had a CUDA DLL project in my solution. Compiling in a clean solution was OK, but otherwise it failed and the compiler always treated the CUDA DLL project as not up to date.

I tried the solution from this post.

But there is no missing header file in my solution. Then I found out the reason in my case.

I have changed the project's Intermediate Directory before, although it didn't cause trouble. And now when I changed the CUDA DLL Project's Intermediate Directory back to $(Configuration)\, everything works right again.

I guess there is some minor problem between CUDA Build Customization and non-default Intermediate Directory.

---

I had similar problem and followed the above instructions (the accepted answer) to locate the missing files, but not without scratching my head. Here is my summary of what I did. To be accurate these are not missing files since they are not required by the project to build (at least in my case), but they are references to files that don't exist on disk which are not really required.

Here is my story:

1. Under Windows 7 the file is located at %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. There are two similar files devenv.exe.config.config and devenv.exe.config. You want to change later one.

2. Under Windows 7, you don't have permission to edit this file being in program files. Just copy it somewhere else (desktop) change it and than copy it back to the program files location.

3. I was trying to figure out how to connect DebugView to the IDE to see the missing files. Well, you don't have to do anything. Just run it, and it will capture all the messages. Make sure Capture Events menu option is selected in Capture menu which by default should be selected.

4. DebugView will NOT display all the missing files at once (at least it didn't for me)! You would have DebugView running and than run the project in Visual Studio 2010. It will prompt the project out of date message, select Yes to build and DebugView will show the first file that is missing or causing the rebuild. Open the project file (not solution file) in Notepad and search for that file and delete it. You are better off closing your project and reopening it again while doing this delete. Repeat this process until DebugView no longer shows any files missing.

5. It's kind of helpful to set the message filter to not up to date from the DebugView toolbar button or Edit → Filter/Highlight option. That way the only messages it displays are the one that has `not up to date' string in it.

I had lots of files that were unnecessary references and removing them all fixed the issue following the above steps.

Second way to find all the missing files at once

There is a second way to find these files all at once, but it involves (a) source control and (b) integration of it with Visual Studio 2010. Using Visual Studio 2010, add your project to a desired location or dummy location in source control. It will try to add all the files, including those that don't exist on disk as well but referenced in the project file. Go to your source control software like Perforce, and it should mark these files which don't exist on disk in a different color scheme. Perforce shows them with a black lock on them. These are your missing references. Now you have a list of them all, and you can delete all of them from your project file using Notepad and your project would not complain about being out of date.

---

For me it was the presence of a non-existing header file on "Header Files" inside the project. After removing this entry (right-click > Exclude from Project) first time recompiled, then directly

========== Build: 0 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========

and no attempt of rebuilding without modification was done. I think is a check-before-build implemented by VS2010 (not sure if documented, could be) which triggers the "AlwaysCreate" flag.

---

If you are using the command-line MSBuild command (not the Visual Studio IDE), for example if you are targetting AppVeyor or you just prefer the command line, you can add this option to your MSBuild command line:

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

As documented here (warning: usual MSDN verbosity). When the build finishes, search for the string will be compiled in the log file created during the build, MyLog.log.

---

I'm using Visual Studio 2013 Professional with Update 4 but didn't find resolution with any of the other suggestions, however, I did manage to resolve the issue for my Team project.

Here's what I did to cause the problem -

• Created a new class object (Project -> Add Class)
• Renamed the file via Solution Explorer and clicked yes when asked if I wanted to automatically rename all references to match

Here's what I did to solve the problem -

• Go to Team Explorer Home
• Click Source Control Explorer
• Drill into the folder where all of the class/project files are
• Found the ORIGINAL filename in the list and deleted it via right-click
• Build

If this is the case for you then just be extra sure that you're deleting the phantom file rather than the actual one you want to keep in the project.

---

I had this problem and found this:

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

Visual C++ Project continually out-of-date (winwlm.h macwin32.h rpcerr.h macname1.h missing)

Problem:

In Visual C++ .Net 2003, one of my projects always claimed to be out of date, even though nothing had changed and no errors had been reported in the last build.

Opening the BuildLog.htm file for the corresponding project showed a list of PRJ0041 errors for these files, none of which appear on my system anywhere: winwlm.h macwin32.h rpcerr.h macname1.h

Each error looks something like this:

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

Your project may still build, but may continue to appear out of date until this file is found.

Solution:

Include afxres.h instead of resource.h inside the project's .rc file.

The project's .rc file contained "#include resource.h". Since the resource compiler does not honor preprocessor #ifdef blocks, it will tear through and try to find include files it should be ignoring. Windows.h contains many such blocks. Including afxres.h instead fixed the PRJ0041 warnings and eliminated the "Project is out-of-date" error dialog.

---

In my case one of the projects contains multiple IDL files. The MIDL compiler generates a DLL data file called 'dlldata.c' for each of them, regardless of the IDL file name. This caused Visual Studio to compile the IDL files on every build, even without changes to any of the IDL files.

The workaround is to configure a unique output file for each IDL file (the MIDL compiler always generates such a file, even if the /dlldata switch is omitted):

• Right-click the IDL file
• Select Properties - MIDL - Output
• Enter a unique file name for the DllData File property

---

I spent many hours spent tearing out my hair over this. The build output wasn't consistent; different projects would be "not up to date" for different reasons from one build to the next consecutive build. I eventually found that the culprit was DropBox (3.0.4). I junction my source folder from ...\DropBox into my projects folder (not sure if this is the reason), but DropBox somehow "touches" files during a build. Paused syncing and everything is consistently up-to-date.

---

There are quite a few potential reasons and - as noted - you need to first diagnose them by setting MSBuild verbosity to 'Diagnostic'. Most of the time the stated reason would be self explanatory and you'd be able to act on it immediatelly, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.

If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.

---

For me, the problem arose in a WPF project where some files had their 'Build Action' property set to 'Resource' and their 'Copy to Output Directory' set to 'Copy if newer'. The solution seemed to be to change the 'Copy to Output Directory' property to 'Do not copy'.

msbuild knows not to copy 'Resource' files to the output - but still triggers a build if they're not there. Maybe that could be considered a bug?

It's hugely helpful with the answers here hinting how to get msbuild to spill the beans on why it keeps building everything!

---

If you change the Debugging Command arguments for the project, this will also trigger the project needs to be rebuilt message. Even though the target itself is not affected by the Debugging arguments, the project properties have changed. If you do rebuild though, the message should disappear.

---

This happened to me multiple times and then went away, before I could figure out why. In my case it was:

Wrong system time in the dual boot setup!

Turns out, my dual boot with Ubuntu was the root cause!! I've been too lazy to fix up Ubuntu to stop messing with my hardware clock. When I log into Ubuntu, the time jumps 5 hours forward.

Out of bad luck, I built the project once, with the wrong system time, then corrected the time. As a result, all the build files had wrong timestamps, and VS would think they are all out of date and would rebuild the project.

---

Most build systems use data time stamps to determine when rebuilds should happen - the date/time stamp of any output files is checked against the last modified time of the dependencies - if any of the dependencies are fresher, then the target is rebuilt.

This can cause problems if any of the dependencies somehow get an invalid data time stamp as it's difficult for the time stamp of any build output to ever exceed the timestamp of a file supposedly created in the future :P

---

I had a similar issue with Visual Studio 2005, and my solution consisted of five projects in the following dependency (first built at top):

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.

I was finding that the Video_Codec project wanted a full build even after a full clean then rebuild of the solution.

I fixed this by ensuring the pdb output file of both the C/C++ and linker matched the location used by the other working projects. I also switched RTTI on.

---

Another one on Visual Studio 2015 SP3, but I have encountered a similar issue on Visual Studio 2013 a few years back.

My issue was that somehow a wrong cpp file was used for precompiled headers (so I had two cpp files that created the precompiled headers). Now why did Visual Studio change the flags on the wrong cpp to 'create precompiled headers' without my request I have no clue, but it did happen... maybe some plugin or something???

Anyway, the wrong cpp file includes the version.h file which is changed on every build. So Visual Studio rebuilds all headers and because of that the whole project.

Well, now it's back to normal behavior.

---

I had a VC++ project that was always compiling all files and had been previously upgraded from VS2005 to VS2010 (by other people). I found that all cpp files in the project except StdAfx.cpp were set to Create (/Yc) the precompiled header. I changed this so that only StdAfx.cpp was set to create the precompiled header and the rest were set to Use (/Yu) the precompiled header and this fixed the problem for me.

---

The .NET projects are always recompiled regardless. Part of this is to keep the IDE up to date (such as IntelliSense). I remember asking this question on an Microsoft forum years ago, and this was the answer I was given.

참고URL : https://stackoverflow.com/questions/2762930/visual-studio-2010-always-thinks-project-is-out-of-date-but-nothing-has-changed