I am developing a project that uses TFS to build solutions. But I found an error that I do not know how to solve it. When we compile a solution, we can specify a changeset to compile, right? Imagine the following scenario:
At this moment the last changeset is number C100
We created the proj file in TFS. After creating the file, the C101 is the last changeset.
I try to compile using the changeset number C99.
An error occurs: TF224003: An exception occurred on the build computer xxxxxxx: TF42006: The build service not could get the project build definition file is xxxxx. Ensure, the project file exists and the build service account domain \ xxxxx is a member of the Build ...
In this scenario, is there any solution?
Have you tried these suggestions? Examine this scenario and see if any of it matches your case.
possible solutions
Related
I have an on-prem 2017 install of TFS.
Other similar builds work just fine however this new build i have created fails at the first step - NuGet Restore.
The path set is: ***.sln
I will add that I created the new build by copying from another (working) build. There aren't many options to set in the task so I'm not sure what went wrong.
Attached is the result from the log page.
Any help appreciated.
thanks.
According to the error info
no matching files were found with search pattern: E:\vstsagent\_work\5\s\**\*.sln
Seems the build agent is lacking of the solution file.You could double check this on the build agent folder E:\vstsagent\_work\5\s\** to see if there are or not.
Please go through your repository mapping settings, mark sure including and not cloaked that .sln file.
I have an instance of TFS 2015 with vNext builds working on my DEV branch.
I cloned a working build definition and set the Maps and solution file to the corresponding paths on the Main branch. On the Main branch they fail with the error message: "Could not find a part of the path 'C:\agent4_work\5f9b9727\myTfsProjectName'." This path is not even being created in the _work directory like is when I use the paths for the Dev branch.
Notable similarities between the two builds:
The build steps being used in both cases are the NuGet Installer and Visual Studio Build steps.
Same code exists in both branches.
Notable differences:
Main is the parent branch of DEV
Main has an added permission group to deny certain users from checking in.
My TFS service account is not a member of this group so I don't that applies.
Note: If I change the clone to point to DEV, it doesn't fail.
Can anyone tell me how to solve this mystery? Thanks.
Edit:
I found another difference the working branch has that the Main branch doesn't.
I don't remember adding the Project Build Service to the Dev branch. I also don't know why Main did not have this security setting. After I added the same security credential to Main, builds on Main started working. This raises another question: Does one need to add the Project Build Service to every branch as a second step in order to perform TFS builds?
Usually, the Build service account should be created and added to code repository automatically when the project is created and it will be inherited in every child folders. So the user does not need to add it to other branches/folders manually. For your case, I'm not sure if the user is removed unexpectedly or any other things happen.
Have you set "Items To Build" to correct path?
In Build Definition->Process-Items to build
screenshot from Build Definition
When we do team builds using tfs 2013 we occasionally get the following error:
Exception Message: Unable to create the workspace '41_9_UKBOLTFS6' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'.
Details: The path C:\xxx\xxx\xxx is already mapped in workspace 41_9_UKBOLTFS6. (type MappingConflictException)
If we kick off a new build it may succeed, if not we try again and eventually it works without any changes.
I have seen very similar questions posted on stackoverflow about this but non where the workspaces it is complaining about are the same '41_9_UKBOLTFS6'.
We migrated most of our builds from TFS2010 but not all and we never had this issue before.
Does anyone know what is going on?
This occurs (as the error suggests) when you have a workspace clash on the build server. Workspaces are saved as configuration values in the TFS database so clashes are possibly caused by:
you have created a new build definition with the same name as a previous build definition.
some part of your workspace name (or an artifact within your project) is over 260 chars
build definition is not using $(sourcedir) macro in System Settings tab
More details are explained in this article
Possible work-around:
Rename your build definition to something unique.
Looks like you have multiple team builds mapped to the same local directory. Make sure that the Working Directory in all your agents are unique and there is no absolute path in workspace settings of your build definitions
I've run to this issues and blogged about my solution without renaming the build definition. Check it out here: https://christiaanmolendijk.nl/2016/05/23/before-stressing-out-tfs-cache-folder-on-build-server/
Summary of the link:
Go to cache folder: {userprofile}\AppData\Local\Microsoft\Team Foundation\{version}\Cache
Edit file VersionControl.config in Volatile folder
Then go back to the cache folder at {userprofile}\AppData\Local\Microsoft\Team Foundation\{version}\Cache and delete the folders with a GUID as name.
So I have build project on TeamCity 8.0.3 and have create two build steps.
1.) The first step is to Install all NuGet packages.
I have set my project up according to this blog and if I run this step it works fine however I went over the logs and found: [14:07:45][install] All packages listed in packages.config are already installed. Is this OK?
2.) I have another step that is suppose to build my Class Library however I get a compilation error saying that references are missing even after step one, which is suppose to install the packages, has passed?
What am I doing wrong and should I provide more log details?
As already stated by Pedro, the first log message is absolutely normal.
For the second issue, it's not easy to throubleshoot a compilation error without logs :)
Often the issue is related to wrong checkout rules.
You can try to figure out what has been downloaded by teamcity by looking on the agent working directory (normally it is downloaded under c:\buildagent\work\'something', look at the build log to find out the actual folder).
Another common issue is that references are stored as absolute paths instead of relative paths: everything works on your machine, but teamcity builds on a different folder so referenced files can't be found... You have to open your csproj files with a text editor to find out if everything is ok.
Copy the entire folder on your machine and try to build it: are you able to reproduce the error?
I am attempting to use CI on a Branch of one of my TFS projects. MSBuild only fails when I try to use a Branch. I point the same Build at the "trunk" project it works fine.
The error I receive from the build log:
Task "Label"
Label TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6763"
Name="Test_SF_20090619.1"
Scope="$/MyProject" Recursive=True
Comments="Label created by Team Build"
Version="BuildServer3D143_66"
Child="Replace" Files="$/" C:\Program
Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(812,5,812,5):
error : No matching items found in $/
in your workspace.
Done executing task "Label" -- FAILED.
Done building target "CoreLabel" in project
"TFSBuild.proj" -- FAILED.
I believe this error is being caused by a lack of source files getting copied to the Build server.
Get task excerpt from build log:
Task "Get"
Get TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6768"
Force=True Overwrite=False
PopulateOutput=False Preview=False
Recursive=True Version="C204806"
Workspace="BuildServer3D143_66"
Done executing task "Get".
This is a full build. There should be about a thousand files listed in the GET.
General Information
TFS 2008
Visual Studio 2008
Established build server (been
running builds for the last year)
Project being branched is a ASP.NET
web stie (2.0 Framework).
Full Build Params
/p:SkipClean=false
/p:SkipInitializeWorkspace=false
/p:ForceGet=true
/p:IncrementalBuild=false
/p:IncrementalGet=false
note: I know IncrementalBuild is redundent but I just wanted to be sure.
Questions:
Are there restrictions on builds off a branch?
Any idea why MSBuild fails to pull files from the branch workspace?
If it's for CI then you're most likely doing an Incremental Get. TFS will only bother to get files it thinks have changed since its last get - e.g. if you delete any files from your server, it will still think you have those files so it won't get them again. In this case you'll need to run the build once with the incremental properties turned off so that it forces a full get of the source. You can do this by overriding the properties in the MSBuild command line box in the Queue Build dialog with:
/p:IncrementalGet=false;ForceGet=true
Another possibility that springs to mind is that the Label task is confused by your branch. It may be that your workspace is set up incorrectly, so check that you're mapping in everything it needs.
I had two issues in this case.
First, the branch security did not give rights to the build service account. I had restricted the branch to our team's Tech Leads and Release Engineers. The build service account needed access as well. What tipped me of was while searching the internet I stumbled upon a posting by someone who had made the same mistake.
The second issue was a little more involved. While cleaning up my build project file, I removed the following section.
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../_stage/MyProject/MySolution.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
Which worked fine on projects I had already built at least once, but if this was a new build, that had not copied source files to the build server, then there would be no files and the build would fail.
Some of you may wonder if my other builds were working either, after all wouldn’t they have old build files. Yes, but I had targets defined that did all the work I actually cared about. So the SolutionToBuild is a little frivalous.