I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
I have a TFS 2017 Update 2 on-prem server with VS 2017 Enterprise installed. Our Build contains a Unit-Testing project which contains a Fakes assembly and works locally on the dev machines.
When build on TFS, the build fails with
The type or namespace name 'Fakes' does not exist in the namespace
'Our.Product' (are you missing an assembly reference?)
(i.e. misses/fails to generate the Our.Product.Assembly.Fakes.dll file)
I have additionally set up Fakes as suggested here.
What baffles me is that there are no mentions of Fakes in the build log (except for the error itself and the paths where MSBuild looks for the file), even with debug verbosity. He doesn't event try to generate the Fakes assembly.
Are there other steps I need to take? We use the vNext build definitions.
Update:
This is the build step that works now, before the /tv:15.0 /p:VisualStudioVersion=15.0 were not there.
Update
Use the latest version for msbuild arguments such as /tv:15.0 /p:VisualStudioVersion=15.0 could solve this issue.
First try to use build service account RDP to remote build agent and manually run the build to see if the assembly generated.
This will narrow down if it's related to your environment on the build agent. Make sure it's the same as your locally dev machines.
If the assembly is also generated, then the issue may related to your build definition settings. Check if you are using the right msbuild version. For vNext build, also enable verbose Debug Mode with system.debug=true
Not too sure if what I'm asking here is possible, or if it requires an upgrade. My problem is that I have a local install of TFS 2013 (that is, on-premises), and all dev machines have now upgraded to VS2015. However, when using new features (such as $"test {teststring}"), we get build errors.
The build machine has both VS2013 and VS2015 installed, and is using the default build template (TfvcTemplate.12.xaml). Looking at the "Run MSBuild" task inside the build workflow, there doesn't seem to be any way to point it to one MSBuild or another.
Is it possible to hint to the build to use the later version of VS / MSBuild and, if so, how?
Try adding /tv:14 to the msbuild commandline arguments in your build template, if that doesn't work, edit the xaml file for your build process template and override the "ToolPath" property of the "Run MsBuild for Project" task. Or make that field configurable through further customization of the build template.
Set that path to C:\Program Files (x86)\MSBuild\14.0\Bin (or your equivalend location in case your machine uses alternate default directory names).
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.
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.