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
Related
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.
I have been slowly attempting to get the TFS build to work. After some other fixes with other issues, I have gotten to the point where the build will throw the below error. Not exactly sure what to make of the error. I have double checked to make sure the Resources folder is in the solution. However, the file called "resources" is not, but there is a file named "resource". I know this is not much info to go on, however I am stumped at this point.
Suggest you first remote to the build agent machine and check if there are corresponding G3.Resources.resources under path G3.Resources.resources C:\agent\work\1\s
\G3DEV\obj\Debug\G3.Resources.resources
Double confirm the Mapping settings correctly and not cloaked some files.
Try to manually use VS or MSBuild command to build your solution directly on your build agent machine. This will narrow down if your issue is related to TFS build definition side or not.
You could also Enable Verbose Debug Mode for TFS Build vNext by add system.debug=true to get more detail log info for trobuleshooting.
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'm using TFS 2013 on premises. I have four build agents configured on a Build machine. Several build definitions compile ASP .NET websites. I configured the msbuild parameters to deploy the IIS application to the integration server, which sits out there in Rackspace.
By default webdeploy does differential deployments by comparing file dates. In my case that's a big plus because copying files from our network to Rackspace takes quite some time. Now, in order to preserve file dates the build agent has to compile the same base set of source code. On every build only the differential source code yields a new DLL, minimizing the number of files deployed.
All of that works fine, with a caveat: a given build definition has to be assigned to a build agent (by agent name or tag). The problem is I create a lot of contingency when all builds assigned to the same agent are queued up. They wait in line until the previous build is done.
In an ideal world any agent should be able to take care of any build, but the source code being compiled has to be the same, regardless of the agent.
I tried changing the working folder of all agents to point to the same location but I get an error because two agents can't be mapped to the same folder. I guess there is one workspace per agent.
Any ideas?
Finally I found a way to do this. Here are all the changes you need to do:
By default the working folder of each agent is $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath). That means there's one working folder per BuildAgentId. I changed it so that all Agents share the same folder: $(SystemDrive)\Builds\WorkingFolder\$(BuildDefinitionPath)
By default at runtime the workflow creates a workspace that looks like "[BuildDefinitionId][AgentId][MachineName]". Because all agents share the same working folder there's an error trying to create each separate workspace. The solution to this is in the build definition: Edit the xaml and look for an activity called "Get sources from Team Foundation Version Control". There's a property called WrokspaceName. Since I want to have one workspace per build definition I set that property to the BuildDetail.BuildDefinition.Name.
Save your customized build template and create a build that uses it.
Make sure the option "1. TF VersionControl/1. Clean workspace" is set to False. Otherwise the build will wipe out all the source code on every build.
Make sure the option "2. Build/3. Clean build" is set to false. Otherwise the build will wipeout the output binaries on every build.
With this setup you can queue up the same build on any agent, and all of them will point to the same source code and bin output. When the source code changes only the affected binaries are recompiled. I have a custom step in the template that deploys the output files to IIS, to all the servers in our webfarm, using msdeploy.exe. Now my builds+deployments take one or two minutes, because only the dlls or content that changed during the build are synchronized to the servers.
You can't run two build agents in the same folder. The point of build agents is to run multiple builds in parallel, usually on separate PCs. If you try to run them on the same source code, then (a) it's pointless as two build of exactly the same source should produce identical results, and (b) they are almost certainly going to trip over each other and cause the builds to fail or produce unexpected results.
If you want to be able to build and then deploy a series of versions of your codebase, then there are two options:
if you queue up multiple builds, then the last one will "win", so the intermediate builds are of no real value. So if you check in New code before your first build completes, you may as well stop the active build and start a new one. you should be asking yourself why the build is so slow, or why you are checking in changes so often that this is necessary.
if each build produces an incremental update to the deployed result, then you need to pass the output of your builds to some deployment agent that is able to diff it against the deployed version and send only the changes to be deployed. This could be set up to gather results from multiple build agents if that would be beneficial.
but I wonder if perhaps your build Is slow because you are doing a complete build each time (which cleans the build folder, gets all the sources, and does a full rebuild), when what you want is an incremental build (which gets the latest changes, compiles only what is affected, and complete quickly). perhaps you should investigate making your build incremental.
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.