0

We are working with some huge Visual Studio 2010 solutions with a great many static library projects shared between the two. After building either of these solutions the other solution will complain that many (but not all) of the projects are out of date, though actually building naturally does next to nothing and is almost instant.

After following the steps on this question on debugging MSBuild project dependencies I can see many lines of the following messages indicating that the projects are considered out of date because of a "different evaluation fingerprint":

[8444] Project not up to date because the last build has different evaluation fingerprint. 
[8444] devenv.exe Information: 0 : 
[8444] Project not up to date because the last build has different evaluation fingerprint. 
[8444] devenv.exe Information: 0 :

I have come up completely blank while trying to find out what an MSBuild evaluation fingerprint is, where they come from, or what could cause them to be off like this.

Creating new project files is a non-starter given their shear size, the complexity of their configuration requirements, and the lack of enough time in our schedule for cleaning up small annoyances like this.

What are MSBuild evaluation fingerprints and how are they determined?

Community
  • 1
  • 1
Sean Middleditch
  • 2,517
  • 18
  • 31

1 Answers1

2

I assume you are using C++? The issue is that the solution directory which was used to build the project is saved to to "*.lastbuildstate" file. It's just a plain text file which look like:

#v4.0:v100:false
Debug|Win32|C:\MyPath\ToSolution\|

The second line is used as project evaluation fingerprint.

First line consist of following information (see line 246 in Microsoft.CppBuild.targets) #$(TargetFrameworkVersion):$(PlatformToolSet):$(EnableManagedIncrementalBuild)

Second line (see line 38 in Microsoft.CppBuild.targets) $(Configuration)|$(Platform)|$(SolutionDir)|

Microsoft.CppBuild.targets can be found at %ProgramFiles (x86)%\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets

Maybe its possible to modify / extend the MSBuild scripts not to use the SolutionDir in the lastbuildstate file.

Alex
  • 36
  • 1
  • Thanks. If the path _containing_ the solution is what matters, it might be easy enough to just move all our .sln files to our `Solutions/` directory instead of the umpteen billion sub-folders they're in now. – Sean Middleditch Dec 03 '13 at 18:16