So, I tried to upgrade my TFS 2015 to allow project with .NET 4.6.1.
I downloaded the Targeting Pack for .NET 4.6.1, ran it, restarted the server, ran my build configuration for the build agent by overwriting the old settings, and started my builds.
Now non of them will build :(
I think I miss setting a parameter somewhere.
This is my agent, which is registered, but never requested (for some odd reason):
Am I missing something?
According to your agent.version 1.95.3, seems you are using TFS2015 update3 which should definitely support .Net 4.6.1. And the system capabilities of your agent looks okay except the Number_OF_PROCESSOR. Your value is 1, but usually the default is 8. Did you manually change the value during the configure?
Recommend you follow below way to narrow down this issue:
First check in that if the build server is available and enabled in
TFS at https://YOURCOMPANYNAME:8080/tfs/_admin/_AgentQueue, and
your build agent should be “Green”.
Make sure the agent is in interactive mode.
Try to change a domain account which is a member of the Build
Agent Service Accounts group and belongs to "Agent Pool Service
Account" role, to see whether the agent would work or not.
Double check whether there are some Firewall interface block the
build, try to disable all related settings.
If it's still not work, delete that agent and re-deploy a new one following the detail steps in this article. You can also go through below similar questions to check if there is some useful info :
TFS 2015 On-premise issues
TFS 2015 build vNext - hangs with "Waiting for console output from
an agent..."
TFS 2015 Build agent won't start
Related
We have recently upgraded to TFS 2015 Update 4. When I tried to do a build, I am getting the following error:
There are issues with the request or definition that may prevent the build from running:No agent could be found with the following capabilities: msbuild, visualstudio, vstest Queue the build anyway?
I tried the workaround mentioned in this link, but still couldn't figure out.
I have installed VS 2017 Enterprise in the Build Machine. Note, that since this is a POC I have installed Build Agent on the TFS Server itself.
Should anything extra be need to be installed? Please help.
TIA
You could double check if you are missing some capabilities such as VSTEST_15.0 for the build agent.
Settings- Agent Queues- Agent Pool - Agent- Capabilities
If the test related capabilities are missing, you could try to reregister the build agent. Or manually add the capabilitie by select +.
Recently I had the same issue: installed VS2017, configured build agent, visualstudio and msbuild capabilities missing.
Try installing VS2015 next to VS2017. Re-configure the build agent after this (in my case, I completely removed all the old _diag, _work and settings.json data as well). This fixed the issue for me, the missing capabilities were now recognized.
I was getting the same error out of the blue and it was running fine the previous week.
Restarting the build agent service resolved the error for me
Using on-prem TFS 2017, I have added an additional agent to an existing pool. The agent is displayed in the pool/queue management pages, is enabled, and is in an idle state. The logs reflect a healthy agent that is listening for work, but the TFS controller won't designate work to it (as far as I can tel). I have tried disabling the other agent as well as stopping the other agent's service. In either situation, the build status states there are no available agents to perform work. I have other agents running in different pools that are all functioning properly, so I am not sure how to determine whats at fault: agent/agent configuration, queue/pool configuration, or the TFS controller it self.
I finally found the issue:
While MSBuild and all the relevant Microsoft SDK's required for my builds were installed and properly reflected in the agent's capabilities, Visual Studio was not installed on the new build server.
I was not able to determine why the agent(s) was rejected for insufficient capabilities; we were running TFS 2015 update 2, but after an update to TFS 2017, the agents are no longer dependent on Visual Studio being installed and work just fine running the same build definitions with the MSBuild step.
I would like to upload on my TFS 2015 some of the build tasks that are available here https://github.com/Microsoft/vso-agent-tasks.
I do have a problem with certain task as they do require a minimum agent version of 1.89.0. My build agents are 1.83.2 version.
Now, the question is, how do I update my agents for a given pool? If I do right click the agent pool on my TFS and choose update all agents option, nothing happens. I suppose because the latest version of my agent available on TFS is the 1.83.2.
Where can I find the latest version of it and how do I update it?
Note I'm working on premises TFS 2015 and not VSO.
Thanks
If you right-click the agent pool and choose "Update all agents", it will upgrade the agents to the version of the on-premise TFS server. For instance, if you initially installed some RC, and upgraded the server to RTM later, some agents might have lower version. Otherwise, as you mentioned, nothing will happen because all agents are up to date.
VSO has a different release model and updates/fixes to its agents are continuously delivered. That's why the version is constantly growing.
Technically it might be possible to grab the source code of the latest VSO agent tasks, and push it to the on-premise version of TFS 2015. However, it is considered an anti-pattern, and the behavior is undocumented and unsupported.
Let me quote build vNext developers from this discussion (see the bottom of the thread):
That is not a supported option. It is very likely that the agent we
have in VSO will not work with the on-prem server. You must use the
version of the agent that ships with your server.
And:
The behavior is undefined/untested. It may work, may not. The design
is for agents to get pulled forward via an auto update process
downloaded from your service. The auto update process may alter
configs/layout on disk, whatever. That future agent might call REST
apis that don't exist, etc... The primary focus for agents is on
forward compat so they can lazily get upgraded (via task minimum agent
demand, on restart or eventually a scheduled job).
Same answer as #Yan, but putting this here because the following error came from nowhere - so I think Microsoft updated the minimum requirements this week.
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
Agent.Version -gtVersion 1.95.0
For your own hosted agent just right click on the queue, or click the ... icon.
I had to restart the agent service after a few minutes as it didn't seem to want to by itself. Give it a chance to update properly before doing this.
I'm setting up a new build server using TFS 2015 and after I configured the agent, when I tried to queue a build I got this error:
No agent could be found with the following capabilities: msbuild, visualstudio, vstest
How can this be resolved?
Install Visual Studio on your build agent, then restart the build agent. Restarting the build agent will capture the added Capabilities.
Note: First of all, you can do all this with the community edition and TFS Express 2015 on your own server (for free up to five users) - so don't worry about needing to use the Visual Studio online version or paying for Visual Studio Professional.
It is very easy to misinterpret the error message provided and go off on a wild-goose chase trying to debug it.
Unfortunately the message itself is just badly worded and that's the real problem.
Here is what that error message really means:
"No agent could be found with the following capabilities: msbuild,
visualstudio, vstest.
In fact I didn't actually find ANY build agents configured for the selected build queue."
So you're thinking that doesn't apply to you because you just created a build agent?
Well, maybe you did, but here's what probably happened:
You created a new pool (for no reason other than you just thought you ought to).
You then created a queue under that pool.
You ran the PowerShell script to create an agent and you assumed it put it in the pool you just created....
But it didn't - it put it in the 'default' pool which you aren't even using...
Aha!
So here's what happens when you build:
You select a queue from the dropdown.
TFS tries to build by looking for the pool that corresponds to that queue and it doesn't find any agents AT ALL there, so you get a stupid useless red-herring error message.
When I finally realized what happened I just deleted my cutely named pool + queue and just reverted to using the default pool.
Next time I will try to pay more attention to this message during the PowerShell configuration:
Configure this agent against which agent pool? (default pool name is
'default')
You will have to create a queue under the pool, but then your agent should start working.
If you have a genuine with a certain capability being absent from your agent you can check what your agent supports via the 'capabilities' tab shown here. Of course msbuild, visualstudio and vstest are all here :-)
In my case, after installing MSBuild (https://www.visualstudio.com/downloads/, search for "Build Tools for Visual Studio 2017"), I just had to add the path to MSBuild to the PATH environment variable. The agent wasn't detecting MSBuild until I did that.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
I did NOT have to install the full Visual Studio IDE. The selected answer for this question is just plain wrong...
By default, when using the new build system on VSO, it doesn't pick the hosted build option, which is how I ended up on this post in Stack Overflow. If you are used to using a VSO build server here's what you need to do:
Create a hosted build by going to the General tab and changing your Default Queue to hosted. More on the restrictions of that and how it works here: https://www.visualstudio.com/get-started/build/hosted-agent-pool
Add them as User-defined capabilities, e.g.:
visualstudio C:\Program Files\Microsoft Visual Studio\2022\Community
vstest C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I had initially installed the agent on a machine that did not have Visual Studio installed. However, after installing Visual Studio (and then Visual Studio Build Tools), restarting/recreating my agent, restarting my machine, etc., I could not get the agent to detect the new capabilities automatically, so I added them myself in Azure DevOps as User-defined capabilities.
I had this issue and it turned out being my release process had selected the "wrong" agent. Just edit the release and set the correct agent queue
I was using a Xcode build slave for building an Xcode project.
And the error message I ended up with in TFS 2015 was
"No agent could be found with the following capabilities: xcode"
I registered an OS X on-premise build slave.
In the "Register Agent" step, I named by build agent:
>> Register Agent:
Enter agent pool (press enter for default) > My-Xcode-Agent-Pool
So, I had to select the "My-Xcode-Agent-Pool" as Default queue in the build settings. Source: Microsoft-hosted agents
Although none of previous answers worked for me, the post by Simon_Weaver pointed me in the right direction.
He mentioned that vstest was in his list, but it wasn't in mine. I fixed it by adding a user-defined capability named "vstest" with the full path to vstest.console.exe under Visual Studio 2017.
What ended up working for me was to go to where I downloaded the agent and running:
./config.cmd remove then ./config.cmd to reinstall the agent from the command line inside the directory of my agent.
Download agent
per microsoft https://msdn.microsoft.com/en-us/ie/bb399135(v=vs.94)
You must install on the build agent the version of Visual Studio that your team uses on its dev machines. See Installing Visual Studio. You must also install any other software and components that are installed on your dev machines and that are required to build your app.
In my case, after installing MSBuild, restart all Azure services (in windows service) and it worked. No need to install full Visual Studio
You have to install the correspondent Visual Studio version on the build machine (where you have installed your agent). This will add the required tools and capabilities to the server.
Visual Studio is required, because it installs all the build targets required to build your projects.
After being installed, you have to restart the agent Windows service so that it refreshes the list of capabilities.
Since you are using the Visual Studio installation on the build machine to build, that installation doesn't count as an additional license.
General solution for TFS:
The common way of resolving most of the issues on the build server is to install Visual Studio & all dependent packages on your build server.
Alternative solution in case of using VSTS
When you choose where to build, use "Hosted"
and then the build will work.
The guide how to make it work may be found here: Deploy an agent on Windows for TFS 2015
Check the agent section which will contain information about capabilities.
Updated:
Once you have the list of capabilities in vsts(azuredevops)
you might need to install the desired software on your build agent machine.
PS Be aware, you might have to license your sw, if required.
We're working on migrating our build solution from TFS 2008 to TFS 2013. As a part of that process, I am trying to add a clone of (one of) the current build agents (based on TFS 2008 and Visual Studio 2010) to the new TFS 2013 build controller, to make sure that we have the ability to run builds with the same environment that we do now. (This capability will be needed for some time e.g. for minor updates, hotfixes etc.) The clone has been created, started, and given a separate DNS name on the network, to allow it to be addressed.
Currently, our new environment has a TFS server, as well as a build server that hosts both the build controller and one build agent; all TFS 2013. (I'd rather see that the build controller at least ran on the TFS server VM, or ideally on a completely separate VM, but this is what it's like right now.)
When I log in to the new build controller/agent and run the Team Foundation Server Administration Console, then go into Build Configuration under that host's root node, it shows the build controller as well as the build agent (both with the same name because they are running on the same VM).
When I click "New Agent...", I expect to be able to add a new build agent (that's what the link says, after all). This is also what Microsoft indicates you should do in their documentation. However, what happens is that I get a window titled "Build Agent Properties" that appears to show the details for the existing build agent configuration. Specifically, it pre-populates the "Computer Name" field with the name of the existing build agent and has selected the existing (TFS 2013) build controller. The "Build Agent service is enabled" checkbox is checked, but the box immediately underneath that checkbox says "Build Agent status is Offline". In the main administration console window, both the controller and agent show as "Ready", and they have executed builds previously. I also cannot edit the "Computer Name" field.
So, to recap:
When the TFS 2013 build controller is also a TFS 2013 build agent, how do I add a second (TFS 2008-based, in my case) build agent to the build controller?
I imagine I'm missing something really trivial, but I just cannot see what, and Googling has turned up seemingly nothing of relevance.
Click "New Agent...", change the 'display name', click ok and you'll get a new (2013) build agent.
You're going to have to upgrade your existing 2008 build agent. IIRC 2010 build agents only connect to 2012 controllers if they're patched with sp1 so you've got no chance with 2008.