We're experiencing problems with a build, since had been working fine up until last week Thursday. Now we get this error whenever it runs:
Not found SourceFolder:
C:\agent_work\34\s\PharmacyWarehouse\PharmacyWarehouse\bin\release\app.publish
This is in our test build environment. It fails on the Copy Files task. Both the source and destination folders are on the build server, so I think Copy Files would be fine. Here's our environment for test:
According to your description and error message. This may related to cache for build agent/server.
When you add a Visual Studio Build / MSBuild task to build the project, make sure you have checked the Clean option or set Clean=True. Thus it will delete all got source and generated build output which generated from prior builds.
Clean Option : Set to False if you want to make this an incremental build. This setting might reduce your build time,
especially if your codebase is large. This option has no practical
effect unless you also set Clean repository to False.
Set to True if you want to rebuild all the code in the code projects.
This is equivalent to the MSBuild /target:clean argument.
Also check if there are enough drive space in your build agent/server.
Besides, you could also reinstall build agent or upgrade your build agent version. This will force delete/recreate working folder. Which may do the trick.
Related
Actually first code is built and deployed after some updates developer changed the code and check-in the files now I want to build that files or folder and get that files artefact in drop folder? as well as how to deploy those files? in Tfs 2017 and it will automatically build only check-in files.
What you would like is to have an incremental build. When you add a Visual Studio Build / MSBuild task to build the project, just uncheck the Clean option. Thus it will sync the source and only get the changed files from the second time to build. See
Build task Arguments for details.
Clean Option : Set to False if you want to make this an incremental build. This setting might reduce your build time,
especially if your codebase is large. This option has no practical
effect unless you also set Clean repository to False.
Set to True if you want to rebuild all the code in the code projects.
This is equivalent to the MSBuild /target:clean argument.
However for artifacts, TFS always delivered all files - changed and unchanged.
It does copy all of the project output (subsequent projects that
depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only
deliver the changed files". It always delivers all files whether they
are changed or unchanged.
You could take a look at jessehouwing's reply in this question about this part: Incremental Builds issue in Team Foundation Server
I have a solution with around 70 projects inside, and occasionally (maybe 1/5 runs) during the 'Get Sources' stage of the TFS build definition, it will stop with the following error:
Access to the path 'D:\BuildAgent2018\_work\1\s\Implementation\Release\FileHelpers.dll' is denied.
'FileHelpers.dll' is a NuGet package which we pull into multiple different projects in the solution, however, we commit the packages directly to source, we don't use NuGet restore in the build definition, the first step is 'Get Sources' - which is where it sometimes fails.
When the software is built in release mode, it builds itself into the \Implementation\Release folder, but it's definitely worth noting that in the actual source, the \Implementation\Release folder is empty, therefore files such as 'FileHelpers.dll' only get there by the project being built in release mode, meaning that 'FileHelpers.dll' comes from a previous build on the build server.
I've heard that disabling multi-threaded builds could fix the problem, because it's multiple projects copying/deleting the same file at the same time that could be a cause of this issue, however, all the explanations say something along the lines of:
Make sure to explicitly run MSBuild with:
/p:BuildInParallel=false
or
/m:1
This doesn't seem like this would have an effect though, since the only place I can specify that argument is during the project build step, and the error occurs at the 'Get Sources' step (which is before the build step).
The weird thing is though that when I get this issue, it happens on every single build after that point, and is only fixed by reboot, which makes me think that the multi-threading scenario is less likely.
We also only ever run 1 build at a time (the agent has a build queue).
We have 'Clean' enabled for the mapped repository.
Any ideas what could cause this 'Access to the path 'X.dll' is denied.' error?
If you need me to post more detail, or snippets of code please comment and I'd be happy to do so!
EDIT - The file is in use by 'TE.ProcessHost.Managed.exe', even when a build is not running
For one of our build scripts (TFS 2013), when we run it manually or during Check-In (Continuous Integration trigger), the build script is not picking up the latest code changes. We looked in the logs and it does have the correct changeset number for the impacted files (in this case .vb files). We tried with several different .vb files. We also tried recreating the build script from scratch to no avail. We have several other build scripts for similar web applications that have no issues with the same build settings. This project builds fine. We set the Clean Build to True. Configurations is set to "Any CPU|Release". Output Location is set to SingleFolder. Build Template is set to TfvcTemplate.12.xaml. Any thoughts or suggestions would be appreciated.
So, after a bit of kicking the tires we figured it out. We had the actual compiled .dll in this case checked into TFS. Hence, the build server would grab the old version that was checked in versus compiling the project on the fly. We removed the .dll from source control to resolve the issue.
I have a TFS Build that runs overnight. The build source can be found on the agent in c:\build\3\poject\build def\Sources.
The \Sources folder was accidentally deleted (guilty). I would have expected TFS to "Get" the latest source prior to the next build. It seems that it doesn't do this - it just complains that it can't find any of the sources to build.
Can anyone please tell me how I force TFS to get the latest sources to the build agents \sources folder?
Under the Build Definition -> Process what is the Clean Workspace parameter set to? If it is set to All it should cause the entire source to be downloaded on each build.
There should be a way to cause a full redownload of source from the build definition but I am not seeing an option right now. You should be able to fix this on the build machine itself. If you cd into the Source directory and then run tf get /force it should redownload all of the content. Subsequent builds after this should work.
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.