I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
I'm working on a medium-sized project which uses qmake to generate Visual Studio 2005 project files. I'm trying to get it built under Visual Studio 2010 Ultimate. Since qmake doesn't support this IDE yet i had the provided conversion assistant convert my solution.
When trying to build I get the following error in one of the subprojects:
CVTRES : fatal error CVT1100: duplicate resource. type:VERSION,name:1,language:0x0407
After what Google's results told me it seems that this error is likely to occur when migrating to a newer version of Visual Studio but I don't know why and the hacks recommended there don't work for me.
What I already tried is to rename the ressources to random numbers, even a different "name" at every occurence of the version information.
When I build the project again after reading the error and deleting the corresponding .RC-file it works once. But that's too much of a hack.
Any ideas anyone?
Thanks in advance.
I resolved that problem when moving from VC++ 2010 to 2012 by changing the setting under Configuration Properties>Manifest Tool>Input and Output>Embed Manifest to NO. I have no idea what that is all about, but I looked at the contents of the .manifest file, and it sure looks like I can live without it being embedded.
I recently solved the similar problem with Qt 4.8.2 and Visual Studio 2012. Qt 4.8.2 does not support VS2012 as mkspec, so I copied win32-msvc2010 mkspec to win32-msvc2012 (changing _MSC_VER to 1700) and used some other workarounds (QtWebKit fix, etc. — you can find them over the internet) to build Qt 4.8.2 with VS2012. But qmake was not aware of VS2012 .vcxproj project files, so it continued to generate VS2010 projects. After conversion of these project files to the new 2012 format in the VS the above error arose.
The solution was to exclude generated .res files from build in all configurations (both Debug and Release). To do this, open 'Generated Files' folder in Solution Explorer, right click the .res file, open Properties, select 'All Configurations' from drop-down list and set 'Excluded From Build' property of 'General' section to 'Yes'.
It is quite tedious to repeat these actions by hands every time, so I wrote Python script to automate this. You can use it (at your own risk!) to update qmake-generated .vcxproj files.
import sys
import os
from xml.etree import ElementTree
def updateProject(filename):
def getXmlns(tag):
return tag[1:].split('}')[0]
tree = ElementTree.parse(filename)
root = tree.getroot()
xmlns = getXmlns(root.tag)
for cb in root.iter('{' + xmlns + '}CustomBuild'):
if(not 'Include' in cb.attrib):
continue
if(not cb.attrib['Include'].endswith('.res')):
continue
for excl in cb.iter('{' + xmlns + '}ExcludedFromBuild'):
if('Condition' in excl.attrib):
del excl.attrib['Condition'] # delete ExcludedFromBuild condition
ElementTree.register_namespace('', xmlns)
tree.write(filename)
if(len(sys.argv)>=2): # use project files specified in command line:
for i in range(1, len(sys.argv)):
updateProject(sys.argv[i])
else: # update all project files in current directory:
for filename in os.listdir(os.getcwd()):
if(filename.endswith('.vcxproj')):
updateProject(filename)
Thanks to Xandy for pointing out that you'll need to pass working directory to listdir() for script to work in Python 2.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and remove the reference to the manifest file in the .rc file.
Reference
I recently ran into this problem, and by accident ended up with a project file that didn't have the resource conflict. In my case I was importing a QT qmake generated project for VS2008 into VS2010. After using VcprojFormatter and a lot of diffs, I found the difference (for me). I think it is a bug in either the import wizard, or the core of VS 2010.
http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
My resource file was called win32_resources.rc You'll need to edit each intermediate data folder corresponding to your build configurations (release, debug, etc)
Look for a section like the following in your vcxproj file:
<ItemGroup>
<Resource Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</Resource>
<Resource Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</Resource>
</ItemGroup>
All the "Resource" text should be replaced with "CustomBuildStep":
<ItemGroup>
<CustomBuildStep Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
<CustomBuildStep Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
</ItemGroup>
The problem in the VS2008 file is that the default(?) setting was not explicit:
<File RelativePath="release\win32_resources.res">
<FileConfiguration
Name="Debug|Win32"
ExcludedFromBuild="true"
>
<Tool Name="VCCustomBuildTool"/>
</FileConfiguration>
</File>
The "Tool Name" field was missing.
If you ever encounter this error while compiling (usually a downloaded
project from internet), then remove the manifest file and remove the
reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from knowing this, rather than assuming hB0's answer should be ignored because others have votes and hB0's has zero votes. I have to say it in a separate answer because I the system will not let an unregistered user vote. I even registered so as to be able to vote on this answer but the system still will not let me vote till I am a more mature user.
This is a stretch, but I had a similar problem under Visual Studio 2005. It might help, or be totally off base:
I was linking with a static library (.lib) that has its own version resource - very reasonable, it shows the library's version. On some stations, my app would link. On other stations, I'd get the same duplicate resource message you got.
It turned out to be related to a linker optimization setting: "Use Library Dependency Inputs" (UseLibraryDependencyInputs=), possibly combined with "Link Library Dependencies". When "Use Library Dependency Inputs" was enabled, the linker was being fed the .obj and .res files that were used to build the .lib, instead of just searching the .lib.
The problem is that you don't want the .lib's .res file as an input file to the linker. My project has its own version resource. If you bring in the .lib's resources, you now have two version resources, hence the error. If the linker simply searches the .lib, it has no reason to bring in the .lib's resource, and all is well.
My project's configuration didn't force the setting of "Use Library Dependency Inputs", it inherited it. On some stations, it inherited "No", and I could link. On some stations, it inherited "Yes", and we got the error.
If Visual Studio 2010 still has this setting, try forcing it off.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
by Richard Hein worked for me. I was compiling with VS2013.
I had similar problem in Visual Studio C++ 2010. I did not installed any Service packs or updates of VS and this problem arises when I had two rc files which tried to use ICONs. So I just taken content of one file and cut it into the main file. So only one file contains the ICONS and the second file is empty. Works like sharm :-).
Replace else block in Dmitry Markin answer to recursively update all project files
else: # recursively update all project files in current directory:
rootdir = os.getcwd()
for root, subFolders, files in os.walk(rootdir):
for filename in files:
if(filename.endswith('.vcxproj')):
filePath = os.path.join(root, filename)
print "file: %s" % (filePath)
updateProject(filePath)
I came here looking for an answer for this error. I am sorry to burst the bubble. None of the answers worked out for me.
My mistake was I had defined 3 MACRO's with same id. That is the reason I was getting the error mentioned in the question.
my code before when the error was showing:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**6**
#define IDB_MARKER_DOTTED_LINE 21**6**
i changed it to:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**7**
#define IDB_MARKER_DOTTED_LINE 21**8**
Errors were GONE!!!!!!!!!!
I had this and I did the following in resource.h
#undef VS_VERSION_INFO
#define VS_VERSION_INFO 310
As VS_VERSION_INFO is given resource id 1 in WinRes.h just making it something else fixed my issue.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and
remove the reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from
knowing this, rather than assuming hB0's answer should be ignored
because others have votes and hB0's has zero votes. I have to say it
in a separate answer because I the system will not let an unregistered
user vote. I even registered so as to be able to vote on this answer
but the system still will not let me vote till I am a more mature
user.
This answer point a way to find the problem that I encounted. In my senario, the import props has this code:
<ResourceCompile Include="$(VersioningDir)**Version.rc" />
When I delete it, all work is done.
If you ever encounters CVT1100 (duplicate resource) & LNK1123 (failure during conversion to COFF) resource errors in Visual Studio 20XX, then do below steps to resolve it.
Open .rc file & comment / remove below MACRO
MOVEABLE PURE "res\.manifest"
2 Rename / Delete Manifest file from Resource folder from Project directory.
Now Re-build the solution & Enjoy...
I have a very similar problem as described here.
I also upgraded a mixed solution of C++/CLI and C# projects from Visual Studio 2008 to Visual Studio 2010. And now in Visual Studio 2010 one C++/CLI project always runs out of date.
Even if it has been compiled and linked just before and F5 is hit, the messagebox "The project is out of date. Would you like to build it?" appears. This is very annoying because the DLL file is very low-tiered and forces almost all projects of the solution to rebuild.
My pdb settings are set to the default value (suggested solution of this problem).
Is it possible the get the reason why Visual Studio 2010 forces a rebuild or thinks a project is up to date?
Any other ideas why Visual Studio 2010 behaves like that?
For Visual Studio/Express 2010 only. See other (easier) answers for VS2012, VS2013, etc
To find the missing file(s), use info from the article Enable C++ project system logging to enable debug logging in Visual Studio and let it just tell you what's causing the rebuild:
Open the devenv.exe.config file (found in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ or in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). For Express versions the config file is named V*Express.exe.config.
Add the following after the </configSections> line:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
Restart Visual Studio
Open up DbgView and make sure it's capturing debug output
Try to debug (hit F5 in Visual Studio)
Search the debug log for any lines of the form:
devenv.exe Information: 0 : Project 'Bla\Bla\Dummy.vcxproj' not up to date because build input 'Bla\Bla\SomeFile.h' is missing.
(I just hit Ctrl+F and searched for not up to date) These will be the references causing the project to be perpetually "out of date".
To correct this, either remove any references to the missing files from your project, or update the references to indicate their actual locations.
Note: If using 2012 or later then the snippet should be:
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
In Visual Studio 2012 I was able to achieve the same result easier than in the accepted solution.
I changed the option in menu Tools → Options → Projects and Solutions → Build and Run → *MSBuild project build output verbosity" from Minimal to Diagnostic.
Then in the build output I found the same lines by searching for "not up to date":
Project 'blabla' is not up to date. Project item 'c:\foo\bar.xml' has 'Copy to Output Directory' attribute set to 'Copy always'.
This happened to me today. I was able to track down the cause: The project included a header file which no longer existed on disk.
Removing the file from the project solved the problem.
We also ran into this issue and found out how to resolve it.
The issue was as stated above "The file no longer exists on the disk."
This is not quite correct. The file does exist on the disk, but the .VCPROJ file is referencing the file somewhere else.
You can 'discover' this by going to the "include file view" and clicking on each include file in turn until you find the one that Visual Studio can not find. You then ADD that file (as an existing item) and delete the reference that can not be found and everything is OK.
A valid question is: How can Visual Studio even build if it does not know where the include files are?
We think the .vcproj file has some relative path to the offending file somewhere that it does not show in the Visual Studio GUI, and this accounts for why the project will actually build even though the tree-view of the includes is incorrect.
The accepted answer helped me on the right path to figuring out how to solve this problem for the screwed up project I had to start working with. However, I had to deal with a very large number of bad include headers. With the verbose debug output, removing one caused the IDE to freeze for 30 seconds while outputting debug spew, which made the process go very slowly.
I got impatient and wrote a quick-and-dirty Python script to check the (Visual Studio 2010) project files for me and output all the missing files at once, along with the filters they're located in. You can find it as a Gist here: https://gist.github.com/antiuniverse/3825678 (or this fork that supports relative paths)
Example:
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)
...
Source code:
#!/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 + ")")
I've deleted a cpp and some header files from the solution (and from the disk) but still had the problem.
Thing is, every file the compiler uses goes in a *.tlog file in your temp directory.
When you remove a file, this *.tlog file is not updated. That's the file used by incremental builds to check if your project is up to date.
Either edit this .tlog file manually or clean your project and rebuild.
I had a similar problem, but in my case there were no files missing, there was an error in how the pdb output file was defined: I forgot the suffix .pdb (I found out with the debug logging trick).
To solve the problem I changed, in the vxproj file, the following line:
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
to
<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".
"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).
"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:
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.
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.
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.
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.
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.
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
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.
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.
I'm on Visual Studio 2013 and just updated to the Windows 10 May 2019 update and compiling suddenly had to be redone every time, regardless of changes. Tried renaming the pch to ProjectName instead of TargetName, looked for missing files with the detailed log and that Python script, but in the end it was my time was not synced with MS's servers (by like milliseconds).
What resolved this for me was
"Adjust date and time" in the control panel
"Sync Now"
Now my projects don't need to be recompiled for no reason.
I think that you placed some newline or other whitespace. Remove it and press F5 again.
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.