After upgrading TFS2008 to TFS2010 it happened a few times that builds were failing on the build server(s) due to error TF42006.
TF42006: The build service could not get the project file for build definition X. Ensure the project file exists and the build service account Y is a member of the Build Services group for the team project.
TFS 2008 build definitions that are upgraded to TFS 2010 will use the Upgrade Build Process Template and do still need a path to the TFSBuild.proj file (folder level) in Version Control. If a new service account is used to execute the builds on the TFS 2010 Build Servers, you will need to make sure that the Project Collection Build Service Accounts group has at least Read permissions on the folder (TeamBuildTypes) where the TFS 2008 build definition is stored.
This might not be set correctly if security settings were modified (no inheritance of security settings) in TFS 2008.
Just try to avoid unchecking the inherit security settings on the Version Control folders, unless you know what you’re doing. Unchecking this may bring some unwanted side effects!
Build definitions in TFS 2010 that use the Default Build Process Template are entirely stored in the TFS database and can’t be tracked anymore via individual build project and response files. I only wish that there were some more auditing possibilities on changes done to the build definitions. An issue that I already raised during the beta phase of VS2010.