We have a setup with MS Team Services where we have some local build agents. Recently we had some issues with errors about a not found system.io.compression. At the same time we could use hosted agents, but want to have the local running again. On one machine we managed to install a new agent that worked, but on another we get an error about system.io.compression when we try to install the agent. I'm not sure why this is suddenly an issue, maybe som gac mess up or other thing we need to clean up. the machines running the agents all have the latest Visual Studio 2017 installed
Related
We have an on-premises Azure DevOps, currently version 2019 Update 1. Last night I upgraded to 2019 Update 1.2, and initially everything appeared to be fine. However I noticed that builds weren't starting because I could see that the agents were disabled/offline in Collection Settings -> Agent Pools.
We have two agents - the "default" (v2.153.1) installed when we first installed DevOps 2019, and a second agent that I installed myself (v2.210.1). I checked that both agents' services were running in Services.msc, but otherwise had no idea what else to do.
It was getting late so I ended up restoring the server snapshot so it was back up and running for today. I'll need to attempt the upgrade again soon though. Assuming I encounter this issue again, what do I have to do to get the agents working?
I've installed the latest VS Build Tools (2022), but my on-prem build agent isn't picking up the VisualStudio-related capabilities. I've been under the impression that we no longer need to install the full application in order to get these capabilities.
An example from this blog post:
I've added all workloads to my offline layout, and I've included them in my installation.
I know this is possible, because earlier I accidentally included Python and VS 2019 Build Tools in my Node.js installation configuration. The VS-related capabilities were found by the agent then.
But I'm trying to get 2022, so I uninstalled 2019.
How can I get the 2022 VS-related capabilities to be installed and detected by my build agent, without installing the full Visual Studio product?
You need to upgrade the agent to a recent enough version. You can download the agent from the azure-pipelines-agent repository's releases page. Or manually specify the capabilities.
You may need to set a special environment flag on the agent to prevent it from automatically being downgraded to whatever version shipped with your version if Azure DevOps Server or Team Foundation Server.
And then you'll also need to install the latest version of the vsbuild/msbuild and vstest tasks
Required agent version
You will need to install the most recent agent from the azure-pipelines-agent repository for it to auto-detect Visual Studio 2022, or alternatively add the capabilities to the agent manually.
You may need to force Azure DevOps Server to not downgrade back to its preferred agent version. You can do so by setting the following environment variable at the system level on your server before launching the agent:
AZP_AGENT_DOWNGRADE_DISABLED=true
These tricks will work for most tasks in the azure-pipelines-tasks repository, as long as it doesn't depend on a UI extension or service connection type that isn't available in your version of Azure DevOps Server.
https://jessehouwing.net/adding-visual-studio-2022-to-azure-devops-server-2020/
I just updated my TeamCity server and I am suddenly getting this error message on my build agent.
I made a copy of the old installation, and the buildAgent.properties are the exact same. The Plugin folder for powershell exists aswell.
Does anyone have an idea on how to fix this?
I had the same problem when moved the build agent from windows to linux, and found the solution here.
In short:
Make sure powershell is installed on the server where the build agent is running.
You can set Platform and (Since TeamCity 2017.1) Edition properties at the PowerShell build step Edit page.
Edition: on windows Desktop, on linux Core
Platform: could be x64 or x86 based on installed version
If you set these properties correctly, it should meet the requirements, and you can use the build agent as before.
We have a two servers on farm. We issue using Visual Studio's "deploy" action where it can't install the feature because it couldn't be found :
Error 1 Error occurred in deployment step 'Activate Features':
Feature with Id 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' is not installed in this farm, and cannot be added to this scope.
It seems like Visual Studio will only deploy to one server, and we've evidenced that with a project that just had a package and the package only deployed files to the server with the URL. But it doen's worked for us, too.
Does anyone have any idea on what we can do to get the VS 2012 deploying to work when you have two servers for SharePoint 2013?
Can you please enlighten me on my task?
My task is to create a nightly builds of MSI (done in WiX) and install it to our web server using powershell.
TFSBuild server build an MSI
Run Powershell to uninstall and install the newly build MSI.
Run Powershell to Start the windows service.
The WiX MSI contains WindowsService and a Web Application.
Below are list of what i have done so far:
Solution.sln : Configuration Manager and "x86|debug" (check all the files that needs to be built '.wixproj' already checked)
Created a build definition and set "x86|debug" for configurations to build and set projects to build is my solution file.
but after the build has completed, there is no MSI files on the binaries build folder on the build server. :(
Thanks in advance.
Few pointers:
Have you installed Wix on the buildserver?
Which version of Team Build are you using? 2010 has the preference here as the tooling has progressed a lot since 2008.
Did you configure to run msbuild in auto or x86 mode (auto can result in 64-bit which has some issues with the latest stable version of wix) link link
Is your build agent running on a 64 bit server? If so, you either need to run the build agent under an administrative account or do some mucking around in the registry to fix issues with Wix. link
To install the build using Powershell, I personally prefer TFSDeployer, which can monitor your build output and trigger powershell scripts based on the build outcome. It takes away the deployment responsibility from the build server and saves a lot of headaches around security and account configurations.